ThingsBoard服务
ThingsBoard的设计目标：
- 扩展性：基于领先开源技术构建的水平扩展平台。
- 容错性：无单点故障，集群中每个节点完全对等。
- 健壮性：单服务器节点可根据场景支撑数万甚至数十万台设备，集群可承载数百万台设备。
- 持久化：永不丢失数据。ThingsBoard支持多种队列实现，提供极高的消息持久化保障。
- 自定义：通过可定制的组件和规则引擎节点，轻松扩展新功能。
下图展示了系统核心组件及其提供的接口，下面逐一介绍。
ThingsBoard传输层
ThingsBoard提供基于MQTT、HTTP、CoAP和LwM2M的API，供设备应用或固件使用。 各协议API由独立服务组件实现，共同构成ThingsBoard「传输层」。 MQTT传输还提供网关API，供代表多台设备/传感器的网关使用。
传输层收到设备消息后解析，并推入持久化消息队列。 仅在消息队列确认处理该消息后，才会向设备确认消息投递。
ThingsBoard Core
ThingsBoard Core负责处理REST API调用和WebSocket订阅。 还负责存储活跃设备会话的最新信息，并监控设备连接状态。 ThingsBoard Core底层采用Actor模型，为租户、设备等主要实体实现Actor。 平台节点可加入集群，每个节点负责处理部分消息分区。
ThingsBoard规则引擎
ThingsBoard规则引擎是核心，负责处理入站消息。 规则引擎底层采用Actor模型，为规则链和规则节点等实体实现Actor。 规则引擎节点可加入集群，每个节点负责处理部分消息分区。
规则引擎订阅队列的数据流，仅在处理完成后才确认消息。 可通过多种策略控制消息处理顺序及确认条件，详见提交策略和处理策略。
ThingsBoard规则引擎支持两种模式：共享与隔离。共享模式下处理多租户消息。 隔离模式下，可仅处理特定租户配置集中租户的消息。
ThingsBoard Web UI
ThingsBoard提供基于Express.js的轻量组件，用于托管静态Web UI。 该组件完全无状态，配置较少。 静态Web UI包含应用包。加载后会通过ThingsBoard Core提供的REST API和WebSockets API与平台通信。
ThingsBoard消息队列
ThingsBoard支持两种消息队列：Kafka和In-Memory。
- Kafka：广泛使用的分布式持久化消息队列，适合大数据量场景，适用于需要高吞吐、高可用和可扩展性的生产环境。
- In-Memory：轻量、快速的队列实现，适用于测试、小规模或开发环境，消息存于内存，优先考虑速度而非持久化。
使用持久化、可扩展的Kafka队列可实现背压和负载均衡。峰值负载下背压尤为重要。 我们在具体队列实现之上提供抽象层，并维护两个核心概念：topic与topic partition。 单个topic可有可配置数量的分区。因多数队列实现不支持分区，我们采用topic + “.” + partition模式。
ThingsBoard消息生产者根据实体id的哈希选择分区。 因此，同一实体的所有消息始终写入同一分区。 消息消费者通过Zookeeper协调，使用一致性哈希确定每个消费者订阅的分区列表。 微服务模式下，各服务还拥有基于唯一服务id的专用「Notifications」topic，且仅有一个分区。
ThingsBoard使用以下topics：
- tb_transport.api.requests：传输层向Core发送通用API调用以校验设备凭据。
- tb_transport.api.responses：传输层从Core接收设备凭据校验结果。
- tb_core：将传输层或规则引擎的消息推送给Core，包括会话生命周期、属性与RPC订阅等。
- tb_rule_engine：将传输层或Core的消息推送给规则引擎，包括遥测、设备状态、实体生命周期等。
本地部署与云部署
ThingsBoard支持本地和云部署。 全球有超过5000台ThingsBoard服务器在生产环境运行，包括AWS、Azure、GCE及私有数据中心。 可在完全无互联网访问的私有网络中部署ThingsBoard。
单体与集群模式
平台支持水平扩展，并支持自动发现新的ThingsBoard节点。 集群内各节点等同，共同分担负载。 因节点相同，不存在「主节点」或「协调进程」，也无单点故障。 负载均衡器可将设备、应用和用户的请求转发到任意ThingsBoard节点。
单体与微服务架构
自ThingsBoard v2.2起，平台可以单体应用或微服务组形式运行。 兼顾两种模式需要额外开发，但为保证与既有部署的兼容性，这是必要的。
约80%的部署仍使用单体模式，因其对运维、知识和硬件要求较低，维护简单。
若需高可用或要扩展到数百万设备，建议采用微服务架构。 微服务还能应对更复杂部署和使用场景中的问题，例如多租户部署中需要更细粒度隔离以应对：
- 不可预知的负载峰值；
- 不可预知的规则链配置错误；
- 因固件缺陷导致单设备建立数千并发连接；
- 以及其他类似情况。
请参考以下链接选择合适架构与部署方式：
SQL、NoSQL与混合数据库方案
ThingsBoard使用数据库存储 实体（设备、资产、客户、仪表盘等）及 遥测数据（属性、时序、统计、事件）。 平台当前支持三种数据库方案：
- SQL：将实体与遥测均存储于SQL数据库。推荐使用PostgreSQL，这是ThingsBoard主要支持的SQL数据库。 本地开发可使用HSQLDB。不建议将HSQLDB用于测试和极低负载开发实例以外的场景。
- Hybrid（PostgreSQL + Cassandra）：实体存于PostgreSQL，时序数据存于Cassandra。
- Hybrid（PostgreSQL + TimescaleDB）：实体存于PostgreSQL，时序数据存于Timescale。
可通过thingsboard.yml配置上述选项，详见数据库配置页面。
1
2
3
4
5
6
7
database:
ts_max_intervals: "${DATABASE_TS_MAX_INTERVALS:700}" # Max number of DB queries generated by single API call to fetch telemetry records
ts:
type: "${DATABASE_TS_TYPE:sql}" # cassandra, sql, or timescale (for hybrid mode, DATABASE_TS_TYPE value should be cassandra, or timescale)
ts_latest:
type: "${DATABASE_TS_LATEST_TYPE:sql}" # cassandra, sql, or timescale (for hybrid mode, DATABASE_TS_TYPE value should be cassandra, or timescale)
编程语言与第三方组件
ThingsBoard后端采用Java编写，部分微服务基于Node.js。前端为基于Angular的SPA。 第三方组件的详细信息请参见单体架构和微服务架构页面。