聊一聊开源物联网云平台的选型问题。这两年问我这个的人特别多大多是做项目集成、搞毕业设计、或者公司内部要上一套设备管理系统的。需求高度一致数据必须留在自己手里、不想按年交平台费、代码最好能拿来看见改。翻译过来就六个字——开源、私有化部署。这篇文章我就把自己研究过的、实际部署过的平台做一个系统盘点从功能完整性、部署难度、二次开发成本到典型适用场景一次性讲清楚。先说结论目前没有哪个平台能做到“开箱即用全家桶”但按需求分层去选主流方案是完全够用的。通用型物联网平台里ThingsBoard 生态最成熟、JetLinks 国内落地最顺轻量化场景里有 Node-RED 和 ThingsPanel 顶着如果只是想解决设备接入和消息分发EMQX 这类 Broker 反而是性价比最高的选择数据量上来之后还得搭配时序数据库。下面逐个拆。1. 盘点前先搞清需求私有化部署到底在解决什么问题1.1 数据主权与持续成本是核心驱动力很多人上来就问“哪个平台最好”我一般会反问一句你到底是介意数据在别人服务器上还是介意每年要交那笔订阅费这个问题想清楚了选型方向就清晰一半。如果是数据敏感那核心诉求是“数据不出内网”。设备上报的温湿度、电量、位置、运行状态这些数据一旦落到第三方云平台无论是从行业合规角度还是从商业保密角度都很难交代。私有化部署直接把整个链路装进自己的服务器或者局域网数据从设备到数据库全程自己可控这是第一个驱动力。如果是成本敏感那更好理解。商业物联网云平台通常按设备数、消息数、存储量三方面收费设备规模一上来年费相当可观。而开源平台本身免费你只需要承担服务器成本和维护人工。以 ThingsBoard 社区版为例单机部署在中端配置上就能扛住几千台设备的上行数据硬件成本摊下来比按年付费划算得多。还有个隐性诉求是二次开发自由度。商业平台给你的是封装好的功能想加一个私有协议、改一套告警逻辑往往要提工单排队等排期。开源平台代码都在手里基于插件机制自己做扩展半天就能把原型跑起来这在项目交付场景里是刚需。1.2 选型前先回答四个定位问题在下载任何镜像之前我建议你先花半小时把下面四个问题写清楚这比翻一百个 GitHub 仓库都管用第一设备规模大概多少是几十台的小规模验证还是几万台的大规模生产这直接决定你是否需要分布式架构、要不要引入消息队列。第二设备用什么协议接入主流平台都支持 MQTT、HTTP但如果你的设备走的是 CoAP、LwM2M、Modbus、OPC UA那就得确认平台或网关生态里有没有对应组件。第三团队的技术栈是什么Java 团队和 Go 团队、Node.js 团队面对同样需求会选择完全不同的平台。选一个与团队技术栈匹配的平台二次开发效率天差地别。第四你需要的是“平台”还是“组件”如果你只需要把设备数据收上来存起来展示那一个 MQTT Broker 加一个时序数据库就搞定了完全没必要上全套物联网平台。虽然 IoT 平台听起来完整但组件拼装能做到更轻、更可控、更少臃肿。这四个问题的答案决定了你是选重型全家桶、中型业务平台还是轻量组件组合。下面我按这个逻辑分层介绍。2. 通用型平台主流畅选ThingsBoard 与 JetLinks2.1 ThingsBoard生态成熟度最高的通用型方案ThingsBoard 是目前开源物联网平台里星标最多、社区最活跃的一个基于 JVM 技术栈采用微服务架构单体模式下也可以单机跑。核心功能覆盖设备接入、遥测数据采集与展示、告警规则、设备固件 OTA、多租户隔离商业版提供完整多租户插件机制设计得比较清晰官方文档和社区教程都很全。我选择 ThingsBoard 作为主力方案的原因有三点。第一是设备接入层做得扎实基于 Netty 实现了高性能的 MQTT 接入同时支持 HTTP。第二是可视化看板是拖拽式配置对于交付项目来说给客户演示“实时数据大屏”几乎是零代码完成这在项目验收时非常加分。第三是告警引擎支持基于规则链的复杂事件处理虽然上手有点陡峭但熟悉之后非常灵活。社区版的限制需要明确没有多租户管理、没有高级权限控制、部分高级告警功能被裁剪。如果你的产品要对外开放给不同企业客户使用就要考虑商业版 License或者自己做一层租户管理。但单企业内部使用社区版完全够。部署方式上ThingsBoard 支持 Docker Compose、Kubernetes 和传统安装包三种方式。我个人最推荐 Docker Compose一条命令拉起整个环境省去手工装 PostgreSQL、Cassandra、Redis 的痛苦。唯一要提醒的是默认配置文件里带有 Cassandra这是用于分布式部署的高性能数据库小规模单机部署时它反而是资源杀手建议按官方单机模式改成 PostgreSQL 即可。2.2 JetLinks中文社区里最能打的国产开源平台JetLinks 是国内团队开源的物联网平台基于 Spring Boot 生态前几年开源后在国内项目圈里积累了大量用户。和 ThingsBoard 比它最大的优势是文档全中文、社区响应快、内置功能更贴近国内业务习惯比如设备分组、产品物模型、规则引擎可视化编排这些都是开箱即用。在协议支持上JetLinks 也做得比较全。官方主推 MQTT同时通过网关协议包支持 TCP、HTTP、WebSocket还内置了基于 Horton 规则引擎的流式处理能力。对于做系统集成的团队来说它内置的权限体系很完整用户、角色、菜单、数据权限一套下来能省掉不少基础后台管理功能的开发量。使用 JetLinks 的典型场景是国内工厂数字化、能耗监测、智慧园区这类项目。设备侧通常走 Modbus 或者厂商私有协议通过 JetLinks 网关接入后数据统一转成标准物模型平台负责存储和展示再通过开放的 API 对接上层业务系统整个链路非常顺。JetLinks 的部署比 ThingsBoard 要繁琐一些因为它依赖 Elasticsearch 做数据存储和检索对内存要求较高。官方提供了 Docker Compose 脚本建议服务器内存至少 8G否则 Elasticsearch 很容易 OOM。如果你只是小规模试用可以先用 JetLinks 内置的 H2 模式跑通了再上生产。2.3 两者对比选型要看团队和交付场景我画了一张对比表方便你快速定位对比维度ThingsBoardJetLinks技术栈JavaSpring Boot NettyJavaSpring Boot Vert.x协议支持MQTT、HTTP、CoAP部分版MQTT、HTTP、TCP、WebSocket可视化看板强大拖拽式可交付中等图表组件够用规则引擎规则链可视化编排规则引擎可视化编排多租户社区版不支持内置完整权限体系文档语言英文为主中文为主社区活跃度国际社区活跃国内社区活跃典型场景国际化项目、对可视化要求高国内项目、快速交付、后台集成深我的经验是如果项目面向海外客户或者你团队对英文技术栈接受度高优先 ThingsBoard生态丰富问题都能搜到答案。如果项目面向国内政企或者需求里有很多中国式管理后台的定制逻辑JetLinks 能省很多事。当然两者都是 Java 技术栈对国内大多数后端团队都友好。3. 轻量与场景化平台Node-RED 与 ThingsPanel3.1 Node-RED低代码流编排中小项目的效率神器严格意义上 Node-RED 不算是物联网云平台它是 IBM 开源的一个流式编程工具但在物联网领域应用极广很多开发者直接拿它做设备接入层和业务逻辑胶水层。Node-RED 的核心优势是浏览器可视化拖拽编程。MQTT 节点订阅设备消息函数节点转换数据格式HTTP 节点推送到业务系统整个流程拖一拖就连起来了。对于几十台设备的轻量场景用它比部署一个完整 IoT 平台要快得多。我在实际项目中用 Node-RED 做过一个能耗采集网关连接了几十台 Modbus 电表通过 Modbus TCP 采集数据再转成 MQTT 消息上报给平台整个逻辑 20 个节点搞定部署在树莓派上稳定跑了半年没重启过。这种场景如果你用 ThingsBoard光设备配置文件建模就得折腾一天。Node-RED 的短板也很明显没有内置的时序存储、没有设备管理、没有用户权限体系。它适合做接入层或小系统的业务后端不适合做完整平台底座。如果需求是“设备数据要展示、要告警、要多人协作管理”Node-RED 只能当配角。3.2 ThingsPanel为板卡接入而生的国产开源平台ThingsPanel 是国内团队开源的物联网平台Go Vue 技术栈主打硬件接入体验。它和很多国产 IoT 硬件厂商的模组做了预对接比如安信可的 WiFi 模组、4G DTU 等配置界面里选一选硬件类型再填一下设备密钥就能直接把硬件数据接入平台。这对做硬件产品的创客团队来说非常友好。ThingsPanel 内置了设备管理、产品管理、告警中心、可视化大屏等功能部署方式也很简单提供 Docker 镜像一键启动。资源占用上比其他 Java 系平台低不少2G 内存的云服务器能跑得很流畅。使用 ThingsPanel 的场景大多是智能家居、智慧农业、小型商业设备管理。它不像 ThingsBoard 那么重但胜在简单直接尤其是和国产硬件模组对接的便利性是其他平台目前比不了的。如果你手头已经有一批现成的 WiFi/4G 模组想快速做一个私有平台出来ThingsPanel 值得先试。4. 通信层与存储选型不一定要用全家桶4.1 EMQXMQTT Broker 的标杆选择很多时候你真正需要的不是一个“物联网平台”而是一个稳定、高并发的消息接入层。这个场景下EMQX 几乎是最优选。EMQX 是基于 Erlang/OTP 开发的开源 MQTT Broker单节点就能支撑百万级连接集群模式更是能到千万级。它提供完整的 MQTT 3.1/5.0 协议支持内置规则引擎可以直接将 MQTT 消息转发到 Kafka、数据库、HTTP 服务本身就是一个轻量级的 IoT 数据接入层。我之前的团队做车联网数据接入设备产生的 GPS 报文每秒上万条用的就是 EMQX 做接入层后面对接 Kafka 做数据管道再落入时序数据库。整个链路完全自己掌控没有平台软件的厚重感出问题也好排查。EMQX 还提供 Dashboard 可视化管理界面可以实时查看连接数、消息吞吐、订阅关系运维起来非常直观。部署同样支持 Docker 一行命令单独作为设备接入网关使用非常轻量。所以如果你的需求就是“把设备消息稳定收上来然后自己处理”EMQX 数据库的组合比部署完整物联网平台要轻得多也稳定得多。4.2 时序数据存储TDengine 与 IoTDB 谁更适合物联网平台的数据特征是持续追加、按时间维度查询传统关系型数据库在写入吞吐和海量数据聚合查询上很快就会遇到瓶颈。所以部署私有化平台时时序数据库几乎成了默认选项。TDengine 是国产开源时序数据库写入性能极高内置数据保留策略和数据降采样功能SQL 语法对熟悉 MySQL 的人很友好学习成本低。IoTDB 则是 Apache 基金会旗下的时序数据库项目在工业物联网领域尤其是复杂设备建模上做得很深支持树形设备模型和复杂查询。如果是 ThingsBoard官方默认存储可选 Cassandra集群或 PostgreSQL单机也能通过扩展接入 TDengine。JetLinks 官方推荐 Elasticsearch。但如果你是自己拼装 EMQX TSDB 方案我会优先推荐 TDengine它在资源占用和部署便捷度上比 Elasticsearch 有优势而且中文文档完善出了故障好排查。4.3 边缘端方案从云到边EdgeX Foundry 与 Kuiper如果你的物联网项目涉及边缘计算即需要在靠近设备的地方做数据采集、处理、清洗后再上云那 EdgeX Foundry 和 Kuiper 值得了解。EdgeX Foundry 是 Linux Foundation 主导的边缘物联网中间件定义了一套标准的南北向接口北向对接云平台南向接入各种设备协议Modbus、BACnet、MQTT 等核心思想是把设备接入和数据转型做成本地服务即使断网也能边缘自治。Kuiper 则是 EMQX 团队开源的轻量级流式数据处理引擎部署在边缘端对 MQTT 消息做规则过滤、转换然后再转发云端。我在一个工厂能耗项目里就是用 Kuiper 在边缘侧先做数据清洗过滤掉无效报文再上送云端明显减少了网络用量和云端存储压力。边缘端方案通常和云端平台搭配使用边缘负责接入与预处理云平台负责全局展示、分析与告警。纯私有化部署的企业往往会选择“边缘 Kuiper 云端 EMQX 自主业务系统”的组合这样既控制了成本也掌握了全链路。5. 部署实操以最省事的方式把平台跑起来5.1 5分钟快速到最小可运行状态Docker Compose 部署 ThingsBoard不管最终选哪个平台第一次跑通建议都用 Docker Compose我以 ThingsBoard 为例实际操作一遍。前提是你的服务器或本机装了 Docker 和 Docker Compose。然后找一个干净的目录新建一个 docker-compose.yml核心内容如下version: 3.0 services: postgres: image: postgres:15 environment: POSTGRES_DB: thingsboard POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres volumes: - postgres-data:/var/lib/postgresql/data networks: - tb-network thingsboard: image: thingsboard/tb-postgres:3.5.1 depends_on: - postgres environment: TB_QUEUE_TYPE: in-memory SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/thingsboard SPRING_DATASOURCE_USERNAME: postgres SPRING_DATASOURCE_PASSWORD: postgres ports: - 8080:9090 - 1883:1883 - 5683:5683/udp volumes: - tb-data:/data networks: - tb-network volumes: postgres-data: tb-data: networks: tb-network: driver: bridge你需要按照实际版本和环境变量调整配置然后执行docker-compose up -d这里我特意手动指定了 SPRING_DATASOURCE_* 环境变量避免 ThingsBoard 默认连接自带的 PostgreSQL 容器时账号密码不匹配。如果不手动指定它默认会用容器内的环境变量很多第一次部署的人坑在这里。启动后访问http://服务器IP:8080默认账号sysadminthingsboard.org密码sysadmin进入系统后第一件事就是改密码。整个流程确实可以在五分钟左右跑通这个速度在私有化部署里已经算非常友好。5.2 用 MQTT 模拟设备接入并查看数据上报平台起来之后用任何 MQTT 客户端工具就能模拟设备接入。我常用 MQTTX 做桌面端调试也可以用命令行工具快速验证。假设你要创建一个名叫“温度传感器”的设备接入凭证是 Access Tokentest_token。自己在 ThingsBoard 的设备管理里添加设备然后复制设备凭证里的 Access Token执行如下 MQTT 发布命令即可完成数据上报mosquitto_pub -h 服务器IP -p 1883 -t v1/devices/me/telemetry -u test_token -m {\temperature\:26.5,\humidity\:60}命令发布后在 ThingsBoard 的“最新遥测”标签页里几秒内就能看到温度和湿度字段更新。这个链路演示的是物联网平台最核心的功能设备接入、消息认证、遥测存储、实时展示。整个过程中你不需要写一行后端代码这也是我用 ThingsBoard 做项目交付时觉得最省心的地方。5.3 二次开发与扩展哪些点值得投入私有化部署的终局目标往往是二次开发。这里我讲讲值得投入的扩展点以及对应的技术路径。设备接入层扩展如果设备走的协议平台不支持比如私有 TCP 长连接、或者某个特殊的工业协议ThingsBoard 提供了 Transport 模块可以自定义扩展JetLinks 则可以通过网关协议包实现。这一层扩展的难点在于并发处理和协议解析建议在动手前先画清楚协议交互时序图。业务逻辑层扩展也就是告警规则、数据清洗、场景联动。ThingsBoard 的规则链Rule Chain是流式处理模型你可以在界面上拖拽节点实现“当温度超过阈值且持续 5 分钟就发邮件告警”类似的规则完全不用写代码。JetLinks 的规则引擎能力相似。想要更灵活的处理逻辑也可以把原始数据转发到自建的消息队列由自己的服务去消费处理。数据展示层扩展如果内置看板满足不了客户需求比如要 3D 场景、复杂图表一般做法是平台通过 REST API 把数据开放出来前端自研大屏。这要求平台有完善的 API 文档和访问控制机制ThingsBoard 的 API 设计得不错支持实体查询和遥测查询响应速度也够快。6. 常见问题与排查实录6.1 为什么部署后外网访问不了平台页面这个问题 80% 出在防火墙和云服务器安全组上。Docker 容器端口映射正常但云平台的安全组没有放行对应端口外网自然访问不到。排查三步走先在本机执行curl http://localhost:8080验证服务存活再在服务器上检查firewall-cmd --list-ports或 ufw 状态最后去云控制台检查安全组入方向规则放行 8080 端口。如果是 1883 端口连不上同理检查 MQTT 端口。6.2 MQTT 能连上但数据不显示怎么排查这种问题通常和接入凭证或 Topic 有关。我梳理了一个排查顺序确认设备状态是否“已激活”如果一直显示“未激活”说明 MQTT 连接时的用户名Access Token不对。确认 Topic 拼写正确。遥测数据是v1/devices/me/telemetry属性上报是v1/devices/me/attributes大小写都不能错。检查数据格式是否为合法 JSON比如单引号在 MQTT 里会被拒收。确认平台的“最新遥测”页面刷新了这个页面不是自动实时刷新的需要手动刷新或稍等几秒。6.3 设备数量增长后平台响应变慢怎么优化常见瓶颈有三个数据库、消息队列、JVM 内存。小规模单机部署时优先检查服务器的 CPU 和内存占用如果内存长期 80% 以上调整 Docker 容器的内存限制和 JVM 堆大小。设备规模上千之后建议把队列从 in-memory 模式改成 Kafka 或 RabbitMQ 模式让消息异步削峰。数据库层面单机 PostgreSQL 能扛的写入量有限这时候就要考虑把历史数据迁移到时序数据库或开启数据保留策略定期清理过期数据。6.4 关于授权的坑开源不等于随便商用最后必须泼一盆冷水开源不等于无限制商用。ThingsBoard 社区版采用 Apache 2.0 协议商用和二次开发基本没有限制但如果你把社区版改造成 SaaS 对外提供多租户服务要留意协议中关于商标和版权的条款。JetLinks 需要看具体版本的开源协议有的模块是 AGPL 协议如果你不打算把改动开源就要避开这些模块或购买商业授权。动手之前花半小时读清楚 LICENSE 文件比事后收到律师函要划算得多。使用过程里还要留意社区版的版本升级策略。ThingsBoard 升级版本时数据库迁移脚本不一定完全兼容升级前务必备份数据库。我吃过一次亏直接从 3.3 升到 3.5因为跳过了中间版本导致数据库迁移失败花了半天才恢复。以后凡是升级我都严格执行逐版本升级。6.5 我给选型者的一些实在建议根据我个人做过的项目经验再给几条实在建议。第一不要一上来就追求大而全的平台。设备量只有几十台一个 EMQX TDengine Grafana 就能解决完全没必要部署 ThingsBoard 全家桶。技术复杂度每上升一个等级维护成本也跟着上升一个等级。第二可视化需求高就选 ThingsBoard协议适配需求强就重点研究 JetLinks边缘场景多就先把 Kuiper 和 EdgeX Foundry 学透。没有最好的平台只有最合适自己项目的组合。第三尝试把“平台”拆成“组件”来看。设备接入用 EMQX、数据存储用 TDengine、业务展示自研这种搭积木的思路在长期维护上反而比绑定某个大平台更灵活因为你不会受制于某一个项目的 Release 节奏和安全公告。最后再分享一个我自己的习惯不管选哪个平台先在本地用 Docker 跑通完整链路用 MQTT 模拟工具造一批模拟数据连续跑两周稳定性验证没问题再往生产环境迁移。这样踩坑的成本最低交付的时候心里也最有底。物联网私有化部署这条路选型只是第一步真正让平台跑得稳、改得动、扛得住靠的还是对技术选型逻辑的透彻理解和一遍遍的实操打磨。