源 | 小象 文 | 文刀
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）。在这个组件中会维护一份最新的「指令集」，每条指令都有特定的功能，依靠协议解析引擎，对应到不同的设备上的不同功能。
