CN109889416B - 一种基于微服务架构的智能家居系统及构建方法 - Google Patents

Abstract

一种基于微服务架构的智能家居系统及构建方法，包括服务器、第三方无线传输设备群和传感器组件。传感器组件通过连接电路与无线传输设备相连形成无线网络节点，无线收发设备根据所使用的无线传输协议将传感器采集的数据发送至协调器，协调器将各无线网络终端节点采集的数据汇总后通过串口发送至服务器，服务器通过串口实时监听脚本将串口数据存入数据库，以完成无线网络节点数据的汇总。本发明采用单一服务器，使用Docker+Spring cloud的方式实现服务的注册发现和负载均衡机制，可以有效降低系统的耦合度，每一个微服务可以单独开发，单独部署甚至可以使用不同的语言进行开发，极大程度的减少了系统的维护和更新的成本。

Description

一种基于微服务架构的智能家居系统及构建方法

技术领域

本发明涉及智能家居技术领域，特别涉及一种基于微服务架构的智能家居系统及构建方法。

背景技术

目前市场上很多物联网产品，实现了家庭控制的集中化，业务包括了安防，控制和计量等应用，同时实现了通过手机等终端在互联网进行资源的整合利用。在物联网的应用中，物联网服务平台主要对数据进行存储和智能分析处理，为应用提供功能支撑。例如，公号为CN107809356A的发明专利，公开了一种“将互联网资源接入智能家居平台的”的控制方法和系统，其通过将待处理对象信息和数据封装并传输至云平台，将物联网设备接入互联网并下载整合数据包，之后对数据进行实例化处理从而为应用提供支持。

此类物联网智能家居服务平台一般都由一个庞大而复杂的系统支撑，系统的各个功能间耦合度较高，对于每一个特定应用的创建都需要复杂的集成工作，这使得系统的维护工作难度很高，同时不方便进行业务的拓展。

另外，传统智能家居服务平台使用的物联网设备可能由于厂商的不同，导致通信协议，数据传输格式产生差异，这使得即使是同一智能家居平台也没有设备之间的互操作能力。

发明内容

为了克服传统智能家居系统紧耦合、复杂度高以及难于维护和水平拓展的缺点，本发明的目的在于提供一种基于微服务架构的智能家居系统及构建方法，将微服务架构引入智能家居系统，即将系统业务解耦为功能单一且完整的微服务，每一个服务可单独部署在不同的服务器或docker容器中，服务之间通过Restful API进行通信和调用以完成更复杂的业务逻辑。

为实现上述目的，本发明采用的技术方案如下：

一种基于微服务架构的智能家居系统，包括服务器、第三方无线传输设备群和传感器组件；其中，传感器组件通过连接电路与无线传输设备相连形成无线网络节点，无线传输设备根据所使用的无线传输协议将传感器采集的数据发送至协调器，协调器与服务器使用串口相连，并将各无线网络节点的数据汇总后通过串口发送至服务器，服务器通过串口实时监听脚本将串口数据存入数据库以完成无线网络节点数据的汇总。

本发明进一步的改进在于，传感器组件包括DHT11温湿度传感器，MQ2可燃气体传感器和ST188光敏传感器，各传感器分别通过连接电路与无线传输设备相连用以收发系统监测的数据。

本发明进一步的改进在于，无线传输设备CC2530短距离无线传输模块，根据功能将无线传输模块分为终端节点和协调器节点，终端节点与传感器相连，承担数据的发送任务，协调器节点是整个网络的中心节点，负责维护和更新整个网络，接收来自各个终端节点发送的环境数据，并将数据汇总打包通过串口发送至服务器。

本发明进一步的改进在于，服务器中运行串口监听脚本，将串口数据实时写入数据库中，数据包使用多位校验码进行完整性验证，不同类型的环境数据使用不同的校验码验证；当所需数据齐全时，串口监听脚本对数据包进行处理，去掉验证码并加入时间信息后存储至数据库中。

一种基于微服务架构的智能家居系统的构建方法，其特征在于，包括以下步骤：

S10、将第三方无线传输设备通过无线网络协议组网，根据环境要求将无线传输设备组成星型网络或树状网络；

