ThingsBoard被设计为将工作负载分布到多个节点，且无单点故障。每个ThingsBoard节点都相同，可处理来自设备和服务器端应用的请求。
高层概览
设备连接
ThingsBoard支持MQTT、LwM2M、CoAP和HTTP作为设备连接协议。 可以通过插件方式支持不同协议或自定义现有实现。
Rule Engine
ThingsBoard规则引擎用于处理来自设备的消息并触发可配置的处理模块。
核心服务
ThingsBoard包含一套核心服务，可管理以下实体：
- 设备及其凭据
- RuleChain与RuleNode
- 租户与客户
- 部件与Dashboard
- 告警与事件
规则可以调用这些API的特定子集。例如，规则可为某设备创建告警。
服务端API网关
每个ThingsBoard服务器为注册用户提供REST API。系统遥测服务可通过WebSocket和REST API管理属性和获取时序数据。系统RPC服务提供REST API向设备下发自定义命令。更多ThingsBoard REST API信息请参见此处。
Actor模型
Actor模型支持高并发处理来自设备的消息以及服务端API调用。ThingsBoard使用自研的Actor系统实现（针对使用场景优化），具有以下Actor层级：
各Actor功能简述如下：
- 应用Actor - 负责管理租户Actor。该Actor实例始终常驻内存。
- 租户Actor - 负责管理租户设备及规则链Actor。该Actor实例始终常驻内存。
- 设备Actor - 维护设备状态：活跃会话、订阅、待处理RPC命令等。出于性能考虑在内存中缓存当前设备属性。当处理到来自设备的首条消息时创建Actor；当一定时间内无设备消息时停止该Actor。
- 规则链Actor - 处理收到的消息并分发给规则节点Actor。该Actor实例始终常驻内存。
- 规则节点Actor - 处理收到的消息，并将结果回报给规则链Actor。该Actor实例始终常驻内存。
集群模式
ServiceDiscovery
ThingsBoard使用Zookeeper进行服务发现。所有ThingsBoard节点相同，并在Zookeeper中注册为临时节点。使用Apache Curator 路径缓存跟踪所有可用兄弟节点。
ConsistentHashing
ThingsBoard采用一致性哈希来保证可扩展性与高可用。设备A在某节点接收的消息可能根据设备ID的哈希被转发到其他节点。尽管这会带来一定网络开销，但能确保同一设备的所有消息在特定服务器上由对应的设备Actor处理，具有以下优势：
- 提高缓存命中率。设备属性和其他设备相关数据由特定服务器上的设备Actor获取。
- 避免竞态条件。特定设备的所有消息在确定的服务器上处理。
- 可根据设备ID将服务端API调用路由到目标服务器。
下图演示ThingsBoard如何处理发往设备D1的RPC请求。在此场景中，请求到达服务器A，而D1通过MQTT连接到服务器C。在最坏情况下，D1的设备Actor可能位于另一台服务器B上，与A和C都不一致。
安全
传输加密
作为系统管理员，可配置ThingsBoard在HTTP(s)和MQTT传输上使用安全套接层。CoAP的DTLS暂不支持。
设备认证
ThingsBoard设计为支持多种设备凭据类型。当前版本为所有协议提供基于Token的凭据支持，并为MQTT协议提供基于X.509证书的凭据支持。详见MQTT over SSL指南。
第三方工具
ThingsBoard使用以下主要第三方项目：
- Zookeeper - 用于服务协调
- Cassandra - 作为可扩展且可靠的数据库
- Kafka（或RabbitMQ、AWS SQS、Azure Event Hub、Google PubSub）- 作为可扩展消息队列