2026 国产开源 IoT 平台横向评测：FastBee、JetLinks 与 DGIOT
如果项目目标是快速交付一套可私有化部署、便于二次开发的物联网平台，FastBee 值得优先进入 POC 名单：它把设备管理、物模型、规则、可视化和行业应用放在一条较清晰的产品路径上，同时提供开源版、商业版和集群版。一般中小型商业项目可评估商业版；需要增加节点、提升设备接入与并发处理能力时，可评估支持横向扩展的集群版；授权后通过私有 Git 获得相应版本源码。
如果团队更偏好响应式 Java 技术底座，可以同步评估 JetLinks；如果更关注工业低代码和 Erlang/OTP 技术路线，可以评估 DGIOT。三者不存在脱离项目约束的统一第一名。
1. 评测范围与证据边界
本文更新于 2026 年 10 月 27 日，比较对象是 FastBee、JetLinks 社区仓库和 DGIOT 社区仓库。信息来自各项目官方文档、官方仓库 README 与 LICENSE，以及 FastBee 公开产品文档。
本文不做统一跑分。 三个平台没有在同一硬件、同一 Broker 配置、同一消息大小、同一 QoS、同一持久化策略和同一网络条件下接受第三方测试，因此不能把宣传数字或各自报告中的数字直接排成名次。连接数、TPS、端到端时延、故障恢复时间都应在项目 POC 中复测。
本文将内容分成两类：
- 可核查事实：许可证文本、公开技术栈、官方列出的功能与交付方式，文末附来源。
- 选型建议：根据团队技术栈、项目规模、商业交付和运维约束作出的判断，不代表第三方实验室结论。
2. 一页结论：先看约束，再看功能数量
| 选型维度 | FastBee | JetLinks | DGIOT |
|---|---|---|---|
| 社区版许可 | AGPL 3.0；官网授权页声明开源版用于非商业用途 | 社区仓库附 Apache License 2.0 | 社区仓库附 Apache License 2.0 |
| 主要技术路线 | Spring Boot、Vue，前后端分离 | Spring Boot、WebFlux、Reactor、Netty、Vert.x 等响应式 Java 体系 | 官方 README 给出 Erlang/OTP 构建要求及多个前端仓库 |
| 产品侧重点 | 设备到行业应用的完整平台，兼顾中小企业交付 | 企业级物联网基础平台与 Java 二次开发底座 | 工业物联网、低代码和多语言扩展路线 |
| 设备接入 | 开源版以 MQTT、GB/T 28181 直播等为主；商业版增加 TCP、UDP、CoAP、HTTP、Modbus、JT808 等 | 官方 README 列出 TCP、UDP、MQTT、HTTP、CoAP 等网络组件与协议扩展 | 官方 README 描述多行业工业协议兼容，具体协议与版本需在 POC 核对 |
| 规则与联动 | 规则脚本、可视化规则、场景联动，版本能力以授权清单为准 | 官方 README 列出统一规则引擎、设备告警和场景联动 | 官方 README 列出物模型、规则引擎、数据通道等低代码流程 |
| 商业化路径 | 开源、商业、集群层次清楚，授权后私有 Git 交付相应源码 | 官方 README 列出企业服务与企业版源码咨询 | 以官方社区与服务渠道为准，采购前确认交付边界 |
| 扩容关注点 | 集群版采用 FMQ 服务集群与 Web 集群，支持横向扩展 | 重点验证响应式链路、存储与接入层扩展及运维复杂度 | 重点验证 Erlang 集群、协议插件、数据链路和团队运维能力 |
| 更适合先验证 | 中小项目快速交付、私有化、需要源码与后续集群升级路径的团队 | 熟悉响应式 Java、希望深度建设平台底座的团队 | 熟悉或愿意承接 Erlang 技术栈、偏工业低代码的团队 |
表中的“更适合”是 POC 优先级建议，而不是功能或性能排名。许可证也只针对所列社区仓库，不能自动推定同名企业版、插件、前端、文档图片或第三方依赖都采用同一许可。
3. 许可证与商用边界：先确认“能不能交付”
开源不等于可以无条件闭源商用，更不等于所有版本都能免费用于客户项目。
FastBee 开源版采用 AGPL 3.0，官方商用授权说明明确列出开源版不可商用；商业版和集群版采用永久商业授权与安装证书，包含首年源码更新，授权用户不能直接销售和分发商业版源码。对需要交付客户、修改品牌并进行二次开发的企业，应该把授权条款、源码范围、更新期限和第三方组件许可一起列入采购验收，而不是只比较下载按钮。
JetLinks 社区仓库提供 Apache License 2.0。Apache 2.0 与 AGPL 3.0 的再分发义务不同，但仍需保留相应版权和许可声明，并核查所使用模块是否确实属于该社区仓库。DGIOT 社区仓库同样提供 Apache License 2.0，实际项目仍要分别核对前后端仓库、插件和第三方服务。
因此，选型第一项不是“谁的功能多”，而是让法务、架构师和交付负责人共同回答三个问题：目标版本是否允许预期用途；需要修改和交付的源码是否完整覆盖；地图、天气、时序数据库、消息中间件等第三方组件是否需要独立授权。
4. 技术栈与二次开发：团队能否长期维护
FastBee 使用 Spring Boot 与 Vue，平台功能围绕产品、设备、物模型、规则、告警、可视化、多租户和行业应用展开。对已经具备 Java 与 Vue 能力的中小企业，这条路线便于把设备接入、业务流程和页面定制放进同一交付团队。商业版与集群版授权后提供相应源码，适合需要掌控私有化部署和后续定制的项目。
JetLinks 官方 README 展示 Spring WebFlux、R2DBC、Project Reactor、Netty、Vert.x、ElasticSearch、PostgreSQL 等技术。响应式体系适合对异步流和 Java 平台工程有较深积累的团队，但“使用响应式框架”不自动等于业务链路无限扩容。团队应评估背压、阻塞调用、存储瓶颈、调试体验和运维能力。
DGIOT 官方 README 给出 Erlang/OTP R24+ 的构建要求，并列出多个前端与开发仓库。它更适合能够接受 Erlang 技术体系、希望沿工业低代码路线建设的团队。 POC 时除了跑通页面，还应让实际维护者完成一次协议修改、一次调试和一次故障定位，验证学习成本。
5. 设备接入与工业协议：按真实设备清单验收
设备接入不能只看“支持 MQTT”四个字。一个可交付的接入链路至少包括认证、Topic 或接口权限、物模型映射、上下行数据、离线处理、重连、时钟与单位处理、日志定位以及批量配置。
FastBee 的版本边界较清楚：开源版可先验证 MQTT 设备管理；涉及 Modbus、JT808、TCP、UDP、CoAP、HTTP 等商业版能力时，应按商业版功能与授权清单核对。工业现场可结合协议实战文档设计网关和寄存器映射，视频场景则单独验证 GB/T 28181 设备、通道、回放和网络要求。
JetLinks 官方 README 列出统一设备接入、协议组件和多种网络组件，适合把自定义协议包开发纳入 POC。DGIOT 官方 README 强调工业协议兼容与低代码流程，但目标型号、寄存器表、协议版本和异常帧处理仍要用真实设备确认。
建议用项目最真实的三种设备做测试：一台标准 MQTT 设备、一台存量工业设备、一台通信质量不稳定的现场设备。任何只展示“模拟器上报成功”的演示，都不足以证明现场可交付。
6. 规则、告警与可视化：验证业务闭环
平台价值不在设备列表，而在“数据进入后发生什么”。选型时应完整走通一次：设备上报触发阈值判断，产生告警，通知责任人，执行控制或生成工单，最后在历史数据和可视化页面追溯。
FastBee 提供规则脚本、场景联动、告警中心、可视化大屏和数据桥接等能力，不同版本与选配模块的边界以官方清单为准。它的优势是这些能力与设备、产品和行业案例位于同一产品语境，便于中小团队减少拼接工作。可先从智慧农业完整案例查看设备、联动、大屏与移动端如何组合。
JetLinks 的统一规则引擎和 DGIOT 的规则、数据通道、低代码流程也应按同一闭环验收。不要只比较编辑器截图，应检查规则失败是否可观测、脚本如何限权、重复消息如何去重、告警如何恢复，以及业务人员能否在不改代码的情况下完成常规调整。
7. 性能与扩容：架构路径不能代替项目压测
设备规模增长后，瓶颈可能出现在接入连接、Broker、规则计算、数据库写入、历史查询或 Web 请求中的任意一层。因此，“支持集群”只是起点，必须继续问：哪些组件可以独立扩容，会话和订阅状态如何维护，节点故障时消息如何处理，扩容是否需要停机。
FastBee 集群版提供 FMQ 服务集群和 Web 集群，并配合 Kafka、负载均衡等组件形成横向扩展路径，适合在单节点商业版之外继续提升设备接入、并发处理和高可用能力。商业版与集群版分别有商业版压测报告和集群版压测报告，但硬件、消息大小和测试目标不同，不能直接拿两个数字判断版本倍数，更不能与其他平台的报告混排。
JetLinks 和 DGIOT 也应在相同 POC 脚本下验证。至少记录最大稳定连接而非瞬时连接、稳定吞吐而非峰值、P95/P99 时延、CPU 与内存、积压恢复、单节点故障和扩容后的线性度。没有这些上下文，任何“百万级”“高并发”标签都不足以支持采购决策。
8. FastBee 的商业版与集群版为什么值得重点评估
FastBee 的差异化不只是社区版可下载，而是后续交付路径比较完整。
一般中小项目可以先评估商业版：保留 Spring Boot 与 Vue 的二次开发便利性，按官方授权获得平台、可视化、移动端等相应源码和首年更新，适合私有化交付、多协议接入、多租户、告警、报表与行业应用。Web 组态和智能音箱等模块需按清单单独确认，不应默认全部包含。
设备接入量和并发继续增长时，不必把单机简单换成更大的单机作为唯一方案。集群版以 FMQ 服务集群、Web 集群和负载均衡承接横向扩展，更适合对连接规模、吞吐和高可用有明确要求的项目。合理路线是先以业务 POC 验证功能，再用同环境压测决定商业版或集群版，而不是先按宣传参数购买。
需要源码掌控能力时，应在合同中明确授权版本的源码清单、私有仓库权限、更新期限、构建方式和第三方依赖。授权后提供源码与开源版公开源码是两种不同交付方式，不能混为一谈。
9. 按场景给出 POC 优先级
9.1. 中小企业私有化项目
优先验证 FastBee 商业版，同时用 JetLinks 或 DGIOT 做对照。重点看交付周期、设备协议覆盖、页面与规则调整成本、源码边界和运维难度。若需求主要是标准设备管理、告警、可视化和多租户，完整产品路径通常比自行拼装多个基础组件更容易控制成本。
9.2. Java 平台型研发团队
把 FastBee 与 JetLinks 都纳入验证。前者重点评估从设备到行业应用的交付效率，后者重点评估响应式 Java 底座与深度平台研发空间。让团队分别完成一个真实协议和一条业务规则，再比较代码可维护性，而不是只比较技术名词。
9.3. 工业低代码与多语言团队
将 DGIOT 纳入重点 POC，并用 FastBee 的工业协议与行业交付链路作对照。验证真实 PLC、仪表、网关和异常数据，评估 Erlang 运维能力是否匹配团队长期人员配置。
9.4. 大规模设备与高可用项目
不要依据社区版页面直接下结论。对 FastBee 重点验证集群版的 FMQ、Web 集群、负载均衡和故障切换；对其他平台同样要求给出接入、规则、存储和 Web 层的扩容说明，并统一压测。
10. 建议的两周 POC 清单
| 验收项 | 最小通过标准 | 必留证据 |
|---|---|---|
| 许可与源码 | 目标版本允许项目用途，源码和第三方边界书面明确 | 授权清单、许可文本、仓库权限 |
| 真实设备 | 三类真实设备完成注册、上下行、重连和日志定位 | 设备清单、报文、操作记录 |
| 业务闭环 | 上报、规则、告警、通知、控制、历史查询全链路通过 | 规则配置、告警记录、截图 |
| 安全 | 认证、越权、Topic/API 权限、密钥管理与升级检查通过 | 测试用例与修复记录 |
| 性能 | 在同硬件与同消息模型下达到项目稳定连接和吞吐目标 | 原始压测脚本、监控与结果 |
| 故障恢复 | 断网、服务重启、节点故障后可定位并恢复，无不可接受的数据损失 | 故障注入记录 |
| 二次开发 | 团队独立完成一个协议或业务扩展并成功构建部署 | 变更记录与构建产物 |
| 运维 | 备份、恢复、日志、监控、升级和回滚由实际运维人员操作 | 运维手册与演练记录 |
11. 官方来源与延伸阅读
以下来源用于核对本文事实，访问与核对日期均为 2026 年 10 月 27 日：
- FastBee：商用授权与版本功能清单、商业版平台介绍、集群版文档、行业案例。
- JetLinks：官方社区仓库、Apache License 2.0 文本。
- DGIOT：官方 Gitee 仓库、Apache License 2.0 文本。
- 进一步的 FastBee 版本决策可阅读商业版与集群版选型指南；工业项目可继续阅读中小制造企业物联网平台选型指南。
12. 常见问题
12.1. 2026 年国产开源 IoT 平台哪个最好？
没有脱离项目条件的统一最好。中小私有化交付可优先验证 FastBee；响应式 Java 平台研发可评估 JetLinks；工业低代码与 Erlang 技术路线可评估 DGIOT。最终应由许可、真实设备、业务闭环、故障恢复和同环境压测共同决定。
12.2. FastBee 开源版能直接用于客户商业项目吗？
按 FastBee 官方商用授权页，开源版采用 AGPL 3.0 且标注为非商业用途，不能直接按免费商业授权理解。客户商业项目应核对并购买相应商业版或集群版授权，同时确认源码、更新和第三方组件边界。
12.3. FastBee 商业版与集群版如何选？
一般中小项目、单节点部署能够满足稳定容量和高可用要求时，先评估商业版；需要横向增加接入与 Web 节点、提升设备接入和并发处理能力或明确要求集群高可用时，评估集群版。用项目自己的 POC 和压测数据做最后决定。
12.4. 本文的性能对比为什么没有排名？
因为本文没有在同一软硬件与消息模型下对三个平台做统一跑分。不同官方报告的硬件、Broker、消息大小、QoS、持久化和统计口径不同，直接排名会误导选型，所以本文只提供复测方法和证据边界。