S11、通过连接电路将传感器与无线收发设备相连，无线传输设备在将传感器监测数据发送前按照协议要求对数据进行打包并于数据包前后加入校验位；若无线传感网络为星型网络，则终端节点直接将数据包发送至协调器节点；若无线传感为树状网络，则终端节点将数据包发送至当前节点的父节点，并逐层将数据包发送至协调器节点；

S12、协调器节按照预设的时间周期将各终端节点采集到的数据包进行汇总和预处理，并通过串口与服务器连接，将汇总后的数据发送至服务器；

S13、服务器端建立数据库并运行串口监听脚本，串口监听脚本对串口接收到的数据进行预处理，将数据包中存在的校验位去除，并将处理后的数据实时存入数据库中；

S14、采用单一服务器，使用Docker+Spring cloud的方式搭建微服务架构；完成在微服务的部署后，采用Zuul组件实现微服务的注册发现和负载均衡。

本发明进一步的改进在于，步骤S10中，当传输距离不超过50m时将无线传输设备组成星型网络，星型网络中包括协调器节点和终端节点，每一个终端节点只能和协调器节点进行通讯；如果在两个终端节点之间进行通讯时，通过协调器节点进行信息的转发；

当传输距离超过50m时，将无线传输设备组成树状网络，树状网络包括一个协调器节点以及一系列的路由节点和终端节点；协调器节点连接一系列的路由节点和终端节点，协调器的子节点的路由节点也可以连接多个路由节点和终端节点，由此组成多个层级。

本发明进一步的改进在于，步骤S14中，使用Docker+Spring cloud的方式搭建微服务架构的具体过程如下：

在服务器中完成docker的安装和配置，然后制作docker镜像，再搭建私有docker仓库；在成功配置和上线docker容器后，在上线的docker容器中搭载一个或多个微服务，同种类型的服务具有相同的service id，每一个服务都需配置不同的端口或ip地址，每一个服务都通过Restful API相互协调和调用并被唯一的URI标识；客户端通过HTTP协议调用主服务，主服务通过负载均衡机制选择相应的微服务，若用户需要完成的业务需要多种服务协调完成，则服务间通过Restful API进行通信和调用，处理的结果通过HTTP协议返回至客户端。

本发明进一步的改进在于，在系统应用层面，在服务注册中心注册主服务，并将该服务地址作为其他服务的注册地址，根据业务需求开发功能单一且完整的微服务；同时，在服务器端配置docker容器和负载均衡Zuul组件，将开发的微服务在docker容器中上线，并为每一个微服务配置不同的端口以便其他服务对此服务进行发现和调用；然后，开发统一的Restful API，使每一个微服务均能够被唯一的URI指定，并且服务之间通过PUT、POST、DELETE与GET四种HTTP请求相互调用和通信。

本发明进一步的改进在于，步骤S14中，采用Zuul组件实现微服务的注册发现和负载均衡的具体过程如下：

建立一个空的maven工程；创建服务注册中心，配置server.port来设定服务器端口号；开发微服务，配置server.client使得该服务能够使用服务注册服务器；将微服务注册地址设置为服务注册服务器地址；

根据需求开发多个功能单一且完整的微服务，每一类微服务单独开发，同一种服务存在多个拷贝；

将微服务打包配置进入docker容器，根据系统需求每一个docker配置多个微服务；

将所有开发的微服务注册在主服务地址下并配置负载均衡组件以完成服务的注册和发现；

定义Restful API，使服务间通过四种HTTP请求相互调用。

本发明进一步的改进在于，该智能家居系统具有用户自定的业务需求模式、设备省电模式以及具有数据库更新删除模式。

本发明进一步的改进在于，在服务间进行调用时，某微服务将待调用服务的service id写入请求，根据业务逻辑进行判断；若需要创建资源，则发送POST请求；若删除操作，则发送DELETE请求；若更新某中资源，则发送PUT请求；若查看操作，则发送GET请求；待调用微服务采用Jason格式对返回数据进行封装，之后原微服务对请求进行处理，并将处理结果返回客户端页面。

