物联网设备网关系统架构设计

源 | 小象     文 | 文刀

0、写在前面的话

坦白来讲，我对物联网行业沉淀较少。

做软件出身的我，之前也学过一些单片机的知识，还有射频，ZigBee诸如此类的无线传输协议，因为那段时间“智能家居”火了，年少无知的我也跟着疯了，然后就没有然后了……

回想自己以前对技术的狂热，还是值得肯定的，但是那种近乎盲目的追求，就有点过犹不及了。

总之，学到的新技术或者新概念，需要及时去实践，去落地，长时间的搁置会导致最终一场空，这种到头来一无所有的感受，对自己的积极性也是一种打击。

1、背景介绍

如今，随着公司业务的不断扩大，有一批设备需要对接到我们的平台里，所以我尝试着去设计一下我司的设备网关系统架构。

目前接入的均为无线设备，设备与载体可随时移动，使用普通SIM卡流量，所以没有固定ip地址。至于设备网关1.0的核心功能，说来也简单，拢共分为三大部分：

① 设备安装/绑定。

② 设备数据实时上报

③ 设备运维

图1 设备网关核心功能

2、四层结构

让我们从另一个视角来看待设备网关：层次结构。

我梳理了一下整个业务过程，追踪了一遍整个数据流向，于是乎很容易就得出了如下的四层结构图：

图2 设备网关四层结构

整个层次结构自底向上依次为数据层、控制层、应用层、表现层，该层次结构也成为了我之后设计系统架构的指导思想。

现在对每个层次做一个简单的介绍：

• 数据层。处于底层，整个系统的数据源头，很明显是一个最基础的层次。

• 控制层。这是一个承上启下的关键层次，最主要的功能是指令的解析，以及指令的收发。

• 应用层。亦可称之为业务层，这个层次与系统的业务逻辑是紧密相关的，一些业务的实现都将在这里得以发挥。对上承接的是表现层，进而可以通过控制层对设备进行指令的收发，对下接入的是控制层，可以获取设备相关数据提交给表现层。

• 表现层。亦可称之为交互层，是人机交互，数据可视化的切入点。不难看出，这个层次是直接与人打交道的，所以在满足业务需求的同时，需要设计得足够人性化才行。

通过上述的介绍，结合层次结构图，不难得出：数据层和控制层是业务无关的，我们可以统称为「协议层」，而应用层和表现层是业务相关的，我们可以统称为「系统层」。整个层次结构相互独立而又彼此相连，达到了弱耦合的目的。

3、架构演进(level-1)

做出整个架构也是一个很痛苦的过程，唯恐有考虑不周的地方，导致今后会不断踩坑。也非常感谢在这个过程中给我提供帮助和建议的业内人士，在他们的指点下，我才有了更多的灵感。

至于所谓的IoT体系结构，也并没有完全遵循。整个业务场景也不像是一个非常标准的物联网，所以给自己的要求不是很高，设计出来的架构堪用就行。

首先，我们从一个较高的视角去看待，整个架构是这样子的：

图3 设备网关系统架构(level-1)

从图中不难看出，整个设备网关存在4个关键角色。

• 设备以及设备组成的群组(Device Group)，是最基础的角色，属于数据层。考虑到今后可能会对设备做精细化管理，所以会按一定的规则（比如地域，组织）对设备进行分组，这部分设计在前期体现得不是很明显。

• 中控平台(Center Controller)，对应的是控制层。这个角色的主要工作有数据采集，设备指令的收发等，值得注意的是，接入到系统里面的设备厂商可能不止一家，设备种类也是形形色色，报文协议也不尽相同，因此中控平台应该被设计成「对设备类型不敏感」的，以便提升中控平台的兼容性，可扩展性，以及可用性。

• 业务处理器(Biz Processor)，对应的是应用层（业务层）。这个角色集中体现了系统的业务需求，包括设备运维监控，数据分析以及持久化，日志分析，当然，这也是建立在中控平台的基础之上。

• 设备管理系统(Management System)，对应的是表现层。这个角色是直接面向终端用户的，是一个可操作的人机交互平台，该平台可以通过业务处理器控制整个数据链条。因为是整个架构的最高层级，通过对底层数据的有效整合，想象空间还是很大的。

以上就是设备网关架构的Level-1，紧接着我们再更深入的剖析整个架构，进入Level-2。

4、架构演进(level-2)

这部分内容，我们深入到四个角色的内部，窥探其中的结构组成。

