架构

• ThingsBoard服务
• 消息队列
• 本地部署与云部署
• 独立与集群模式
• 整体与微服务架构
• SQL与NoSQL与混合数据库
• 编程语言和第三方

ThingsBoard服务

ThingsBoard设计为：

• 扩展性：可水平扩展的平台使用领先的开源技术构建。
• 容错性：没有单点故障集群中的每个节点都是相同的。
• 健壮性：单个服务器节点可以根据使用情况处理成千上万的设备。ThingsBoard集群可以处理数百万个设备。
• 自定义：使用可自定义的部件和规则引擎节点可以轻松添加新功能。
• 持久性：永远不会丢失你的数据。

下图屏示了系统的关键组件和相关接口。

ThingsBoard传输

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

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

MQTT传输还提供网关API供代表多个已连接设备和/或传感器的网关使用。

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

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

ThingsBoard核心

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

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

ThingsBoard核心在幕后使用Actor来实现主要实体（租户和设备）的actor。

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

ThingsBoard规则引擎

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

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

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

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

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

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

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

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

ThingsBoard Web UI

ThingsBoard提供了一个使用Express.js框架编写的轻量级组件，用于承载静态Web ui内容。

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

静态Web UI包含应用程序捆绑包加载后该应用程序将开始使用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或环境变量进行可配置。 我们计划在ThingsBoard 2.6或3.1中通过UI启用配置。

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

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

本地部署与云部署

ThingsBoard支持本地部署和云部署。

在全球运行着超过5000台ThingsBoard服务器之后，ThingsBoard在AWS，Azure，GCE和私有数据中心的生产环境中运行。

可以在完全没有互联网访问的专用网络中启动ThingsBoard。

独立与集群模式

该平台设计为可水平扩展，并支持自动发现新的ThingsBoard服务器（节点）。

集群中的所有ThingsBoard节点都是相同的，并且正在分担负载。

由于所有节点都相同，因此没有“主”或“协调器”过程，也没有单点故障。

你选择的负载均衡器可能会将来自设备，应用程序和用户的请求转发到所有ThingsBoard节点。

整体与微服务架构

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

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

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

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

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

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

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

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

• 不可预测的规则链配置错误；
• 不可预测的负载峰值；
• 由于固件错误，单个设备打开了数千个并发连接；
• 和许多其他情况。

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

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

SQL与NoSQL与混合数据库

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

• SQL-将所有实体和遥测存储在SQL数据库中。 ThingsBoard作者建议使用PostgreSQL这是ThingsBoard支持的主要SQL数据库。 HSQLDB具有最小的负载可用于本地开发、测试我们不建议将HSQLDB用于任何其他用途。
• NoSQL (已弃用)-将所有实体和遥测存储在NoSQL数据库中。 ThingsBoard作者建议使用Cassandra这是ThingsBoard目前支持的唯一NoSQL数据库。
• 混合-将所有实体存储在SQL数据库中，并将所有遥测存储在NoSQL数据库中。
• 混合 (PostgreSQL + Cassandra) - 将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Cassandra数据库中。
• 混合 (PostgreSQL + TimescaleDB) - 将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Timescale数据库中。

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

database:
  ts_max_intervals: "${DATABASE_TS_MAX_INTERVALS:700}" # Max number of DB queries generated by single API call to fetch telemetry records
  entities:
    type: "${DATABASE_ENTITIES_TYPE:sql}" # cassandra OR sql
  ts:
    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。

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