与现有技术相比，本发明的有益效果是，本发明在使用微服务架构后，系统的每个功能被分配给了不同的微服务，每个微服务可以单独执行，单独部署甚至可以使用不同语言进行开发。微服务架构极大程度的降低了系统的耦合度，将一开始所有的功能都集中在一个实例上的模式转化为多个单独的实例相互协调而完成业务的模式。由此一来，系统的维护人员在进行业务的拓展或系统的更新时只需专注于自己维护的微服务部分而不用了解其他业务是如完成的，系统维护人员在使用微服务架构时只需修改特定服务或修改某些服务间的接口就进行系统的维护和拓展，这相比于以往牵一发而动全身的整体架构模式有更高的灵活性并极大程度的降低了系统的开发和维护成本。此外，对于物联网应用系统来说，由于不同通信设备或传感器可能由不同厂商制造，因此这些设备可能在通信协议、数据格式以及数据传输方式上存在差异，而基于微服务架构设计的物联网应用平台从应用层面解决了物联网设备异构的问题，每个服务单独部署并且可以建立自己的数据库，因此其分布式、开放式的设计特性易于实现跨应用的交互，使得不同厂商的设备在同一系统下能够完成数据的交互。本发明使用微服务架构开发的智能家居平台可以有效降低系统的耦合度，每一个微服务可以单独开发，单独部署甚至可以使用不同的语言进行开发，极大程度的减少了系统的维护和更新的成本。本系统虽然由功能单一且完善的微服务组成，但服务之间可以相互通信和调用以完成较为复杂的业务逻辑。

进一步的，每一种服务的拷贝数量由实际的用户请求数量和服务器性能决定，若用户体量较大，在某一时间内对同一种服务的请求次数较多，为保这一服务能够及时响应每一个用户请求，可对该服务建立多个拷贝。每一个拷贝具有相同的service id和相同的业务功能，在为新增服务配置完负载均衡组件Zuul并将这些服务分别上线后，若某一时间内对同一种服务的请求次数较多，系统便可根据负载均衡机制选择该服务的不同拷贝对用户进行响应。通过这种方法，可以极大程度的降低系统在高峰期的负载量。

进一步的，在服务器中安装负载均衡组件Zuul并通过修改配置文件完成对Zuul的配置；启动Zuul组件。Zuul完成的是对docker容器形成小型服务器的负载均衡和反向代理机制，因此若同一docker容器中存在同种类型服务的多份拷贝，服务注册中心会同时调用多个相同的服务来处理同一请求，因而消耗不必要的系统资源，甚至产生严重的读写冲突问题。

附图说明

以下结合附图，对本发明上述的和另外的技术特征和优点进行清楚、完整地描述，显然，所描述的实例仅仅是本发明的部分实施例，而不是全部实施例。

图1为本发明的实施例1所提供的基于微服务架构的智能家居系统搭建方法的流程图。

图2为本发明系统结构示意图。

图3为本发明实施例3所提供的基于微服务架构的智能家居系统节电模式方法的流程图。

图中：21-客户端，22-服务通信单元，23-业务处理单元，24-服务器数据库，25-网络协调器节点，26-网络终端节点，27-传感器组件。

具体实施方式

下面结合附图对本发明进行详细说明。

本发明提供的一种基于微服务架构的智能家居系统，由三部分组成：服务器、第三方无线传输设备群和传感器组件；传感器组件通过连接电路与无线传输设备相连形成无线网络节点，无线传输设备根据所使用的无线传输协议将传感器采集的数据发送至协调器，协调器与服务器使用串口相连，并将各无线网络节点的数据汇总后通过串口发送至服务器，服务器通过串口实时监听脚本将串口数据存入数据库以完成无线网络节点数据的汇总。

本发明传感器组件包括若干传感器，传感器可根据系统需求进行选择，本发明使用的传感器组件包括DHT11温湿度传感器，MQ2可燃气体传感器和ST188光敏传感器，各传感器分别通过连接电路与相应的无线传输模块相连用以收发系统监测的数据。

无线传输设备使用德州仪器的CC2530短距离无线传输模块，根据功能可将无线传输模块分为终端节点和协调器节点，终端节点与传感器直接相连，主要承担数据的发送任务，协调器节点是整个网络的中心节点，负责维护和更新整个网络，主要接收来自各个终端节点发送的环境数据，并将数据汇总打包通过串口发送至服务器。

