第2章 ThingsBoard平台初探

2、ThingsBoard平台初探：开源版与商业版区别、核心功能（仪表板、规则链、资产管理）、架构概览

好，咱们正式开始接触 ThingsBoard 这个平台。说实话，我第一次看到它的时候，第一反应是「又一个 IoT 平台？」。但用了一段时间后，我发现它确实有两把刷子。尤其是它的规则链引擎，让我在项目里少写了不少后端代码。

这一节，咱们先不急着动手。先搞清楚 ThingsBoard 到底是什么，开源版和商业版有啥区别，它的核心功能怎么用，以及整体架构长什么样。嗯，这些基础打牢了，后面实操才不会懵。

ThingsBoard 有社区版（CE）和商业版（PE）。我在项目里两个版本都用过，说说我的感受。

我的建议： 如果你只是做原型验证、小规模部署（几百台设备），社区版完全够用。我第一个项目就是拿社区版跑的，跑了两年没出过问题。但如果你要给客户做私有化部署，客户要求改 Logo、做报表，那还是得上商业版。

ThingsBoard 功能很多，但核心就三样：仪表板、规则链、资产管理。咱们一个一个说。

说白了，就是给数据「化妆」的地方。传感器采集的温度、湿度、电压，最终都要在仪表板上展示出来。

ThingsBoard 的仪表板支持拖拽式编辑，你可以放图表、仪表盘、地图、表格。我个人习惯把实时数据放左边，历史趋势放右边，报警信息放底部。

    避坑指南： 我曾经在仪表板上放了 20 多个实时图表，结果页面加载慢得要死。后来发现是每个图表都在独立查询数据库。解决办法是：用「别名」功能，把多个数据源合并成一个查询。

这是 ThingsBoard 最强大的部分，没有之一。规则链本质上是一个可视化的事件处理引擎。你可以把设备上报的数据，通过拖拽节点的方式，进行过滤、转换、存储、报警。

举个例子：

设备上报温度数据 → 规则链入口
    ↓
[消息类型过滤] → 只处理 "POST_TELEMETRY" 消息
    ↓
[温度阈值判断] → 如果温度 > 50°C
    ↓
[创建报警] → 生成一条报警记录
    ↓
[发送邮件] → 通知运维人员

你看，整个过程不需要写一行后端代码。我在项目里用规则链处理过设备 OTA 升级、远程配置下发、甚至设备间的联动控制。嗯，这东西用熟了，你会爱上它的。

注意： 规则链的节点执行顺序很重要。我曾经把「数据持久化」节点放在了「报警判断」节点后面，结果报警触发了，但数据没存进去。调试了半天才发现是顺序问题。

设备多了，你得管起来。ThingsBoard 把「设备」和「资产」分得很清楚。

你可以把设备挂到资产下面。比如「车间A」下面有 10 个温度传感器、5 个湿度传感器。这样在仪表板上，你可以直接看「车间A」的整体数据，不用一个一个设备去查。

我记得有一次客户问：「能不能按区域查看设备状态？」我直接建了几个资产，把设备关联进去，5 分钟搞定。客户觉得好神奇，其实原理很简单。

咱们不画复杂的架构图，用文字说清楚就行。ThingsBoard 的架构，说白了就是「一个核心 + 三个组件」。

这是大脑。负责处理设备连接、数据存储、规则链执行、API 服务。它基于 Java 开发，用的是 Spring Boot 框架。嗯，Java 程序员看到这里应该会心一笑。

Transport Layer（传输层）： 负责和设备通信。支持 MQTT、HTTP、CoAP、LwM2M。你想想看，不管你的设备用哪种协议，它都能接进来。
Storage Layer（存储层）： 默认用 PostgreSQL 存元数据（设备信息、用户、仪表板配置），用 Cassandra 或 TimescaleDB 存时序数据（温度、湿度这些）。我个人推荐 TimescaleDB，部署简单，性能也不错。
Queue Layer（队列层）： 用于解耦和异步处理。支持 Kafka、RabbitMQ、AWS SQS。设备上报的数据先进队列，再慢慢处理，不会因为突发流量把系统打崩。

一个小技巧： 如果你只是做测试，用内置的内存队列就够了。但生产环境，我强烈建议上 Kafka。我曾经遇到过设备批量上报时队列积压，换了 Kafka 之后，吞吐量直接翻了 5 倍。

这一节咱们把 ThingsBoard 的底牌翻了个遍。开源版和商业版的区别，说白了就是「够用」和「好用」的区别。核心功能里，仪表板是脸面，规则链是灵魂，资产管理是骨架。架构上，它用 Java 写了一个能扛高并发的 IoT 平台。

下一节，咱们就要动手部署了。我会带你从零开始，在 Linux 服务器上把 ThingsBoard 跑起来。嗯，到时候记得准备好一杯咖啡，因为第一次部署可能会踩几个坑。

公众号:蓝海资料掘金营，微信deep3321