物联网平台-ThingsBoard架构

ThingsBoard架构

ThingsBoard架构
ThingsBoard服务
消息队列太棒了！
内部部署与云部署
独立模式与群集模式
单片与微服务体系结构
SQL vs NoSQL vs混合数据库方法
程序设计语言与第三方
ThingsBoard服务
木板设计为：

可扩展：水平可扩展平台，使用领先的开源技术构建。
容错：没有单点故障，群集中的每个节点都是相同的。
强健高效：根据使用情况，单个服务器节点可以处理数万甚至数十万个设备。可以处理数以百万计的设备。
耐用的：永远不要丢失数据。ThingsBoard支持各种队列实现，以提供极高的消息持久性。
可定制的：使用可自定义的小部件和规则引擎节点可以轻松添加新功能。
下图显示了它们提供的关键系统组件和接口。让我们穿过它们。

ThingsBoard Transports

木板提供MQTT ,超文本传输协议和CoAP可用于设备应用程序/固件的基于API。每个协议api都由一个单独的服务器组件提供，是ThingsBoard“传输层”的一部分。MQTT传输还提供网关API由表示多个连接设备和/或传感器的网关使用。

一旦传输接收到来自设备的消息，它将被解析并推送到持久消息队列. 只有在消息队列确认了相应的消息之后，才会向设备确认消息传递。

ThingsBoard Core

板负责处理REST API呼叫和WebSocket订阅。它还负责存储有关活动设备会话和监视设备的最新信息连接状态.ThingsBoard核心在引擎盖下使用Actor系统为主要实体（租户和设备）实现Actor。每个集群的传入节点都可以加入到特定的集群节点中，其中每个节点都可以负责加入。

ThingsBoard规则引擎

ThingsBoard规则引擎是系统的核心，负责处理传入的数据信息规则引擎使用Actor系统来实现主要实体的Actor：规则链和规则节点，规则引擎节点可以加入集群，每个节点负责传入消息的特定分区。

规则引擎订阅来自队列的传入数据馈送，并且仅在消息被处理后才确认该消息。有多种消息处理策略或消息处理准则提交策略和处理策略更多细节

共有两种发动机工作模式：独立发动机。在共享模式下，规则引擎处理属于多个租户的消息。在隔离模式下，可以将规则引擎配置为仅处理特定租户的消息。

ThingsBoard Web UI

ThingsBoard提供了一个使用Express.js框架编写的轻量级组件，用于承载静态web ui内容。这些组件是完全无状态的，没有太多可用的配置。静态web UI包含应用程序包。加载后，应用程序开始使用ThingsBoard核心提供的restapi和WebSockets API。

消息队列太棒了！
ThingsBoard支持多种消息队列实现：Kafka、RabbitMQ、AWS SQS、Azure Service Bus和Google Pub/Sub。我们计划在将来扩展此列表。使用持久和可扩展的队列允许ThingsBoard实现背压和负载平衡。在峰值负载的情况下，背压非常重要。
我们在特定队列实现上提供“抽象层”，并维护两个主要概念：主题和主题划分。一个主题可以有可配置的分区数量。由于大多数队列实现不支持分区，所以我们使用主题“.”分区图案

ThingsBoard消息生产者根据实体id的哈希决定使用哪个分区。因此，同一实体的所有消息总是被推送到同一个分区。ThingsBoard消息使用者使用Zookeeper进行协调，并使用一致的哈希算法确定每个使用者应订阅的分区列表。在微服务模式下运行时，每个服务还有一个专用的“通知”主题，该主题基于只有一个分区的唯一服务id。

ThingsBoard使用以下主题：

tb_transport.api.请求：发送通用API调用以检查从传输到ThingsBoard Core的设备凭据。
tb_transport.api.响应：接收从ThingsBoard Core到传输的设备凭据验证结果。
结核核心：将消息从传输或规则引擎推送到ThingsBoard核心。消息包括会话生命周期事件、属性和RPC订阅等。
tb_rule_引擎：将消息从传输或ThingsBoard核心推送到规则引擎。接收到的实体、事件、遥测设备等。
注：所有主题属性（包括分区的名称和数量）都是可配置通过thingsboard.yml或环境变量。我们计划在ThingsBoard 2.6和/或3.1中通过UI启用配置。

注：从2.5版开始，我们已经从使用gRPC公司到消息队列用于板组件之间的所有通信。其主要思想是牺牲较小的性能/延迟代价，以支持持久可靠的消息传递和自动负载平衡。

内部部署与云部署
ThingsBoard支持内部部署和云部署。Azure的所有服务器都在私有网络上运行，所有这些服务器都不可能在互联网上运行。

独立模式与群集模式
平台设计为可水平扩展，并支持自动发现新的板服务器（节点）。集群内的所有ThingsBoard节点都是相同的，并且共享负载。由于所有节点都是相同的，因此没有“主”或“协调器”进程，也没有单点故障。您选择的负载平衡器可以将来自设备、应用程序和用户的请求转发到所有ThingsBoard节点。

单片与微服务体系结构
从ThingsBoard v2.2开始，可以将平台作为一个单片应用程序或一组微服务运行。支持这两个选项需要一些额外的编程工作，但是，由于向后兼容各种现有的安装是至关重要的。

大约80%的平台安装仍在使用单片模式，这是因为安装所需的支持工作、知识和硬件资源最少，且维护工作量较低。

但是，如果您确实需要高可用性，或者希望扩展到数百万台设备，那么微服务是一个不错的选择，还有一些挑战可以通过microservices架构来解决，并适用于更复杂的部署和使用场景。例如，运行多租户部署时，需要更精细的隔离来防止：

负载不可预测；
不可预测的规则链错误配置；
单个设备由于固件错误打开了1000个并发连接；
还有很多其他的案子
请访问以下链接以了解更多信息，并选择正确的体系结构和部署选项：

单片：了解有关部署、配置和运行ThingsBoard平台的更多信息。
微型服务：了解有关在microservices模式下部署、配置和运行ThingsBoard平台的更多信息。
SQL vs NoSQL vs混合数据库方法
ThingsBoard使用数据库存储实体（设备、资产、客户、仪表板等）和遥测数据（属性、时间序列传感器读数、统计信息、事件）。平台目前支持三种数据库选项：

SQL语言-将所有实体和遥测数据存储在SQL数据库中。ThingsBoard的作者建议使用PostgreSQL，这是ThingsBoard支持的主要SQL数据库。可以将HSQLDB用于本地开发。我们不建议使用HSQLDB除了运行测试和启动具有最小可能负载的dev实例之外的任何操作。
NoSQL（已弃用）-将所有实体和遥测数据存储在NoSQL数据库中。ThingsBoard的作者建议使用Cassandra，这是ThingsBoard目前唯一支持的NoSQL数据库。请注意，由于NoSQL对事务和“连接”的许多限制，该选项被弃用，而倾向于混合方法，这是为了启用对物联网实体的高级搜索所必需的。
混合动力（PostgreSQL Cassandra）-将所有实体存储在PostgreSQL数据库中，timeseries数据存储在Cassandra数据库中。
混合（PostgreSQL TimescaleDB）-将所有实体存储在PostgreSQL数据库中，将timeseries数据存储在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 9框架的SPA。看到了吗单片和微型服务有关使用的第三方组件的详细信息。