服务器中运行串口监听脚本，将串口数据实时写入数据库中，为解决下位机数据采集周期不同而引起的某时刻数据缺失的问题，数据包使用多位校验码进行完整性验证，不同类型的环境数据使用不同的校验码验证，例如，温度数据以二进制“010”标识数据的开始，“101”标识数据的结束，湿度数据以二进制“100”标识数据的开始，“001”标识数据的结束。当所需数据齐全时，串口监听脚本对数据包进行处理，去掉验证码并加入时间信息后存储至数据库中。

参见图2，传感器组件27通过连接电路与第三方无线收发设备相连组成网络终端节点26，网络终端节点将采集到的环境数据发送至网络协调器节点25，网络协调器节点通过串口与服务器相连并向服务器周期性的发送汇总的数据包，服务器中运行的监听脚本对数据包进行完整性验证，并将符合要求的数据的存入服务器数据库24中。应用层方面，系统将业务解耦成多个功能单一且完整的微服务并将其部署在多个docker容器中形成业务处理单元23，不同微服务可通过服务通信单元22相互通信和协调，最终将处理结果通过HTTP协议返回客户端21页面。

参见图1，本发明实施例1提供一种基于微服务架构的智能家居服务系统的搭建方法，包括以下步骤：

S10、将第三方无线传输设备通过无线网络协议组网(本发明使用ZigBee协议)，根据环境要求可将设备组成星型网络或树状网络。当传输距离不超过50m时可将无线传输设备组成星型网络，即网络中包括协调器节点和终端节点，每一个终端节点只能和协调器节点进行通讯。如果需要在两个终端节点之间进行通讯必须通过协调器节点进行信息的转发。当传输距离超过50m时，可将设备组成树状网络，包括一个协调器节点以及一系列的路由节点和终端节点。协调器节点连接一系列的路由节点和终端节点，协调器的子节点的路由节点也可以连接多个路由节点和终端节点，由此组成多个层级。

S11、通过连接电路将传感器与无线收发设备相连，为了保持某一时刻监测数据的完整性，无线传输设备在将传感器监测数据发送前按照协议要求对数据进行打包并于数据包前后加入校验位。若无线传感网络为星型网络，则终端节点直接将数据包发送至协调器节点。若无线传感为树状网络，则终端节点将数据包发送至当前节点的父节点，并逐层将数据包发送至协调器节点。

S12、协调器节按照预设的时间周期将各终端节点采集到的数据包进行汇总和预处理，并通过串口与服务器连接，将汇总后的数据发送至服务器。

S13、服务器端建立数据库并运行串口监听脚本，串口监听脚本对串口接收到的数据进行预处理，即将数据包中存在的校验位去除，并将处理后的数据实时存入数据库中。

S14、在微服务的部署方面，本发明采用单一服务器，使用Docker+Spring cloud的方式搭建微服务架构。在服务器中完成docker的安装和配置；制作docker镜像；搭建私有docker仓库；解决部分私有仓库兼容性问题。在成功配置和上线docker容器后，便可在上线的docker容器中搭载一个或多个微服务，在这里，同种类型的服务具有相同的service id，但每一个服务都需配置不同的端口或ip地址，由此以来，每一个服务都可通过Restful API相互协调和调用并被唯一的URI标识。客户端21通过HTTP协议调用主服务，主服务通过负载均衡机制选择相应的微服务，若用户需要完成的业务需要多种服务协调完成，则服务间通过Restful API进行通信和调用，处理的结果通过HTTP协议返回至客户端21。

具体微服务的部署如下：

在系统应用层面，在服务注册中心注册主服务，并将该服务地址作为其他服务的注册地址，根据业务需求开发功能单一且完整的微服务(每一种服务可存在多个拷贝以完成负载均衡机制)。同时，在服务器端配置docker容器和负载均衡Zuul组件，将开发的微服务在docker容器中上线，并为每一个微服务配置不同的端口以便其他服务对此服务进行发现和调用(每一个docker容器可装入多个微服务)。之后，开发统一的Restful API，使每一个微服务均可被唯一的URI指定，并且服务之间可通过PUT、POST、DELETE与GET四种HTTP请求相互调用和通信，在服务间进行调用时，某微服务将待调用服务的service id写入请求，根据业务逻辑进行判断；若需要创建资源，如创建用户数据表以及相应的监测数据条目，则发送POST请求；若需要删除操作，如删除时间戳靠前的历史数据，则发送DELETE请求；若需要更新某中资源，如更新用户数据监测区间或修改用户密码，则发送PUT请求；若需要查看操作，如需获取某时间室内环境数据，则发送GET请求。待调用微服务采用Jason格式对返回数据进行封装，之后原微服务对请求进行处理，并将处理结果返回客户端页面。

