RunMQTT 入门：如何验收前 100 台设备

MQTT 试点的目标不是证明“一台设备可以成功发消息”，而是回答系统能否继续扩展。在设备数量超过最初的 100 台之前，团队需要拿到关于身份、授权、投递、恢复和真实运维能力的证据。

这份验收表用于把 RunMQTT 试点转化为明确的通过或失败结论。建议由固件、后端、安全、支持，以及依赖设备数据的产品目标负责人共同完成。

先定义试点退出标准

测试开始前先写验收标准。一份有效的评分表衡量结果，而不是完成了多少操作：

“连接成功”不能单独作为验收项。每个标准都必须有阈值、证据来源、负责人和验证日期。

1. 限定试点负载

先定义边界清晰的首批设备，而不是从最终规模倒推所有设计。

• 列出首批上线的设备型号和固件版本。
• 估算并发连接数、平均载荷大小、稳定发布速率和突发峰值。
• 标出不能丢失或重复的指令与事件。
• 写明对产品真正有影响的延迟和可用性目标。
• 明确 Broker、设备注册表、下游消费者和事故响应的负责人。

将这些假设整理为压测模型。如果容量数据仍然来自猜测，应先采集试点设备的真实流量并在预发布环境回放。

2. 固化主题与载荷契约

在批量创建设备前，先写出有代表性的发布和订阅示例。主题层级需要表达稳定的所有权和消息方向：

prod/{tenant}/{site}/{deviceId}/telemetry
prod/{tenant}/{site}/{deviceId}/state
prod/{tenant}/{site}/{deviceId}/command

记录字段、单位、时间戳、Schema 版本、最大载荷、QoS、Retain 和过期规则。加入拒绝场景测试：一台设备不能冒充另一台设备发布，也不能订阅自身前缀之外的主题。

更完整的方法见 MQTT 主题设计指南。

3. 证明设备之间真正隔离

设备凭据属于基础设施，不能当作表格里的普通字段管理。

1. 为生产环境创建专属 Broker，不复用公共或预发布端点。
2. 为每台设备或职责单一的客户端签发唯一身份。
3. 只授予该身份必要的发布和订阅过滤器。
4. 所有生产连接启用 TLS 并校验服务端证书。
5. 设备支持时，将密钥保存在硬件安全区或受保护的应用存储中。
6. 在首批设备出厂前完成轮换和吊销演练。

共享凭据会放大单台设备泄露的影响，也无法单独吊销。完整的 TLS、身份和主题授权模型见 MQTT 安全指南。

4. 演练端到端消息链路

不要只验证“成功连接 Broker”，而要覆盖端到端链路：

• 使用与生产固件相同的客户端库和 TLS 设置连接；
• 按实际用途分别验证 QoS 0 和 QoS 1；
• 检查所有订阅者、转换任务、数据库、告警和看板；
• 强制断开设备，确认 Last Will 行为；
• 注入 QoS 1 重复消息，验证消费者幂等性；
• 模拟离线后重连，检查会话、重试和过期规则；
• 尝试越权主题，确认 Broker 明确拒绝。

仅用于测试的免费公共 MQTT Broker适合用合成数据验证客户端基础连接。负载测试或接近生产的数据必须使用隔离的托管 Broker。

5. 让故障可以被定位

在故障发生前建立告警，至少覆盖：

• 当前与峰值连接数；
• 连接抖动和认证失败；
• 发布速率、载荷大小与处理延迟；
• 排队和过期消息；
• 下游消费者延迟与错误率；
• Broker 健康状态和计费状态。

每条告警都要有负责人、基于负载模型的阈值和简短 Runbook。上线窗口还需明确回滚条件，以及谁有权限轮换凭据、禁用客户端或暂停发布。

6. 用证据决定下一批扩展

按批次发布，避免固件或策略错误影响整个设备群。

1. 先连接内部金丝雀设备。
2. 观察一个完整业务周期，而不是只看几分钟流量。
3. 扩展到一个小型客户或站点批次。
4. 对比实际连接数、吞吐、延迟、失败率与预测。
5. 达到约定阈值时自动暂停。
6. 上一批稳定后再继续扩量。

为每个批次记录固件版本、策略模板、Broker 套餐和主题 Schema，这会显著降低回滚与事故分析成本。

7. 在 48 小时内形成扩展结论

试点结束后，逐项对比验收标准与真实行为，记录异常重连、噪声主题、授权拒绝、载荷增长和 Runbook 缺口。每个门槛都应标记为通过、失败，或由明确负责人接受风险。

最终产物是一项扩展决策，而不是一份复盘幻灯片：扩大设备批次、延长试点补充证据，或者停止扩展并修复失败的边界。

如果试点已经需要独立运行环境，可以查看 MQTT Broker 定价与套餐，或直接创建账户部署第一个托管 Broker。