背景

最近几年公司规划了好几个工业物联网方面项目,由于前期团队较小，资源有限比较少考虑技术复用和抽象的问题，后面随着业务的不断发展，团队规模组件扩大，为了能够更好的支撑后期业务的快速迭代和输出，从整个研发体系出发不得不考技术沉淀，抽象复用的问题。

目标

根据公司业务特性，抽象提取出针对于设备连接、安全、数据分析和存储等能力，形成公司技术沉淀和后期业务快速构建的基础。提升开发效率。

分析

公司本身从事工业物联网行业，所涉及的解决方案基本都会涉及到设备的连接和监控，不同设备具备不同的数据协议，在考虑对这块能力进行抽象和提去的过程中，重点需要考虑设备从连接到上传，到云端数据存储和最终分析展现数据的整个环节。

针对具体使用场景分析如下:

场景一:

此处以企业中央空调为例:作为物业的管理人员或是作为空调的运维人员，希望能随时随地查看空调当前输出温度，本身运行温度，连续运行时长，耗电等及时性的状态。

场景二:

此处以城市智辉照明为例:作为城市管理人员想要监控到当前各个街道的路灯是否正常运行，或是否在运行。当大雾或是夜幕能够通过手工或是自动化的机制远程开启路灯

场景三:

此处再列举一个汽车例子:比如一辆小汽车，汽车使用者希望能时刻了解汽车的安全状态，什么时候该做保养，该加油，应该换刹车片，当前是否有行驶等。作为一个汽车维修技师在为车辆做检查时也需要能够知道汽车的重要部件是否有更换，运行状态，都希望能有一些数据以供维修参考。

以上的三个场景，理论上是绝大部分物联网解决方案需要能够支持，总结主要在于三方面:

1. 设备实时状态监控

2. 远程设备控制

3. 设备数据分析

思路

对于这部分能力的抽象主要从设备的连接开始到最后设备数据分析的整个链路做组件的抽象和提取，通过领域的边界的确定从而划分出对应的职责边界。

抽象

在这里通过前期的分析和多个项目业务共性的抽象,整体规划如下图所示:

​

在图中左边部分主要是下端传感器设备，传感器设备可能通过低功耗网络或是串口与工业网关进行通讯，在工业网关中去实现对应的应用程序，主要负责解析下端传感器传输回来的数据，并对数据做一定量的分析和计算，然后将数据传送到云端服务器，在云端经过一些列的处理和存储，最终通过图形化界面展示出设备的状态及分析数据。

前面主要描述了设备端到云端再到用户端的整个过程，接下来根据目前的思路从设备端抽象-云端抽象-用户端抽象进行分层介绍

设备端抽象介绍

设备端一般分为传感设备和路由设备，一般所为的传感设备即为不能直接联网的物理设备，但是他本身可以产生数据，比如温度传感器，烟感，热感，光感等。路由设备一般俗称路由器，本身具备上网能力，无论这个能力是通过网线还是通过无线蜂窝网等，总之最后能让设备连上网络，我们的设备端抽象更多是聚焦于路由端，设备端的抽象相对比较简答，主要是是抽象除了与云端建立通讯的SDK，此SDK朱啊哟负责与云端建立连接，接受消息，和对设备本身的集成应用提供对应的API接口。

云端抽象介绍

接下来主要针对云端处理做抽象的分析和介绍。

对于云端的处理由图可以看出来，主要分为5部分:Iot Hub、数据分析、设备管理、规则引擎和安全；接下来将对这五部分做整体介绍和说明

Iot Hub介绍

在每个物联网企业中大家对于Iot Hub的理解可能存在不一样的定义，在本设计中对于IOT Hub主要解决设备连接的问题，因此也是成为了所有设备连接的入口。

当然对于此部分的技术选型可以有很多，比如需要支持目前主流的物联网通讯协议如:MQTT,CoAP,HTTP,XMPP,SoAP等，在这些协议中目前主流的应该是MQTT，可能还有一些大型设备是基于XMPP，因此在设计之初更多是考虑支持MQTT和XMPP这两种，当然需要支持其他协议也是可以的，无非就是后期在Iot Hub增加对应的实现。理清楚了协议，就涉及到实现了，我们的实现并不一定要自己重头造轮子，而是更多的调研和借鉴行业主流的中间件技术，除非真心找不到适合自身需要的。目前对于MQTT主流的中间件,可参考官网推荐产品:

