欢迎来到友道创新学院!
咨询电话:010-59519886
电路设计热门培训内容之物联网设备网关系统架构设计


1、背景介绍

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

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

① 设备安装/绑定。

② 设备数据实时上报

③ 设备运维


2、四层结构

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

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

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

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

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

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

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

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

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


3、架构演进(level-1)

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

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


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

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

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

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

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


4、架构演进(level-2)

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

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

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

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


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

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

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

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

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

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

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

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

日志服务(Logger Service)。这部分记录的日志有两种类型:数据型,设备型。日志的存储形态不在本篇范畴,这里着重阐述一下这两类数据。

- 数据型日志记录的是流经控制层的数据,分为三种:

① 源数据,亦可称之为「裸数据」,这一部分数据没有经过任何的加工,从各个设备直出;

② 结构化数据,这部分数据是最接近业务数据的,对源数据进行了粗加工形成的;

③ 业务数据,根据系统的业务需求,对结构化数据做了进一步整合和加工形成的。

- 设备型日志记录的是接入平台里的设备相关的数据,分为两种:

① 设备状态,记录的是设备状态流数据;

② 指令收发,记录的是中控平台对设备指令的收发数据。

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

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

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


5、总结

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


立即咨询有惊喜哦 !