1) 设备以及设备群组。这里我们将引入一个叫作「子设备」的概念，即一个设备对象下会再附属若干个设备，我们称之为「子设备」。当然，一个设备也可能没有子设备，依实际情况而定。

举个例子： 以一扇门作为一个设备，那么密码锁，锁舌，红外探头都可以是子设备; 再比如地震监测的探针，就是一个独立的设备，下属没有子设备。

图4 「子设备」概念

这样设计的目的是为了能够更精细化地对接入的设备进行控制，进可控制单个子设备，退可控制整个大设备。此外，对于平台内的所有大小设备，都不会直接相互进行通信，都是直接与中控平台打交道的。

2) 中控平台。我把这个角色定位为一种中间件，如下是中控平台的组件图：

图5 中控平台组件图

整个中控平台由八大组件构成，下面做一个简单的介绍。

• 连接器（Connector）。这个组件是控制层与数据层的数据传输渠道，维护着中控平台和各个设备的数据连接，数据传输连接都是基于TCP/IP协议。

• REST API。中控平台作为协议层与系统层的枢纽，对下层提供了连接器，对上层则提供了RESTful接口。因为设备网关将会使用微服务架构风格，所以使用的是REST API，暂不考虑其他的远程调用方式。

• 消息队列（Message Queue）服务。主要是解决应用耦合，异步消息，流量削锋等问题，最终实现高性能，高可用，可伸缩和最终一致性架构，有利于实现协议层与系统层准实时通信。

• 协议解析引擎（Protocol Parser）。这个组件很好理解，因为要适配不同的源设备，不同的设备厂商，协议规范是不一样的，需要通过协议解析引擎进行转换并在系统内形成规范。这部分工作对上层系统完全透明，只需要根据系统内的规范进行数据交互即可。所以，协议的解析是双向的，由内向外，以及由外而内。

• 指令执行引擎（Command Executor）。在这个组件中会维护一份最新的「指令集」，每条指令都有特定的功能，依靠协议解析引擎，对应到不同的设备上的不同功能。

• 数据采集器（Data Collector）。顾名思义，这个组件的主要任务是收集来自设备的所有数据，配合日志服务进行记录。数据采集器大致可以分为两类：实时性和非实时性，根据业务需求响应不同时效性的采集器。

• 日志服务（Logger Service）。这部分记录的日志有两种类型：数据型，设备型。日志的存储形态不在本篇范畴，这里着重阐述一下这两类数据。
   - 数据型日志记录的是流经控制层的数据，分为三种：
      ① 源数据，亦可称之为「裸数据」，这一部分数据没有经过任何的加工，从各个设备直出；
      ② 结构化数据，这部分数据是最接近业务数据的，对源数据进行了粗加工形成的；
      ③ 业务数据，根据系统的业务需求，对结构化数据做了进一步整合和加工形成的。
  - 设备型日志记录的是接入平台里的设备相关的数据，分为两种：
      ① 设备状态，记录的是设备状态流数据；
      ② 指令收发，记录的是中控平台对设备指令的收发数据。

• 管理工具套件（Management Toolkit）。这部分可以认为是中控平台的增值服务，优先级最低，不过想象的空间也是很大的。我打算将其设计成一个可响应Terminal命令的服务，比如获取当前连接数，最大连接数是多少，指令集配置，发送指令给设备等等。

3) 业务处理器，这个是与业务相关的角色，可以根据实际业务需求去设计。我在设计业务处理器的时候，是以设备为中心的，再去扩充其他功能。如下是一张业务处理器的拓扑图，具体的业务需求就不再展开叙述了。

图6 业务处理器拓扑图

4) 设备管理系统(Management System)，这部分我认为要做到两个「可视化」：数据可视化，设备可视化。「数据可视化」比较好理解，就是数据的整合及其图形化表示，当然，数据的来源可以是实时的，也可以是离线加工过的，这个业界都有成熟的解决方案。还有一个就是「设备可视化」，这个主要是给普通用户一个比较友好的操作体验，将设备具象化，点击不同的按钮可以触发其对应的功能。当然，对于专家用户，也可以提供站内Terminal，直接使用命令与设备进行交互。

图3 设备管理系统两个「可视化」

5、总结

整篇文章阐述了设备网关的四层结构，并分两个层面深入分析设备网关的系统架构。通篇没有涉及具体技术细节，因为这是技术架构层面的内容了，定当另起新篇阐述之。

希望能对你有所帮助！

THANKS！

-END-