https://github.com/mqtt/mqtt.github.io/wiki/server-support,对于产品之间的对比如下

如上所示，对应的可选产品有很多，需要根据我们实际业务特性去选择，当然如果开源产品无法满足，可以考虑直接继承百度、阿里、Azure、AWS等大厂的IoT Hub形成自身能力，但为可能无法满足私有化部署的需求。

安全认证&权限策略

安全认证和权限策略，更多的是集成在Broker中,比如MQTT协议的服务器，对于连接的认证，对于Topic的发布和订阅的权限控制策略，包括黑白名单等均由此模块负责

数据分析

数据分析模块主要负责设备联网后的所有数据的上传，解析，存储和分析。目前抽象出的几个组件为消息路由、协议解析、多级存储、地图定位；根据实际业务需要适当选择搭配；

消息路由：主要负责将接受到的消息路由到对应的目标队列或渠道，可以是一个或多个，便于对数据的不同业务处理

协议解析: 主要负责解析从设备端上传过来的消息，可能上传过来的是二进制、Json、xml或自定义字符串等，这里主要是对消息进行解析

多级存储: 主要提供对于解析后的消息做存储功能，对于设备的消息可以支持多种存储方式，比如Mysql,MongoDB,TSDB等，便于系统在整合时的适配

地图定位: 主要负责解析或转换设备的地理位置，因为设备很多时候不能定位或是GPS不到导致定位数据缺失，此组件提供基于其他云厂商地图服务的基站定位，和地址编码转换功能，从而明确出设备的具体经纬度和地址描述

设备管理

设备管理模块主要负责设备注册、数字孪生、设备控制、OTA升级等,对设备整体做管理和控制。

设备注册: 设备注册负责设备连接前的添加注册，同时提供对外接口便于业务系统根据实际进行设备登记

数字孪生: 数字孪生是一个抽象概念，意为在云端构建一个与实体一致的设备模型，然后同步设备状态及动作，当需要操作设备或是查询设备信息时直接通过数字孪生设备进行查询或操作即可，形成与物理设备一一对应

设备控制: 设备控制主要负责下发消息给设备，与设备建立下达通道，确保通道畅通。同时记录操作日志，便于如其他模块集成

OTA升级：OTA升级引擎提供安全的OTA升级服务，基于补丁分发机制的云端智能推送策略，解决OTA升级过程中可能出现的如数据篡改，固件包伪造，链路劫持等安全风险。主要体现形态：自动升级、手动升级、强制升级三种模式，单台升级、批量升级、全网升级三种模式。技术上实现可通过连接通道，后端的定时任务和队列进行组合实现。

规则引擎

规则引擎主要在于解析设备协议，或是上传设备数据之后对于设备数据终端状态、时间进行过滤，提取出关键信息然后通过对外接口(如广播)进行公告。此处可通过集成第三方规则引擎再结合MQ消息队列或是http外部调用方式扩散特征数据。

用户端抽象

用户端抽象主要分为两方面，一方面是对于搜集到的设备数据在用户端的个性化呈现，另一方面是对于外部系统集成所能提供的开放接口，因此主要抽象出两个组件，自定义报表和OPEN-API

自定义报表

主要希望通过此组件能实现设备的实时展示，或是对分析过的数据进行结果呈现；此处可选实现方案可继承第三方的BI组件，或是开源的报表组件，如果前期对于数据暂时效果要求不高，推荐用grafana，这是一个不错的展示工具，支持多种数据源，可以多维度呈现不同的业务或设备数据。

OPEN-API

openApi模块更多的是为了对外暴露整个云端能力接口，在OPEN-API中需要能够提供接口鉴权，限流，容错，记录等功能，

总结：

以上是近期对于物理网整体架构抽象的思考，或许还不完美，但是已经比最初不知道如何做好了很多，知识的积累在于不断的学习、验证、总结再学习、验证、总结的无限循环。

最后，希望看到此文章的朋友能为大家带去思路和思考，也欢迎有不同见解的朋友一起探讨学习。