一、ThingsBoard平台概述：平台架构、核心组件、数据模型、部署方式

大家好，我是你们这堂课的讲师。在正式开始讲集成实战之前，我觉得有必要先把ThingsBoard这个平台本身聊透。你想想看，如果连平台的核心骨架都不清楚，后面做集成的时候很容易踩坑。我在好几个项目里都见过这种情况——开发同学上来就调API，结果连数据是怎么流转的都没搞明白，最后排查问题花了好几天。

所以这一章，咱们就把ThingsBoard的底裤扒干净。我会从架构、组件、数据模型、部署四个维度来讲。嗯，都是干货。

1.1 平台架构：从宏观到微观

ThingsBoard的架构，说白了就是典型的微服务+消息队列模式。我个人习惯把它分成三层来看：

• 接入层：负责设备连接，支持MQTT、HTTP、CoAP、LwM2M等协议
• 核心层：处理数据路由、规则引擎、实体管理、权限控制
• 应用层：提供仪表板、告警、REST API、WebSocket等对外能力

这三层之间通过消息队列（Kafka或内存队列）解耦。为什么要这么设计？我在一个智慧工厂项目里遇到过，设备量从几百台突然涨到几万台，如果不用消息队列做缓冲，核心服务直接被打挂。所以这个架构不是花架子，是真能扛压的。

1.2 核心组件：每个零件都有它的脾气

咱们来看看ThingsBoard里那些关键组件。我按功能模块来拆解：

1.2.1 规则引擎（Rule Engine）

这是ThingsBoard的大脑。所有设备上报的数据、所有事件都会流经规则引擎。你可以把它理解成一个管道，数据进来后经过一系列节点处理，最终输出到目标。

节点类型包括：

• 过滤器节点：判断数据是否满足条件，比如温度大于50度才放行
• 转换节点：修改数据格式，比如把摄氏度转成华氏度
• 动作节点：执行具体操作，比如发送邮件、创建告警、调用REST API
• 外部节点：与第三方系统交互，比如Kafka、RabbitMQ、AWS SQS

1.2.2 设备管理（Device Management）

设备是ThingsBoard里的核心实体。每个设备都有一个唯一的设备令牌（Access Token），用来做身份认证。设备可以关联客户（Customer）、租户（Tenant），形成层级关系。

设备属性分为三类：

属性类型	说明	典型用途
服务端属性	由平台写入，设备只读	设备配置、固件版本
客户端属性	由设备上报，平台只读	设备序列号、硬件信息
共享属性	平台和设备均可读写	设备控制参数、阈值设置

1.2.3 仪表板（Dashboard）

仪表板是给用户看的面板。支持拖拽式布局，可以放图表、地图、表格、控件。我个人觉得它的灵活性相当不错，但要注意一点——仪表板的性能取决于数据查询方式。如果实时数据量大，建议用WebSocket而不是轮询。

1.2.4 告警系统（Alarm）

告警是ThingsBoard里比较成熟的功能。你可以通过规则引擎定义告警规则，比如温度连续3次超过阈值就触发告警。告警支持生命周期管理：创建、确认、清除。

1.3 数据模型：实体之间的关系

ThingsBoard的数据模型，说白了就是一套树形结构。顶层是租户（Tenant），下面是客户（Customer），再下面是设备（Device）和资产（Asset）。

实体关系图可以这样理解：

• 一个租户可以有多个客户
• 一个客户可以有多个设备和资产
• 设备和资产可以关联到同一个客户
• 设备可以属于某个资产（比如一个传感器属于某个车间）

数据存储方面，ThingsBoard用了两种数据库：

数据库	存储内容	特点
PostgreSQL / Cassandra	实体元数据、关系、告警、日志	关系型存储，支持复杂查询
TimescaleDB / Cassandra	时序数据（遥测数据）	高吞吐写入，按时间范围查询

这里要注意：时序数据库的选择直接影响性能。我在一个项目里用过Cassandra，写入确实快，但查询灵活性不如TimescaleDB。如果你的业务需要频繁做聚合查询（比如按小时统计平均值），我建议优先考虑TimescaleDB。

1.4 部署方式：从单机到集群

ThingsBoard的部署方式，我把它分成三种场景：

1.4.1 单机部署（开发/测试环境）

最简单的方式，用Docker Compose一键启动。适合本地开发、功能验证。配置如下：

version: '3.0'
services:
  mytb:
    image: thingsboard/tb-postgres:latest
    ports:
      - "8080:9090"
      - "1883:1883"
      - "5683:5683/udp"
    environment:
      TB_QUEUE_TYPE: in-memory
    volumes:
      - mytb-data:/data

嗯，这个配置里我用了内存队列（in-memory），因为单机场景不需要消息持久化。但生产环境千万别这么干。

1.4.2 高可用部署（生产环境）

生产环境我建议至少三台机器。架构是这样的：

• 负载均衡器（Nginx/HAProxy）做流量分发
• ThingsBoard节点至少2个，做水平扩展
• 消息队列用Kafka集群（3节点起步）
• 数据库用PostgreSQL主从 + TimescaleDB
• 缓存用Redis集群

1.4.3 边缘部署（Edge）

ThingsBoard Edge是专门为边缘场景设计的轻量版本。它可以在本地运行，与云端ThingsBoard保持同步。适合网络不稳定、延迟敏感的场景。

Edge的特点：

• 本地处理数据，减少云端依赖
• 断网时数据缓存，恢复后自动同步
• 资源占用小，可以跑在树莓派上

我在一个油田项目中用过Edge。井场网络很差，经常断网。我们把规则链部署在Edge上，本地做告警判断，数据缓存到网络恢复后再上传。效果相当不错。

小结

这一章咱们把ThingsBoard的底子打好了。架构上记住三层解耦，组件上重点掌握规则引擎和设备管理，数据模型理解租户-客户-设备的层级关系，部署方式根据场景选单机、集群还是边缘。

下一章咱们开始讲真正的集成实战——如何用REST API和MQTT把第三方系统接入ThingsBoard。到时候我会拿一个真实项目案例来拆解，保证你们学完就能用。