Broker 选型不只是软件选型。它决定了由谁负责升级、证书、身份集成、扩容、备份、事故响应，以及谁必须在系统故障时掌握恢复能力。
托管 MQTT Broker（也常被称为云 MQTT Broker）可以减少平台工作；自建 MQTT Broker 则让团队直接掌控拓扑和运行环境。两者并非天然更便宜或更安全，答案取决于真实约束和团队的运维能力。
先比较责任边界
| 维度 | 托管 MQTT | 自建 MQTT |
|---|---|---|
| 开通 | 服务创建并维护运行环境 | 团队搭建主机、网络、存储和自动化 |
| 升级 | 服务商规划并执行 Broker 升级 | 团队测试、排期、发布和回滚 |
| 可用性 | 取决于服务方案与架构 | 取决于团队实际建设的拓扑 |
| 安全边界 | 与服务商共同负责 | 团队负责完整运行时和主机边界 |
| 可观测性 | 产品内置仪表盘、日志与指标 | 团队选择、集成并维护整套系统 |
| 扩容 | 由套餐或策略驱动 | 自行做容量规划和集群变更 |
| 成本结构 | 服务费与用量更容易预测 | 基础设施、工程投入和 On-call 成本 |
| 定制能力 | 受支持的配置范围约束 | 可深入控制运行时和插件 |
自建方案最容易漏算的成本不是虚拟机，而是持续维护一个有状态、暴露在网络边界上的系统。
更适合托管 MQTT 的情况
以下场景通常更适合托管服务：
- 团队需要尽快交付设备连接能力，不想先建设 Broker 平台；
- 安全更新和证书运维不应依赖某一位专家；
- 多套环境需要以一致方式创建；
- 产品工程师希望在同一流程里查看日志、连接和权限；
- 需求尚不稳定，不希望每次扩容都变成集群项目。
采购时要确认服务商实际负责哪些工作。“已托管”并不一定意味着备份、升级和高可用都由服务商承担。
适合自建的明确理由
以下约束可以支持自建决策：
- 数据必须留在服务商无法进入的工厂或专用网络；
- 依赖托管产品不支持的 Broker 插件或协议扩展；
- 必须在完全离线环境中确定性运行；
- 组织已经具备有状态分布式系统的全天候值守能力；
- 规模巨大且长期稳定，专用基础设施确实有经济优势。
这些都是具体约束。单纯“希望拥有更多控制权”并不充分，除非团队愿意在事故中真正承担并使用这份控制权。
安全责任不会消失
托管服务可能负责运行时安全、Broker 补丁和身份控制能力，但使用方仍然需要负责：
- 设备凭据生命周期；
- 主题级发布、订阅策略；
- 载荷数据分类；
- 客户端 TLS 证书校验；
- 应用侧授权；
- 设备泄露后的事故响应。
自建方案还要额外承担操作系统加固、网络暴露、证书自动化、升级策略、密钥存储、备份恢复和集群安全。
可以用 MQTT 安全指南中的同一套基线评估两种方案。
把工程时间纳入总成本
完整成本至少包括：
Broker 基础设施
+ 网络与存储
+ 监控与日志
+ 备份与恢复
+ 日常工程维护
+ On-call 与事故成本
+ 容量冗余
比较时必须使用相同的工作负载、可用性目标、保留策略和支持要求。单台小型自建节点与生产级托管集群并不是等价单位。
工程投入需要换算成与服务账单一致的月度成本。估算升级、证书轮换、可观测性、容量评审、备份、On-call 和事故恢复的工时，再乘以团队的完整人力成本。事故影响应单独计入，不要假设每个月都不会发生故障。
至少按三档负载建模。自建 MQTT Broker 在稳定低流量时可能很便宜，但高可用、跨地域容灾或集中重连需要调整拓扑时，成本会迅速增加。托管 MQTT 的基础费用可能更高，但它可以消除团队原本必须配人、演练和持续维护的工作。
不要因为工程师已经在公司任职，就把工程时间视为免费。真正需要比较的是：团队在运维 Broker 时，会放弃哪些产品、安全或可靠性工作。
决策前先演练一次迁移
无论迁往托管还是自建环境：
- 盘点 MQTT 版本、传输方式、认证、ACL、主题、QoS 和会话设置；
- 用有代表性的客户端连接目标环境；
- 有意复现保留消息、持久会话与离线队列；
- 压测重连风暴，而不仅是稳态吞吐；
- 制定 DNS、证书、凭据和回滚方案；
- 在可控切换期间同时观察新旧系统。
MQTT 客户端通常让 Broker 迁移相对直接，但会话状态和授权细节仍可能带来意外。
一个务实的结论
如果 Broker 运维并非产品差异点，且托管服务满足安全、网络和地域要求，优先选择托管 MQTT。如果存在明确的技术或合规约束，且收益足以覆盖长期运维责任，再选择自建——并把它当作平台来投入，而不是顺手维护的副项目。
最终决策前，用下面的约束清单复核：
- 是否必须在本地或完全离线环境运行？
- 是否依赖托管服务不支持的插件、协议扩展或网络拓扑？
- 团队能否全天候负责升级、安全响应、备份和恢复？
- 两种方案是否按相同可用性与支持标准比较？
- 是否演练过集中重连、Broker 故障和回滚？
- 自行运维 Broker 能否形成长期产品优势？
如果前两项为否，最后一项也为否，托管 MQTT 通常是风险更低的默认选择。如果仍需自建，应在部署前明确责任人和服务目标。
你可以继续查看 托管 MQTT 功能、价格方案，也可以先用公共 MQTT Broker完成一次性客户端验证。