ThingsBoard架构

服务

ThingsBoard设计为：

• 扩展性：可水平扩展的平台使用领先的开源技术构建。

• 容错性：没有单点故障集群中的每个节点都是相同的。

• 健壮性：单个服务器节点可以根据使用情况处理以万级别的设备，集群可以处理数百万级别设备。

• 自定义：使用可自定义的部件和规则引擎节点可以轻松添加新功能。

• 持久化：永远不会丢失你的数据。

参见如下架构图及关键组件和相关接口。

通信

ThingsBoard提供了基于MQTT、HTTP、CoAP和LwM2M的基础API适用于你的设备应用程序/固件。

每个协议API都是由单独的服务器组件提供的并且是ThingsBoard“传输层”的一部分。

MQTT传输还提供网关API与多个设备建立连接获取传感器的数据。

传输从设备接收到消息后将被解析结果推送到持久的消息队列。

仅在消息队列确认了相应消息后才将消息传递给设备。

内核

ThingsBoard Core负责处理REST API调用和WebSocket订阅。

它还负责存储有关活动设备会话和监视设备连接状态。

ThingsBoard Core使用Actor来实现主要实体（租户和设备）的actor。

平台节点可以加入群集其中每个节点负责传入消息的某些分区。

规则引擎

ThingsBoard规则引擎是系统的心脏负责处理传入的消息。

规则引擎使用Actor来实现主要实体的actor：规则链和规则节点。

规则引擎节点可以加入集群，其中每个节点负责传入消息的某些分区。

规则引擎从队列中订阅传入的数据并且仅在处理完消息后才对其进行确认。

有多种策略可用于控制顺序或消息处理以及消息确认的标准， 请参阅提交策略和处理策略。

ThingsBoard规则引擎可能以两种模式运行：共享和隔离

在共享模式下规则引擎处理多个租户的消息。

在隔离模式下规则引擎处理特定租户的消息。

Web UI

ThingsBoard提供了一个使用Express.js框架编写的轻量级组件用于开发静态Web界页。

这些组件是完全无状态的，没有太多可用的配置。

静态Web界面包含应用程序加载后该应用程序将开始使用ThingsBoard核心提供的REST API和WebSockets API。

消息队列

ThingsBoard支持多种消息队列实现：Kafka、RabbitMQ、AWS SQS、Azure服务总线和Google发布订阅。

使用持久化和可伸缩的队列ThingsBoard可以实现积压和负载均衡。

我们在特定的队列实现上提供“抽象层”并维护两个主要概念：主题和主题分区。

一个主题可能具有可配置数量的分区由于大多数队列实现不支持分区因此我们使用topic + “.” + partition模式。

ThingsBoard消息生产者根据实体ID的哈希值确定使用哪个分区。

因此同一实体的所有消息总是被推送到同一分区。

ThingsBoard消息使用者使用Zookeeper进行协调，并使用一致性哈希算法确定每个使用者应订阅的分区列表。

在微服务模式下运行时每个服务还基于唯一的服务ID（只有一个分区）具有专用的“通知”主题。

ThingsBoard使用以下主题：

• tb_transport.api.requests: 发送通用API调用以检查从Transport到ThingsBoard核心的设备凭据。

• tb_transport.api.responses: 从ThingsBoard核心到Transport接收设备凭证验证结果。

• tb_core: 将消息从传输或规则引擎推送到ThingsBoard核心。消息包括会话生命周期事件属性和RPC订阅等。

• tb_rule_engine: 将消息从Transport或ThingsBoard核心推送到规则引擎。消息包括传入遥测、设备状态、实体生命周期事件等。

注意:所有主题属性（包括分区的名称和数量）都可以通过Thingsboard.yml或环境变量进行可配置从ThingsBoard3.4开始可以通过UI配置规则引擎队列请参阅文档。

注意:从2.5版开始我们已经从使用 gRPC切换到消息队列用于ThingsBoard组件之间的所有通信。

核心思想是牺牲少量的性能/延迟以支持持久可靠的消息传递和自动负载平衡。

部署

ThingsBoard支持本地部署和云部署并在AWS，Azure，GCE和私有数据中心运行超过5000台服务器用于生产环境同时完全可以在没有互联网访问的专用网络中良好运行。

模式

平台设计为可水平扩展并支持自动发现新的服务器（节点）集群中的所有节点都是相同的并且支持负载均衡所有请求都会被转发到所有的节点用来解决单点故障。

微服务

从ThingsBoard v2.2开始对平台进行了重构以支持微服务体系结构而且还能够以独立模式将其作为单体应用程序运行。

支持这两个选项都需要一些额外的编程工作，但是由于与各种现有安装的向后兼容性，这一点至关重要。

ThingsBoard始终被设计为可作为分布式应用程序运行但最初也被设计为单体应用程序。

这意味着在每个服务器节点上只有一个Java进程在运行该应用程序。

这些进程正在使用gRPC进行通信，并且服务发现是通过Zookeeper完成的。

该模型适用于许多安装，并且只需最少的支持工作，知识和硬件资源即可进行设置。

但是微服务架构还解决了一些挑战，这些挑战适用于更复杂的部署和使用场景。

例如运行一个多租户部署，其中需要更精细的隔离以防止：

如果需要高可用性或希望扩展到数百万台设备微服务是一种选择，适用于更复杂的部署和使用场景例如：运行多租户部署需要更加精细的数据隔离以防止：

• 不可预测的规则链配置错误；

• 不可预测的负载峰值；

• 由于固件错误，单个设备打开了数千个并发连接；

• 和许多其他情况。

请点击下面列出的链接以了解更多信息，然后选择合适的架构和部署选项：

• 单体：了解有关单体模式下部署、配置和运行ThingsBoard平台的更多信息。

• 微服务：了解有关微服务模式下部署、配置和运行ThingsBoard平台的更多信息。

数据库

ThingsBard使用数据库进行存储 实体设备，资产，客户，仪表板等）和遥测数据（属性，时间序列传感器读数，统计信息，事件）。 平台目前支持三种数据库选项：

• SQL：将所有实体和遥测存储在SQL数据库中，建议使用PostgreSQL数据库HSQLDB可用于本地开发和测试不建议将HSQLDB用于任何其他用途。

• NoSQL (已弃用)：将所有实体和遥测存储在NoSQL数据库中，建议使用Cassandra数据库。

• 混合：将所有实体存储在SQL数据库中，并将所有遥测存储在NoSQL数据库中。

• 混合 (PostgreSQL + Cassandra)：将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Cassandra数据库中。

• 混合 (PostgreSQL + TimescaleDB)：将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Timescale数据库中。

可以使用thingsboard.yml文件配置此选项有关更多详细信息，请参见数据库配置页面。

1
2
3
4
5
6
7
8
database:ts_max_intervals:"${DATABASE_TS_MAX_INTERVALS:700}"# Max number of DB queries generated by single API call to fetch telemetry recordsentities:type:"${DATABASE_ENTITIES_TYPE:sql}"# cassandra OR sqlts:type:"${DATABASE_TS_TYPE:sql}"# cassandra, sql, or timescale (for hybrid mode, DATABASE_TS_TYPE value should be cassandra, or timescale)# note: timescale works only with postgreSQL database for DATABASE_ENTITIES_TYPE.

中间件

ThingsBoard后端是用Java编写的但是我们也有一些基于Node.js的微服务。

ThingsBoard前端是基于Angular JS框架的SPA。

有关使用的第三方组件的更多详细信息请参见单体和微服务页面。