完成在微服务的部署后，系统采用Zuul组件实现微服务的注册发现和负载均衡。微服务的注册和发现步骤如下：

在服务注册中心注册一个主服务，将该服务地址作为所有其他微服务的注册地址。其具体过程如下:

建立一个空的maven工程；创建服务注册中心，配置server.port来设定服务器端口号；开发微服务，配置server.client使得该服务能够使用服务注册服务器；将微服务注册地址设置为服务注册服务器地址。

根据系统需求开发多个功能单一且完整的微服务，每一类微服务单独开发，同一种服务可存在多个拷贝。

将微服务打包配置进入docker容器，根据系统需求每一个docker可配置多个微服务。

将所有开发的微服务注册在主服务地址下并配置负载均衡组件以完成服务的注册和发现。

定义Restful API，使服务间可以通过四种HTTP请求相互调用。

需要说明的是，每一种服务的拷贝数量由实际的用户请求数量和服务器性能决定，若用户体量较大，在某一时间内对同一种服务的请求次数较多，为保这一服务能够及时响应每一个用户请求，可对该服务建立多个拷贝。每一个拷贝具有相同的service id和相同的业务功能，在为新增服务配置完负载均衡组件Zuul并将这些服务分别上线后，若某一时间内对同一种服务的请求次数较多，系统便可根据负载均衡机制选择该服务的不同拷贝对用户进行响应。通过这种方法，可以极大程度的降低系统在高峰期的负载量。

另外，当用户所需业务逻辑比较简单，比如“显示温度”时，系统可直接调用温度显示服务对用户进行响应。当用户需求较为复杂，比如“当温度高于40℃时警报”时，单一服务无法满足该需求，需要多个服务相互协调完成，此时系统首先获取温度显示服务，若在安全范围内则返回用户安全信息，若温度超出安全范围，则温度显示服务需要调用警报服务，最终将温度信息和警报信息同时返回用户。由此可见，本系统虽然由功能单一且完善的微服务组成，但服务之间可以相互通信和调用以完成较为复杂的业务逻辑。

在服务器中安装负载均衡组件Zuul并通过修改配置文件完成对Zuul的配置；启动Zuul组件。需要注意的是，Zuul完成的是对docker容器形成小型服务器的负载均衡和反向代理机制，因此若同一docker容器中存在同种类型服务的多份拷贝，服务注册中心会同时调用多个相同的服务来处理同一请求，因而消耗不必要的系统资源，甚至产生严重的读写冲突问题。

本发明的基于微服务架构的智能家居服务系统具有用户自定的业务需求模式。

用户在第一次登陆系统界面时，可根据自身需求填写室内环境监控区域以及定制化的业务需求。

通常的，在根据用户需求搭建本发明智能家居系统后，本系统会为用户创建账号，生成用户id，用户密码，监控区域名称，设备id，设备类型、数据类型、监控项以及监测时间等数据并保存至数据库。之后，在该用户进行登陆时，登陆验证服务验证用户填写的登陆信息，若验证通过，登陆验证服务会将数据库存储的与该用户相关的数据信息送回前端页面，经过前端页面解析后将定制化的业务需求展现给系统用户。

参见图3，本发明的基于微服务架构的智能家居服务系统具有设备省电模式，设备实现省电模式的过程包括以下步骤。

S20、初始化网络节点。

S21、将终端设备设置为默认24小时工作模式。

具体的，由于本系统使用的第三方无线传输设备使用电池供电，对于实时性要求较高的场合需要频繁的数据收发操作，因此考虑到节点的寿命和网络的可用性，系统用户可在不需要监控的情况下登陆系统界面将设备设置为睡眠模式，当用户没有设定监测时间，则设置终端节点为默认全天开启状态。

