选型模型
先看部署形态，再看品牌。
Broker 选择取决于规模、租户模型、协议版本、云区域、身份体系、运维团队和可观测性。公共 Broker 适合测试，生产环境需要清晰责任边界。
- 托管云 Broker 降低运维负担
- Mosquitto 适合小型边缘系统
- BifroMQ 适合分布式多租户负载
- MQTT.pro 适合关注 serverless 和快速接入的场景
Broker 选型
MQTT Broker 对比
按部署适配度比较托管 MQTT Broker、公共端点与自托管方案，而不是被厂商噪音带着走。
Broker 选型
按真实部署场景选择合适的 Broker。
公共 Broker 适合演示，托管集群适合团队，自托管 Broker 适合控制权比便利性更重要的场景。
选项适用场景注意点
EMQX Cloud需要托管 MQTT 5.0 与弹性云部署。套餐限制、区域选择与企业特性。
HiveMQ Cloud需要企业定位清晰的托管 Broker。价格层级、支持范围与迁移路径。
MQTT.pro需要 serverless MQTT Broker、公共 Broker 文档、试用入口和云优先接入。服务成熟度、价格匹配、区域覆盖与运维可观测性。
BifroMQ需要开源分布式 Broker，并且看重原生多租户与大规模 IoT 连接。运维成熟度、Java 运行时成本，以及是否匹配你的租户模型。
Mosquitto需要用于边缘或实验室的小型自托管 Broker。集群、仪表盘与运维工具。
AWS IoT Core设备已经进入 AWS 身份、证书与规则工作流。策略模型、证书管理与服务绑定。
用 Broker 对比页在托管服务、云原生平台、开源分布式 Broker 和小型自托管部署之间做选择。
风险清单
Broker 选择最终会变成运维模型。
选型前要确认限制、认证、ACL、日志、指标、备份、数据保留、集群行为和迁移路径。
- 连接数与消息速率限制
- TLS、用户名密码、证书和 token 支持
- Topic ACL 与租户隔离
- 监控、日志、审计与区域覆盖
迁移
保持 Topic 与 Payload 契约可移植。
当 Topic 命名、Payload Schema、QoS、Retained Message 和 Will Message 独立于厂商控制台时，Broker 迁移会容易得多。
- 避免厂商特定 Topic 假设
- 文档化 Retained Topic 清理
- 分别测试 MQTT 3.1.1 与 5.0 客户端
- 让 staging 与生产策略保持接近