thingsboard微服务架构的优势特点及应用实践
在众多的开源物联网平台项目中，Thingsboard在体系架构先进性、功能完整性、文档完备性方面，应是首屈一指。但其自身存在的一些短板，直接影响到市场应用的普及。我们艾瑞博达团队，跟进ThingsBoard项目已达四年之久，对其代码和特性进行了深入研究，而且在项目应用中，对其进行了必要的改进和扩充。在此，我们将用一组系列文章，分享我们的实践经验。希望与感兴趣的业界同仁展开交流与合作。
1、优势特点
1.1、微服务架构
从V2.2.0开始支持微服务，逐渐将传输协议（MQTT、HTTP、CoAP）代理服务、规则引擎服务从核心服务中分离出来，保证在高并发接入情况下的分布式部署和性能调优。
1.2、Actor模型
Actor模型具有高并发、高容错的特点。
自从V2.5.2开始，为了提高执行效率，ThingsBoard摈弃了Akka的使用，采用Java自主开发了更高性能的Actor系统。其Actor体系架构如下图所示：
实现的Actor对象包括：
App Actor - 负责管理租户Actors，其实例常驻内存；
Tenant Actor - 负责管理租户设备和规则链Actors，其实例常驻内存；
Device Actor - 维护设备的状态: 活动的Sessions, 订阅, 侦听RPC 命令等。；
Rule Chain Actor - 处理接收的消息并分发给规则节点Actors，其实例常驻内存；
Rule Node Actor - 处理接收的消息，并将结果反馈给规则链, 其实例常驻内存。
1.3、规则引擎
Thingsboard仿效Node Red，自主开发的可视化规则引擎为消息处理提供了强大的功能支持。迄今，一些商业版的物联网平台均未见有相似的工具。
通过规则链的交互式配置，可以定义设备事件或数据的过滤、告警条件设置、跨系统联动控制、数据路由设定等业务逻辑，只需要编写简单Javascript脚本。
缺省提供了常用的功能节点。遇有特殊需求时，可动态扩充。
规则引擎主要应用场景包括：
在存储之前，将设备上行数据进行校验或修正；
将多个设备的数据复制到资产，以便进行聚合、关联计算；
基于预置条件，生成、刷新或清除告警信息；
基于预置条件，触发执行动作；
基于预置条件，触发对外部系统的REST API调用；
支持按预定制模板向指定用户发送邮件或短信息；
将数据转发到消息队列（MQ）中，第三方应用可以通过消息队列获取到设备上行数据；
将数据转发到流计算中，提供设备数据采集 + 流式计算的联合方案；
将数据转发到时序数据库，提供设备数据采集 + 结构化存储的联合方案。
1.4、数据可视化
Thingsboard提供了丰富的数据可视化Widget，包括：地图、仪表盘、卡片、图表等。
通过交互式挂接数据源，便可借助WebSocket实现数据展现的实时刷新。相比Grafana，具有更好的实时性。
1.5、多协议支持
ThingsBoard Server起初就提供了MQTT、HTTP、CoAP三种传输协议的服务端代理。近期发布的V3.30版本，又增加了LwM2M及SNMP协议的支持。
ThingsBoard Gateway是迄今为止，同类开源项目中接入协议支持最为丰富的网关。
ThingsBoard Gateway通过MQTT协议接入ThingsBoard Server，通过各种主流协议连接器接入现场设备、系统或数据。目前支持的协议包括：MQTT、HTTP(S)、OPC-UA、ModBus、BACnet、CAN、SNMP、BLE、ODBC等。针对特殊协议，也支持定制连接器。iRay.iot网关支持RPC请求，以实现反向控制。
ThingsBoard Gateway提供基于内存或本地文件两种方式的数据缓存机制，用于连接中断时，暂存数据，当连接恢复时，自动将数据上传到服务器。
ThingsBoard Server提供网关的远程配置管理服务，允许用户将配置脚本远程下发给指定网关。
2、不足之处
2.1、系统管理问题
ThingsBoard（CE）版的系统管理是针对远程设备管理平台的定位而设计的。每个租户对应一个设备厂商，一个厂商可以有多个客户，每个客户可以有多个用户。具体的设备管理是赋权给客户和用户的。这种管理机制不适合企业内部应用场景。而且缺乏灵活的授权控制功能，许多权限都写死在代码之中。
2.2、时序数据存储组织问题
ThingsBoard（CE）版迄今没有导入专业的时序数据库应用，用户可选择的只有PostgreSQL和Cassandra。虽然针对PostgreSQL引入了TimeScale插件，但由于其不是按照宽表的方式组织数据记录，TimeScale的优势根本发挥不出来。总之，这两种数据库不具备高效的数据吞吐能力。
而且，Thingsboard（CE）版在数据入库时，是将设备的多个遥测值拆分成不同的记录。不断增加了数据冗余量，而且非常不便于使用。
2.3、Asset的歧义性问题
ThingsBoard（CE）版引入了Asset（资产）的概念，这造成了严重的概念混淆，因为设备也是资产。它的Asset应理解为相关联的设备集合，而且这个集合也具有单个设备的特性。
2.4、告警条件配置问题
ThingsBoard（CE）版提供了交互式复杂告警条件配置功能，由于界面逻辑设计的问题，对于多条件配置容易出现混乱。
2.5、前端框架选用问题
ThingsBoard（CE）版采用Angular.js作为前端开发框架，对于普遍使用Vue.js的国内程序员，造成了严重的水土不服。直接影响到了其市场接受度。
2.5、重要功能闭源的问题
ThingsBoard团队为了获取经济收益，推出了闭源的专业版，某些重要的功能模块只存在于专业版之中，包括：
TCP/UDP协议代理：ThingsBoard（PE）版的TCP/UDP代理能处理以TCP/UDP报文方式上传的紧凑型数据格式；
计划任务：ThingsBoard（PE）版的计划任务（Schedule）模块能处理周期性任务或未来单次任务的计划编排与触发执行；
数据分析：ThingsBoard的数据分析（Trendz）模块是一个独立的商业软件，其提供的功能包括：
Ø 分析设备数据的图谱、轮廓及趋势
Ø 预断系统行为并提前做出响应
Ø 定义KPI因子，动态监察并发现其影响作用
Ø 监视设备停留在各种状态上的时间
Ø 以不同的维度过滤、组合、聚合时序数据
Ø 通过可视化仪表板展现分析结果
3、我们所做的改进
针对ThingsBoard（CE）版存在的问题，艾瑞博达团队利用自己的应用框架对其进行了整合封装，并进行了必要的功能扩充，显著提升了其性能和可用性。
详细参见：
https://iray.info/productinfo/885584.html。
关键的改进包括：
（1）应用框架
我们基于SpringCloud和SpringBoot开发了一套企业级的多租户应用框架，将ThingsBoard的租户与我们的租户相对应。完全接管了ThingsBoard的设备配置、组织机构和用户管理、角色与授权控制。
前端采用Vue.js，将ThingsBoard的复杂界面（规则引擎、仪表板等）用iFrame方式进行集成。
（2）导入TDEngine应用
经过严格比选，我们最终确定选用TDEngine替换Cassandra用于存储时序数据，数据记录以测控点为单位进行组织。有效提高了数据存储的效率。
（3）引入测控点和测控域概念
借鉴工控系统的理念，用测控点和测控域分别替换了ThingsBoard的设备（Device）和资产（Asset），同时导入了成套系统的概念，使复杂系统的数据组织更严谨和清晰。
（4）TCP/UDP支持
增加了TCP/UDP服务代理和紧凑格式数据解析与打包机制，使TCP/UDP协议支持成为可能。
（5）HMI的支持
在工业级物联网应用中，HMI是必要选项。我们通过集成开源项目Fuxa，实现了SVG图形交互界面设计和运行时监控执行的HMI引擎。
（6）改进的告警条件配置
使用思维导图的方式简化告警条件的展示，对复杂的告警条件也能直观快捷的配置，同时整个配置方式也更加具有逻辑性。
（7）规则节点新增与改造
新增了保存遥测数据到TDengine和类型转换节点，改造了发送短信节点，使其支持腾讯云、阿里云短信平台。
（8）视频监控支持
增加了视频流及云台Widget，支持在仪表板中添加实时视频流及云台控制功能。通过集成Kurento+OpenCV，实现了视频流的实时转码和识别计算。
（9）与资产管理和三维可视化系统相结合
在艾瑞博达的产品体系之中，将企业级的资产管理系统作为基础支撑，物联网和三维可视化是资产管理的智慧化辅助。通过将资产项与测控点动态数据和GIS/BIM三维空间数据进行动态绑定，从而实现资产管理的动态化、可视化和智能化。
（10）微服务监控
使用SkyWalking来进行服务的APM监控，提供了分布式追踪和上下文传输、应用、实例、服务性能指标分析、根源分析、应用拓扑分析、应用和服务依赖分析、慢服务检测功能。使用Prometheus+Grafana实现了服务器监控、应用监控、Postgresql数据库监控、Reids监控、Nacos监控、Prometheus自身监控功能。通过大量仪表板和告警通知，使整个平台的性能、健康的监控及运维直观方便。