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

各位同学，咱们今天正式开讲。第一节课，我打算先带大家把ThingsBoard这个平台的整体面貌看清楚。说白了，就是先画一张「地图」，知道它长什么样、由哪些零件组成、数据怎么跑、以及怎么把它装起来。

我个人习惯是，学任何一个新平台，先别急着写代码。先花半小时把架构图看明白，后面写插件、做扩展的时候，心里才有底。否则你写出来的东西，很可能跟平台「打架」。

1.1 平台架构：一个「中心化」的物联网大脑

ThingsBoard的架构，我总结为四个字：中心化分层。它不像某些分布式架构那么复杂，但该有的模块一个不少。

从顶层往下看，大概是这样的：

• 接入层：负责跟设备打交道。支持MQTT、HTTP、CoAP、LwM2M这些协议。嗯，这里要注意，MQTT是最常用的，我建议你优先掌握。
• 核心引擎层：这是平台的大脑。包括规则引擎、消息路由、数据持久化。你写的插件，大部分时间都在跟这层打交道。
• 服务层：提供REST API、WebSocket、RPC调用。说白了，就是给前端和第三方系统用的。
• 展示层：仪表盘、告警、资产树。用户看到的东西，都在这一层。

我在项目中遇到过一个问题：有个团队把设备数据直接写到数据库，绕过了规则引擎。结果后面想做数据过滤和告警，发现根本没法搞。你想想看，数据都落地了，再想拦截就晚了。所以，数据流一定要走规则引擎，这是铁律。

1.2 核心组件：拆开看看里面都有啥

ThingsBoard的核心组件，我列个表，大家一目了然：

组件名称	作用	我的经验
Transport	协议适配，接收设备数据	MQTT Transport最稳定，CoAP在弱网环境有奇效
Rule Engine	数据过滤、转换、路由	这是插件的核心战场，后面会重点讲
Entity Service	管理设备、资产、租户等实体	写插件时经常要调用它来查设备信息
Timeseries Service	时序数据存储与查询	默认用Cassandra，但小项目用PostgreSQL也够
Web UI	前端仪表盘和配置界面	基于Angular，扩展起来有点麻烦

这里我想多说一句规则引擎。它本质上是一个「事件处理器」。设备上报数据后，数据会变成一条消息，流经规则引擎里的一个个节点。每个节点可以做一件事：过滤、转换、存库、发告警。你写的插件，就是自定义节点。

1.3 数据流模型：一条消息的「奇幻漂流」

咱们来模拟一下，一个温度传感器上报数据时，数据是怎么跑的：

1. 设备通过MQTT发送 {"temperature": 25.5} 到 v1/devices/me/telemetry。
2. Transport层收到消息，解析出设备ID和数据内容。
3. Transport把消息扔给规则引擎。注意，这里不是直接存库。
4. 规则引擎的根节点收到消息，开始往下游节点分发。
5. 假设你配了一个「温度过高告警」节点，判断25.5没超标，跳过。
6. 消息流到「数据存储」节点，写入时序数据库。
7. 同时，消息通过WebSocket推送到前端仪表盘，实时更新。

为什么会这样设计？我个人的理解是：解耦。设备只管上报，平台负责处理。你可以在规则引擎里任意插拔节点，而不影响设备端。这就是插件扩展的底层逻辑。

1.4 部署方式对比：单机、集群、还是云？

ThingsBoard的部署方式，我把它分成三种场景。你根据项目规模选就行。

部署方式	适用场景	优点	缺点
单机部署	开发测试、小规模（<1000设备）	简单，一条命令搞定	单点故障，性能瓶颈
集群部署	中等规模（1万-10万设备）	高可用，可横向扩展	需要配置Kafka、Zookeeper
Kubernetes部署	大规模（10万+设备）	弹性伸缩，运维自动化	学习成本高，资源开销大

我个人建议：刚开始先用单机。别一上来就搞K8s，那玩意儿光是排错就能让你怀疑人生。等你把插件写熟了，再考虑集群化。

我记得有一次帮客户做POC，他们非要上K8s。结果折腾了两周，连设备都连不上。最后换成单机，半天就跑通了。你想想看，技术选型不是越复杂越好，合适才是王道。

小结

好了，第一节课的内容就这些。咱们把ThingsBoard的骨架搭起来了：架构是中心化分层，核心是规则引擎，数据流是「设备→Transport→规则引擎→存储→展示」，部署方式按需选择。

下一节课，我会带大家搭建开发环境，然后手写第一个插件。嗯，到时候你们就能感受到，写插件其实没那么神秘。

记住一句话：理解架构，才能驾驭扩展。咱们下节课见。