1、ThingsBoard平台概述：核心功能、架构组件与数据流基础
各位同学，咱们今天正式开讲。第一节课，我打算先带大家把ThingsBoard这个平台的整体面貌看清楚。说白了，就是先画一张「地图」，知道它有哪些功能、由哪些零件组成、数据是怎么在内部流转的。这些东西搞明白了，后面调优、做高可用，你才知道该从哪里下手。
我在好几个项目里都遇到过这种情况：团队里有人一上来就改配置、调参数，结果性能没上去，反而把系统搞崩了。为什么？因为他不理解架构。所以，我建议你先把这一章吃透。
1.1 核心功能：它能做什么？
ThingsBoard是一个开源的物联网平台。它的核心使命，说白了就是三件事：连接设备、处理数据、展示结果。
具体来说，它提供了这些能力：
- 设备管理：注册、认证、配置、固件升级。你想想看，成千上万的设备，总不能一个个手动去配吧？
- 数据采集：支持MQTT、CoAP、HTTP等多种协议，把设备上报的遥测数据（温度、湿度、电压等）收上来。
- 数据可视化：内置仪表板（Dashboard），拖拽式操作，能快速生成实时图表、地图、表格。
- 规则引擎：这是它的灵魂。你可以定义「如果温度超过50度，就发告警邮件」，类似这样的逻辑。
- 告警与通知：支持邮件、短信、Webhook等多种方式。
- REST API & WebSocket：方便与外部系统集成。
重点提醒： 规则引擎和仪表板，是ThingsBoard区别于其他轻量级IoT平台的两大杀手锏。很多企业选型，就是看中了这两点。
1.2 架构组件：拆开看看里面有什么
ThingsBoard的架构，我习惯把它分成四个核心组件。你可以把它们想象成一家工厂的四个车间。
1.2.1 Node（核心节点）
这是整个系统的大脑。它负责协调所有其他组件，管理设备元数据、处理REST API请求、维护系统状态。Node本身是无状态的，这意味着你可以横向扩展——加机器就能扛更多设备。
我记得有一次，客户现场的设备量从5000突然涨到5万，我们就是靠加Node节点扛过去的。嗯，这里要注意，Node虽然无状态，但它依赖数据库，所以数据库的瓶颈才是真正的天花板。
1.2.2 Transport（传输层）
Transport层是系统的「门卫」。所有设备上报的数据，第一站就是到这里。它支持三种协议：
- MQTT Transport：最常用，轻量级，适合低带宽、高并发的场景。
- CoAP Transport：基于UDP，适合资源受限的设备。
- HTTP Transport：简单直接，适合原型验证或低频上报。
每个Transport都是一个独立的微服务进程。你可以单独部署、单独扩容。比如，如果你的设备全是MQTT的，那你可以给MQTT Transport分配更多的资源。
1.2.3 Rule Engine（规则引擎）
规则引擎是ThingsBoard最核心、也最容易出性能瓶颈的地方。它本质上是一个事件处理管道。数据进来后，会经过一系列「节点」——过滤、转换、 enrichment、持久化、告警判断等等。
我曾经在一个项目中，发现规则引擎的CPU使用率飙到90%。排查下来，是因为有人写了一个死循环的规则节点。所以，我建议你在生产环境中，一定要对规则链做性能测试。
1.2.4 Web UI（用户界面）
Web UI是一个Angular应用，通过REST API和WebSocket与后端通信。它本身不参与数据处理，但它的性能会影响用户体验。比如，仪表板加载慢，往往是因为后端API响应慢，而不是前端代码的问题。
我的经验： 很多人在调优时只盯着后端，忽略了Web UI的静态资源缓存。其实，给前端资源加个CDN或者Nginx缓存，能显著提升页面加载速度。
1.3 数据流与消息队列
数据在ThingsBoard里是怎么走的？我画一条最简单的路径给你看：
- 设备通过MQTT上报一条数据（比如温度=30）。
- MQTT Transport收到后，把数据转成内部格式，发给消息队列。
- Node从消息队列里消费这条数据，交给规则引擎处理。
- 规则引擎执行逻辑（比如存数据库、触发告警）。
- 结果通过WebSocket推送到前端仪表板。
这里的关键角色，就是消息队列。ThingsBoard原生支持两种：
| 特性 | Kafka | Pulsar |
|---|---|---|
| 吞吐量 | 极高，百万级/秒 | 极高，百万级/秒 |
| 延迟 | 毫秒级 | 毫秒级 |
| 持久化 | 基于磁盘，可配置 | 基于磁盘，分层存储 |
| 运维复杂度 | 中等，依赖ZooKeeper | 较高，但架构更灵活 |
| 适用场景 | 大规模、高吞吐、成熟生态 | 多租户、跨地域、需要更细粒度控制 |
我个人习惯，在大多数场景下首选Kafka。为什么？因为它的生态太成熟了，社区支持好，出了问题很容易找到解决方案。但如果你做的是多租户平台，或者需要跨机房复制，Pulsar的架构优势就体现出来了。
避坑指南： 我曾经见过一个团队，为了追求「新技术」，强行上了Pulsar，结果运维团队没人会调优，导致消息堆积严重。所以，选消息队列，不仅要看技术指标，还要看团队能力。
1.4 小结
这一章，我们画了ThingsBoard的全景图。核心功能就是连接、处理、展示。架构上，Node、Transport、Rule Engine、Web UI各司其职。数据流的核心是消息队列，它决定了系统的吞吐能力和解耦程度。
下一章，我们会深入消息队列的调优细节。到时候，我会手把手教你配置Kafka的参数，让你知道哪些参数是「命门」。
一句话总结： ThingsBoard的架构设计，本质上就是「微服务 + 消息驱动」。理解了这个，你就掌握了调优的钥匙。
公众号:蓝海资料掘金营，微信deep3321