S22、根据用户需求创建监测时间信息。

S23、将监测时间信息和对应设备ID存入用户数据表。

S24、在需要监控时间内唤醒对应设备，其余时间将设备置为睡眠模式。

本步骤中，系统支持用户设定监控时间段，当处于监控时间段时，系统将发送唤醒请求至服务器，服务器根据设备id选择需要唤醒的设备，并将设备id通过串口发送至网络协调器，协调器根据设备id进行解析，选择待唤醒的设备进行唤醒操作。

另外，当某设备电量低于安全阈值时，该设备发送数据包至协调器，协调器对该数据包进行解析并通过串口发送至服务器，串口监听脚本收到该数据后将相应设备id对应的状态信息更新为“低电量”信息以便向用户显示。

本发明的基于微服务架构的智能家居服务系统具有数据库更新删除模式。

系统会为每一个用户建立相应的数据表，而每一个用户可能对应多态设备，各台设备实时对室内环境信息进行监测，因此系统中存储的历史数据会随时间增加。当系统用户量较大时，数据量会变得更加庞大，因此数据库会因为存储过多无用数据而导致数据查询时间变慢，久而久之，系统对用户请求的响应时间也会增加。因此，本系统为每个用户数据表设定上限，系统周期性的检查该用户数据的个数，当该用户数据量达到上限时，系统调用数据删除服务并向后台发送数据删除指令，后台根据指令中删除数据的条目选择最先存入数据库的历史数据进行删除。通过这种方法，系统的数据查询速度和对用户请求的响应速度得到保证。

本发明的基于微服务架构的智能家居系统，微服务的部署和注册和发现是本发明的核心。

在系统的应用层方面，本发明采用单一服务器，使用Docker+Spring cloud的方式实现服务的注册发现和负载均衡机制。客户端通过HTTP协议调用主服务，主服务通过负载均衡机制选择相应的微服务，若用户需要完成的业务需要多种服务协调完成，则服务间通过Restful API进行通信和调用，处理的结果通过HTTP协议返回至客户端。本发明使用微服务架构开发的智能家居平台可以有效降低系统的耦合度，每一个微服务可以单独开发，单独部署甚至可以使用不同的语言进行开发，极大程度的减少了系统的维护和更新的成本。

本发明使用微服务架构开发的智能家居平台可以有效降低系统的耦合度，每一个微服务可以单独开发，单独部署甚至使用不同的语言进行实现，极大程度的减少了系统的维护和更新的成本。此外，这种微服务架构设计的物联网应用平台从应用层面解决了物联网设备异构的问题，其分布式、开放式的设计特性易于实现跨应用的交互，因此适用于对开放性、可扩展性有较高要求的物联网应用系统。

Claims (7)

1.一种基于微服务架构的智能家居系统，其特征在于，包括服务器、第三方无线传输设备群和传感器组件；其中，传感器组件通过连接电路与无线传输设备相连形成无线网络节点，无线传输设备根据所使用的无线传输协议将传感器采集的数据发送至协调器，协调器与服务器使用串口相连，并将各无线网络节点的数据汇总后通过串口发送至服务器，服务器通过串口实时监听脚本将串口数据存入数据库以完成无线网络节点数据的汇总；

传感器组件包括DHT11温湿度传感器，MQ2可燃气体传感器和ST188光敏传感器，各传感器分别通过连接电路与无线传输设备相连用以收发系统监测的数据；

无线传输设备CC2530短距离无线传输模块，根据功能将无线传输模块分为终端节点和协调器节点，终端节点与传感器相连，承担数据的发送任务，协调器节点是整个网络的中心节点，负责维护和更新整个网络，接收来自各个终端节点发送的环境数据，并将数据汇总打包通过串口发送至服务器；

服务器中运行串口监听脚本，将串口数据实时写入数据库中，数据包使用多位校验码进行完整性验证，不同类型的环境数据使用不同的校验码验证；当所需数据齐全时，串口监听脚本对数据包进行处理，去掉验证码并加入时间信息后存储至数据库中；采用单一服务器，使用Docker+Spring cloud的方式搭建微服务架构；完成在微服务的部署后，采用Zuul组件实现微服务的注册发现和负载均衡。

