ThingsBoard 替代选型：FastBee 适配场景、许可边界与迁移 POC
如果你的团队正在评估 ThingsBoard 之外的自托管物联网平台，FastBee 值得进入 POC 名单：它把设备管理、物模型、规则脚本、场景联动、可视化和移动端放在一条完整的产品路径上，开源版内置 MQTT Broker、Docker 一键部署，商业版与集群版提供永久授权和对应源码交付。对使用 Java 与 Vue 技术栈、需要私有化交付中小型商业项目的团队，这是一条容易掌控的路线。
同时，ThingsBoard 在规则链生态、LwM2M/CoAP 原生接入、微服务化横向扩展和全球社区方面仍然成熟，适合需要这些能力的团队继续使用。不存在脱离项目约束的普遍最优解，本文只提供可核验的事实与决策方法。
1. 范围与证据边界
本文更新于 2026 年 10 月 31 日，事实陈述基于 ThingsBoard 官方文档、GitHub 官方仓库 README 与 LICENSE 文本，以及 FastBee 官方文档与公开授权页，来源见文末。
这不是统一基准测试。 ThingsBoard 官方文档给出的容量指导值与 FastBee 官方发布的压测报告，使用不同硬件、Broker、报文大小、QoS 与持久化策略，两者的数字不能直接互相换算或排名。连接数、TPS、端到端延迟与恢复时间必须在项目 POC 中以相同条件重新测量。
本文区分两类陈述：
- 可核验事实：许可文本、公开技术栈、官方列出的能力与交付方式，附来源。
- 选型建议：基于团队技能、项目规模、商业交付与运维约束的判断，不是第三方实验室结论。
2. 结论先行：适配场景速查
| 场景 | 建议 |
|---|---|
| Java + Vue 团队，私有化交付中小型商业项目，需要授权源码与清晰的一次性采购 | 优先 POC FastBee 商业版 |
| 需要 GB/T 28181 视频接入、Modbus/JT808 等工业协议、微信小程序与移动端的国内项目 | 优先 POC FastBee 商业版 |
| 需要原生 LwM2M/CoAP/SNMP 传输、成熟规则链与控件生态、全球社区资源 | 继续评估 ThingsBoard |
| 微服务化拆分、超大规模设备接入、独立扩展传输层的平台工程团队 | 继续评估 ThingsBoard（微服务架构） |
| 商业生产但设备量很小（官方附加授权条款内），可保留品牌署名 | 可评估 ThingsBoard 4.4+ 的免费生产额度，以官方条款为准 |
| 大量存量工业设备经网关接入 | 两者都走网关路径：ThingsBoard IoT Gateway 或 FastBee 协议实践方案，各自 POC |
「建议」列是选型判断，不是功能或性能排名。两边涉及商业生产的条款都应由法务或采购负责人核对原文。
3. 许可与商业使用边界
许可条款决定平台能否合法用于目标项目，必须先于功能对比确认。
ThingsBoard 的许可在 4.4 版本发生变化。 官方 GitHub 仓库 README 声明：自 4.4 起平台采用 Business Source License 1.1（BUSL，源码可用而非 OSI 定义的开源许可），可自由阅读、构建、修改、分发并用于开发测试；生产使用在「附加使用授权」（Additional Use Grant）范围内免费，超出范围或需要去除品牌署名则需商业许可；每个版本发布满四年后转为 Apache 2.0，4.4 之前的版本保持 Apache 2.0。LICENSE 文本中的附加使用授权要点：非商业用途全组织设备不超过 1,000 台，或商业用途设备不超过 100 台且仅部署在一台服务器；同时要求界面保留 "Powered by ThingsBoard" 署名、生产使用持有官方免费签发的许可密钥且不得绕过密钥功能。云服务与专业版按官方定价页以设备数等维度订阅计费，白标能力出现在较高档位。
FastBee 的版本边界见商用授权页：开源版采用 AGPL 3.0，限非商业用途；商业版与集群版为永久授权（安装证书），授权后通过私有 Git 获得对应版本源码并赠送一年源码更新；授权用户不得直接销售和分发商业版源码。开源版没有设备数条款，但 AGPL 的传染性义务与非商业限制意味着商业交付必须走授权版本。
对决策的含义：两个生态对严肃商业生产都不是「免费随便用」，差别在于计费口径（设备数/服务器数对一次性永久授权）、Copyleft 义务（AGPL 对 BUSL/Apache）与署名要求。不要用第三方转载的旧价格或旧许可状态做采购依据。
4. 架构与运维边界
| 维度 | FastBee | ThingsBoard |
|---|---|---|
| 主要技术栈 | Spring Boot + MyBatis + Vue 前后端分离，UniApp 移动端 | Java（Spring），Web UI 为 Angular 应用 |
| 最小部署 | 开源版 Docker Compose 单机一键部署，内置 Netty MQTT Broker，无需独立 Broker | 单体模式单 Java 进程，官方建议 2–4 GB 内存；单节点仅需 PostgreSQL |
| 存储 | MySQL + Redis 默认；时序数据可选 TDengine、IoTDB、InfluxDB | PostgreSQL 必选（实体）；时序可选 SQL（PostgreSQL）或 Hybrid（Cassandra） |
| 集群形态 | 集群版：FMQ 服务集群 + Web 集群，配合 Kafka 与负载均衡 | 单体集群需 Zookeeper + Kafka + 负载均衡；微服务模式可按服务独立扩展 |
| 官方容量口径 | 商业版压测报告基于其测试环境发布 | 官方文档指导：单体典型上报频率下 5–10 万台设备；SQL 存储 ≤5–10K 数据点/秒，Hybrid（Cassandra）约 1M 数据点/秒 |
运维边界是真实成本：ThingsBoard 规模化后需要维护 Kafka、Zookeeper、（可选）Cassandra 与多服务进程，平台工程门槛更高，但获得按服务独立扩展的能力；FastBee 组件更少、小团队即可运维单机与中小型部署，大规模横向扩展则依赖集群版，必须以同环境压测验收。两边官方数字的测试条件不同，只能作为各自架构的参考，不能互除推算倍数。
5. 设备接入与协议
ThingsBoard 平台内置 MQTT、HTTP、CoAP、LwM2M、SNMP 传输服务，设备凭据支持 Access Token、MQTT Basic 与 X.509 证书；Modbus 等工业存量协议经独立的 ThingsBoard IoT Gateway 组件以连接器方式接入，网关作为额外部署单元存在。
FastBee 开源版聚焦内置 MQTT（TCP 1883 + WebSocket 8083）与 GB/T 28181 视频直播，设备认证采用 clientId/userName/password 模型（设备编号、产品 ID、设备密钥，见 MQTT 接入）；商业版在此之上增加 TCP、UDP、CoAP、HTTP、Modbus、JT808 等协议，完整边界见授权页功能矩阵。存量工业设备的网关与寄存器映射可参考协议实践文档。
无论选择哪个平台，都用三台代表性设备验收：一台标准 MQTT 设备、一台存量工业设备、一台现场弱网设备，覆盖注册、上下行、重连与诊断日志。模拟器发通数据不等于现场可用。
6. 规则引擎与可视化
ThingsBoard 的核心是规则链（Rule Chain）：以节点图编排过滤、转换、告警与外部集成，脚本节点在独立的 JS Executor 沙箱中执行；配合 Angular 仪表盘控件库、告警体系与「租户 → 客户 → 设备/资产」层级，生态成熟、可配置空间大。
FastBee 提供基于 Groovy（语法同 Java）的规则脚本、场景联动与可视化规则设计器（可视化设计器属商业版能力），告警中心可对接短信、语音、钉钉、企业微信等国内通知渠道，另有可视化大屏、报表与可选的 Web 组态模块，能力与产品、设备、行业应用在同一产品上下文内，集成工作更少。
关键提醒：两边规则模型不是一一对应关系。ThingsBoard 的节点式规则链无法直接导入 FastBee，迁移意味着用规则脚本与场景联动重新实现业务逻辑——这正是 POC 要测量的工作量。
7. 迁移发现：概念映射与差距
先说结论：没有从 ThingsBoard 到 FastBee 的自动化迁移工具，迁移应按「概念映射 + 业务重实现 + 数据搬迁」组织，而不是寻找一键转换。
| ThingsBoard 概念 | FastBee 对应 | 迁移方式 |
|---|---|---|
| Device Profile | 产品 + 物模型 | 按物模型重建属性、功能、事件定义 |
| Telemetry Key/Value | 物模型属性与事件 | 上报报文改为物模型协议格式 |
| Access Token 设备凭据 | 设备编号 + 产品 ID + MQTT 认证参数 | 按 MQTT 接入模型批量重新签发并下发 |
| Rule Chain（规则链） | 规则脚本 / 场景联动 | 逐条梳理后重新实现，无法导入 |
| Dashboard / Widget | 可视化大屏 / 报表 / Web 组态（可选模块） | 按页面清单重建 |
| Tenant / Customer 层级 | 多租户与数据权限（商业版） | 重新设计租户与权限模型 |
| ThingsBoard Edge | 边缘场景需单独评估 | 参考 FastBee 网关文档与项目实际需求 POC |
主要差距与风险：历史遥测数据需要经 ThingsBoard REST API 导出、按物模型转换后写入新平台并抽样校验；规则链中的外部系统集成（Kafka 转发、REST 调用等）要在 FastBee 侧用数据桥接或规则脚本等价实现并回归；迁移期间通常需要新旧平台并行运行一段灰度期。决策前先钉住当前使用的 ThingsBoard 版本号与其许可条款，4.4 前后的许可义务不同。
8. 推荐的两周 POC 清单
| 项目 | 最低验收标准 | 需要的证据 |
|---|---|---|
| 许可与源码 | 目标版本许可允许目标用途，源码与第三方组件边界成文 | 授权矩阵、许可文本、仓库访问记录 |
| 真实设备 | 三台代表性设备完成注册、上下行、重连与诊断 | 设备清单、抓包、操作日志 |
| 业务闭环 | 上报触发规则、产生告警、通知到人、下发控制并留痕 | 规则配置、告警记录、截图 |
| 迁移工作量 | 一条真实规则链在目标平台等价实现并回归 | 实现记录与工时 |
| 安全 | 认证、越权、Topic/API 权限、密钥管理、升级流程检查通过 | 测试用例与整改记录 |
| 性能 | 同硬件同报文模型下稳定连接数与吞吐达到项目目标 | 原始压测脚本、监控与结果 |
| 故障恢复 | 断网、重启、节点故障可诊断、可恢复且无不可接受的数据丢失 | 故障注入记录 |
| 运维 | 实际运维人员独立完成备份、恢复、日志、监控、升级与回滚 | 操作手册与演练记录 |
9. 官方来源与延伸阅读
以下来源支撑本文的事实陈述，核验日期为 2026 年 10 月 31 日：
- ThingsBoard：官方 GitHub 仓库（README 许可声明）、LICENSE 文本（BUSL 1.1 与附加使用授权）、架构参考、单体部署参考、官方定价页、IoT Gateway 文档与 Modbus 连接器配置。
- FastBee：商用授权与功能矩阵、开源版总览、商业版平台介绍、集群版文档、MQTT 接入与行业案例。
- 延伸阅读：2026 国产开源 IoT 平台横向评测：FastBee、JetLinks 与 DGIOT。
10. 常见问题
10.1. FastBee 能完全替代 ThingsBoard 吗？
不存在普遍意义的「完全替代」。FastBee 适合 Java + Vue 团队私有化交付中小型商业项目，提供永久授权与对应源码；ThingsBoard 在规则链生态、LwM2M/CoAP 原生接入与微服务横向扩展上仍然成熟。用本文的 POC 清单在相同条件下验证后再做决定。
10.2. ThingsBoard 4.4 之后还是 Apache 2.0 吗？
不是。官方 README 与 LICENSE 文本表明 4.4 起采用 BUSL 1.1：开发与测试自由，生产使用在附加使用授权范围内免费（非商业 ≤1,000 台设备，或商业 ≤100 台设备且单服务器，保留品牌署名并持有官方许可密钥），每个版本发布满四年后转为 Apache 2.0；4.4 之前的版本保持 Apache 2.0。商业使用前请核对官方许可原文。
10.3. ThingsBoard 的规则链能直接导入 FastBee 吗？
不能。两边规则模型不同：规则链需按业务逐条梳理，在 FastBee 侧用 Groovy 规则脚本或场景联动重新实现。把「一条真实规则链的等价重实现」放进 POC 验收项，可以直接测出迁移工作量。
10.4. 迁移 POC 最关键的验收项是什么？
真实设备接入与完整业务闭环：上报、规则、告警、通知、控制与历史数据全部走通，其次是同环境压测与故障注入。只验证页面能打开、模拟器能发数据，不足以支撑迁移决策。