1. ThingsBoard 概览：平台架构、核心组件、应用场景、版本对比

1.1 先聊聊我为什么选 ThingsBoard

做物联网平台选型，说实话挺头疼的。市面上开源方案不少，但真正能扛住企业级压力的，其实没几个。

我个人最早接触 ThingsBoard 是在 2018 年。当时一个智慧工厂项目，需要对接上千个传感器，还要做实时告警和远程控制。试了一圈，最后选了 ThingsBoard。为什么？因为它架构清晰，扩展性好，而且社区活跃。说白了，你遇到坑了，大概率有人已经踩过了。

嗯，这里要注意：ThingsBoard 不是万能的。但它确实是我见过的，在「开箱即用」和「二次开发灵活性」之间平衡得最好的平台之一。

1.2 平台架构：一张图讲清楚

ThingsBoard 的架构，我习惯把它分成四层：

• 设备接入层：负责跟硬件打交道。支持 MQTT、HTTP、CoAP、LwM2M 这些主流协议。
• 核心服务层：这是大脑。处理数据、执行规则、管理设备、存储状态。
• 数据存储层：分两块。时序数据用 Cassandra 或 TimescaleDB，元数据用 PostgreSQL。
• 应用展示层：仪表板、告警、API 网关，给用户和第三方系统用。

我在项目中遇到过一个问题：设备量从几百突然涨到几万，结果数据库扛不住了。后来发现是时序数据存储没配好。你想想看，如果一开始就按分层架构来规划，扩容会轻松很多。

1.3 核心组件：每个角色都有活干

咱们拆开来看，ThingsBoard 里到底有哪些关键角色：

组件	职责	我踩过的坑
Transport Layer	协议适配、设备认证、消息收发	MQTT 的 KeepAlive 设太短，设备频繁重连
Rule Engine	数据过滤、告警判断、消息路由	规则链写太复杂，排查问题很痛苦
Core Service	设备管理、租户隔离、REST API	租户数量多了，内存占用飙升
Data Storage	时序数据、属性数据、日志	Cassandra 的 compaction 策略没调好，磁盘 IO 打满
Web UI	仪表板、告警管理、系统配置	仪表板加载慢，往往是后端 API 响应慢

我曾经在部署时犯过一个低级错误：把 Transport 和 Core 放在同一台机器上。结果设备一多，CPU 直接飙到 90%。后来强制拆开部署，问题就解决了。所以，组件分离是必须的。

1.4 应用场景：它到底能干啥？

ThingsBoard 的应用场景，我总结下来主要有这几类：

• 工业物联网：设备监控、预测性维护、产线数据采集。我做过一个注塑机项目，用 ThingsBoard 采集温度、压力、振动数据，配合规则引擎做异常告警。
• 智慧能源：电表、水表、气表的数据采集和计费。支持海量设备接入，时序数据存储是强项。
• 智能楼宇：门禁、照明、空调的集中控制。仪表板可以实时展示能耗和状态。
• 车联网：车辆定位、行驶数据、远程诊断。MQTT 协议在这里很合适。

1.5 版本对比：选社区版还是专业版？

这个问题几乎每个客户都会问我。我直接说结论：

功能	社区版	专业版
设备数量	无限制	无限制
租户管理	单租户	多租户
规则引擎	基础版	高级版（支持脚本、自定义节点）
仪表板	基础版	高级版（图表、地图、报表）
告警管理	有	有（更丰富）
OAuth/SSO	无	有
技术支持	社区	官方

我个人习惯是：小规模验证用社区版，生产环境直接上专业版。为什么？因为专业版的多租户和高级规则引擎，能省掉你大量开发时间。我曾经帮一个客户从社区版迁移到专业版，光是租户隔离这块，就省了至少两周的编码工作。

1.6 小结：这一章你该记住什么？

嗯，这一章内容不少，但核心就三点：

1. 架构要分层：设备接入、核心服务、数据存储、应用展示，各司其职。
2. 组件要分离：别把所有东西塞一台机器，否则迟早出问题。
3. 版本要选对：社区版适合学习和验证，专业版适合生产。

下一章，我会带你手把手搭建 ThingsBoard 开发环境。到时候咱们聊聊 Docker 部署的那些坑，以及我第一次部署时差点把服务器搞崩的故事。

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