2.一种如权利要求1所述的基于微服务架构的智能家居系统的构建方法，其特征在于，包括以下步骤：

S10、将第三方无线传输设备通过无线网络协议组网，根据环境要求将无线传输设备组成星型网络或树状网络；

S11、通过连接电路将传感器与无线收发设备相连，无线传输设备在将传感器监测数据发送前按照协议要求对数据进行打包并于数据包前后加入校验位；若无线传感网络为星型网络，则终端节点直接将数据包发送至协调器节点；若无线传感为树状网络，则终端节点将数据包发送至当前节点的父节点，并逐层将数据包发送至协调器节点；

S12、协调器节按照预设的时间周期将各终端节点采集到的数据包进行汇总和预处理，并通过串口与服务器连接，将汇总后的数据发送至服务器；

S13、服务器端建立数据库并运行串口监听脚本，串口监听脚本对串口接收到的数据进行预处理，将数据包中存在的校验位去除，并将处理后的数据实时存入数据库中；

S14、采用单一服务器，使用Docker+Spring cloud的方式搭建微服务架构；完成在微服务的部署后，采用Zuul组件实现微服务的注册发现和负载均衡。

3.根据权利要求2所述的基于微服务架构的智能家居系统的构建方法，其特征在于，步骤S10中，当传输距离不超过50m时将无线传输设备组成星型网络，星型网络中包括协调器节点和终端节点，每一个终端节点只能和协调器节点进行通讯；如果在两个终端节点之间进行通讯时，通过协调器节点进行信息的转发；

当传输距离超过50m时，将无线传输设备组成树状网络，树状网络包括一个协调器节点以及一系列的路由节点和终端节点；协调器节点连接一系列的路由节点和终端节点，协调器的子节点的路由节点也可以连接多个路由节点和终端节点，由此组成多个层级。

4.根据权利要求2所述的基于微服务架构的智能家居系统的构建方法，其特征在于，步骤S14中，使用Docker+Spring cloud的方式搭建微服务架构的具体过程如下：

在服务器中完成docker的安装和配置，然后制作docker镜像，再搭建私有docker仓库；在成功配置和上线docker容器后，在上线的docker容器中搭载一个或多个微服务，同种类型的服务具有相同的service id，每一个服务都需配置不同的端口或ip地址，每一个服务都通过RestfulAPI相互协调和调用并被唯一的URI标识；客户端通过HTTP协议调用主服务，主服务通过负载均衡机制选择相应的微服务，若用户需要完成的业务需要多种服务协调完成，则服务间通过Restful API进行通信和调用，处理的结果通过HTTP协议返回至客户端。

5.根据权利要求4所述的基于微服务架构的智能家居系统的构建方法，其特征在于，在系统应用层面，在服务注册中心注册主服务，并将该服务地址作为其他服务的注册地址，根据业务需求开发功能单一且完整的微服务；同时，在服务器端配置docker容器和负载均衡Zuul组件，将开发的微服务在docker容器中上线，并为每一个微服务配置不同的端口以便其他服务对此服务进行发现和调用；然后，开发统一的Restful API，使每一个微服务均能够被唯一的URI指定，并且服务之间通过PUT、POST、DELETE与GET四种HTTP请求相互调用和通信。

6.根据权利要求2所述的基于微服务架构的智能家居系统的构建方法，其特征在于，步骤S14中，采用Zuul组件实现微服务的注册发现和负载均衡的具体过程如下：

建立一个空的maven工程；创建服务注册中心，配置server.port来设定服务器端口号；开发微服务，配置server.client使得该服务能够使用服务注册服务器；将微服务注册地址设置为服务注册服务器地址；

根据需求开发多个功能单一且完整的微服务，每一类微服务单独开发，同一种服务存在多个拷贝；

将微服务打包配置进入docker容器，根据系统需求每一个docker配置多个微服务；

将所有开发的微服务注册在主服务地址下并配置负载均衡组件以完成服务的注册和发现；

定义Restful API，使服务间通过四种HTTP请求相互调用。

7.根据权利要求2所述的基于微服务架构的智能家居系统的构建方法，其特征在于，该智能家居系统具有用户自定的业务需求模式、设备省电模式以及具有数据库更新删除模式。

Images