开源物联网平台thingsBoard可用性探讨

开源物联网平台开源物联网平台 ThingsBoardThingsBoard（（CECE 版）可用版）可用 性探讨性探讨 在众多的开源物联网平台项目中，Thingsboard 在体系架构先进性、功能完 整性、文档完备性方面，应是首屈一指。但其自身存在的一些短板，直接影响到 市场应用的普及。我们艾瑞博达团队，跟进 ThingsBoard 项目已达四年之久，对 其代码和特性进行了深入研究，而且在项目应用中，对其进行了必要的改进和扩 充。在此，我们将用一组系列文章，分享我们的实践经验。希望与感兴趣的业界 同仁展开交流与合作。 1 1、优势特点、优势特点 1.11.1、微服务架构、微服务架构 从 V2.2.0 开始支持微服务，逐渐将传输协议（MQTT、HTTP、CoAP）代理服 务、 规则引擎服务从核心服务中分离出来，保证在高并发接入情况下的分布式部 署和性能调优。 i Ray 艾瑞博达 1.21.2、、ActorActor 模型模型 Actor 模型具有高并发、高容错的特点。 自从 V2.5.2 开始，为了提高执行效率，ThingsBoard 摈弃了 Akka 的使用，采 用 Java 自主开发了更高性能的 Actor 系统。其 Actor 体系架构如下图所示 实现的 Actor 对象包括 ◼ App Actor - 负责管理租户 Actors，其实例常驻内存； i Ray 艾瑞博达 ◼ Tenant Actor - 负责管理租户设备和规则链 Actors， 其实例常驻内存； ◼ Device Actor - 维护设备的状态 活动的 Sessions, 订阅, 侦听 RPC 命令等。； ◼ Rule Chain Actor - 处理接收的消息并分发给规则节点 Actors，其实 例常驻内存； ◼ Rule Node Actor - 处理接收的消息，并将结果反馈给规则链, 其实例 常驻内存。 1.31.3、规则引擎、规则引擎 Thingsboard 仿效 Node Red，自主开发的可视化规则引擎为消息处理提供了 强大的功能支持。迄今，一些商业版的物联网平台均未见有相似的工具。 通过规则链的交互式配置， 可以定义设备事件或数据的过滤、 告警条件设置、 跨系统联动控制、数据路由设定等业务逻辑，只需要编写简单 Javascript 脚本。 缺省提供了常用的功能节点。遇有特殊需求时，可动态扩充。 规则引擎主要应用场景包括 ◼ 在存储之前，将设备上行数据进行校验或修正； ◼ 将多个设备的数据复制到资产，以便进行聚合、关联计算； ◼ 基于预置条件，生成、刷新或清除告警信息； ◼ 基于预置条件，触发执行动作； ◼ 基于预置条件，触发对外部系统的 REST API 调用； ◼ 支持按预定制模板向指定用户发送邮件或短信息； ◼ 将数据转发到消息队列（MQ）中，第三方应用可以通过消息队列获取到 设备上行数据； i Ray 艾瑞博达 ◼ 将数据转发到流计算中，提供设备数据采集 流式计算的联合方案； ◼ 将数据转发到时序数据库，提供设备数据采集 结构化存储的联合方 案。 1.41.4、数据可视化、数据可视化 Thingsboard 提供了丰富的数据可视化 Widget， 包括 地图、 仪表盘、 卡片、 图表等。 通过交互式挂接数据源，便可借助 WebSocket 实现数据展现的实时刷新。相 比 Grafana，具有更好的实时性。 1.51.5、多协议支持、多协议支持 ThingsBoard Server 起初就提供了 MQTT、HTTP、CoAP 三种传输协议的服务 端代理。近期发布的 V3.30 版本，又增加了 LwM2M 及 SNMP 协议的支持。 ThingsBoard Gateway 是迄今为止，同类开源项目中接入协议支持最为丰富 的网关。 i Ray 艾瑞博达 ThingsBoard Gateway 通过 MQTT 协议接入 ThingsBoard Server，通过各种主流 协议连接器接入现场设备、 系统或数据。 目前支持的协议包括 MQTTMQTT、、 HTTPSHTTPS、、 OPCOPC- -UAUA、、ModBusModBus、、BACnetBACnet、、CANCAN、、SNMPSNMP、、BLEBLE、、ODBCODBC 等。针对特殊协议，也支持定 制连接器。iRay.iot 网关支持 RPC 请求，以实现反向控制。 ThingsBoard Gateway 提供基于内存或本地文件两种方式的数据缓存机制， 用于连接中断时，暂存数据，当连接恢复时，自动将数据上传到服务器。 ThingsBoard Server 提供网关的远程配置管理服务，允许用户将配置脚本远 程下发给指定网关。 2 2、、不足之处不足之处 2.12.1、系统管理问题、系统管理问题 ThingsBoard （CE） 版的系统管理是针对远程设备管理平台的定位而设计的。 每个租户对应一个设备厂商，一个厂商可以有多个客户，每个客户可以有多个用 户。 具体的设备管理是赋权给客户和用户的。这种管理机制不适合企业内部应用 场景。而且缺乏灵活的授权控制功能，许多权限都写死在代码之中。 2.22.2、时序数据存储组织问题、时序数据存储组织问题 ThingsBoard（CE）版迄今没有导入专业的时序数据库应用，用户可选择的 只有 PostgreSQL 和 Cassandra。虽然针对 PostgreSQL 引入了 TimeScale 插件， 但由于其不是按照宽表的方式组织数据记录，TimeScale 的优势根本发挥不出来。 总之，这两种数据库不具备高效的数据吞吐能力。 i Ray 艾瑞博达 而且，Thingsboard（CE）版在数据入库时，是将设备的多个遥测值拆分成 不同的记录。无端增加了数据冗余量，而且非常不便于使用。 2.32.3、、AssetAsset 的歧义性问题的歧义性问题 ThingsBoard（CE）版引入了 Asset（资产）的概念，这造成了严重的概念混 淆，因为设备也是资产。它的 Asset 应理解为相关联的设备集合，而且这个集合 也具有单个设备的特性。 2.42.4、告警条件配置问题、告警条件配置问题 ThingsBoard（CE）版提供了交互式复杂告警条件配置功能，由于界面逻辑设 计的问题，对于多条件配置容易出现混乱。 2.52.5、前端框架选用问题、前端框架选用问题 ThingsBoard （CE） 版采用 Angular.js 作为前端开发框架， 对于普遍使用 Vue.js 的国内程序员，造成了严重的水土不服。直接影响到了其市场接受度。 2.52.5、重要功能闭源的问题、重要功能闭源的问题 ThingsBoard 团队为了获取经济收益，推出了闭源的专业版，某些重要的功 能模块只存在于专业版之中，包括 ◼ TCP/UDP 协议代理 ThingsBoard （PE） 版的 TCP/UDP 代理能处理以 TCP/UDP 报文方式上传的紧凑型数据格式； ◼ 计划任务ThingsBoard（PE）版的计划任务（Schedule）模块能处理周期 性任务或未来单次任务的计划编排