物联网平台架构怎么设计？从四层模型到边云协同的完整拆解与选型清单

很多人问「一个 MQTT Broker 能扛多少设备」，这个问题没法直接回答，因为真正的容量公式是：

按这个公式，可以把接入层分成三档。三档之间的差别不只是「加机器」，而是组件形态要变。

除了容量，接入层还有三个必须提前定死的参数，定错了后期改起来很痛：

• 心跳间隔（keepalive）：默认 60 秒。设太短，10 万台设备的空心跳就能打满 Broker；设太长，设备掉线要 3 倍时间才能发现。建议 60-120 秒，配合服务端主动探测。
• 重连退避：设备断网恢复后如果同时重连，会造成「惊群」。必须让设备端做指数退避加随机抖动，否则一次基站切换就能把 Broker 打挂。
• QoS 等级：QoS 2 的开销是 QoS 0 的 4 倍以上。除了计费类指令，其余全部用 QoS 0 或 1。见过一个项目全链路 QoS 2，10 万台设备的吞吐只有理论值的四分之一。

还有一个常被忽略的点：设备离线判定和业务告警要分开。设备离线是通信层事件，业务告警是应用层事件。把两者混在一起，会导致「网络抖一下，值班手机响一片」。正确做法是设备离线超过 3 个心跳周期才置为离线，超过 10 分钟才发业务告警。

「边缘计算」这个词被用得过度了，很多项目把边缘当成一个技术时髦，结果部署了一堆边缘盒子，运维成本翻倍，收益却说不清。判断标准其实只有四条，按顺序问：

举个最典型的例子：停车场道闸。断网时车还得出去，所以「识别车牌 → 比对白名单 → 抬杆」这一整条链路必须在本地完成，云端只负责同步白名单、记录流水、做跨场站的对账。这类业务如果设计成「识别后请求云端判断」，一次网络抖动就会堵住出口。

反过来，边缘不适合做的事情也很明确：

• 跨站点对比分析——边缘只有本站数据，做不了横向比较
• 长期趋势和同比环比——边缘存储有限，保留不了几年数据
• 复杂规则和模型推理——边缘算力有限，模型更新也麻烦
• 统一权限和审计——分散在各站点无法统一管控

把上面的内容收拢，实际项目里 90% 落在三种架构之一。这张表可以直接用来做方案对比和报价参考。

三个提醒：

1. 1500 台设备以下不要上微服务。拆分带来的部署复杂度、链路追踪成本，远大于它带来的弹性收益。一套单体应用加一个消息队列，足够跑到 5000 台。
2. 2边缘盒子的成本不要只看硬件。每个站点的上门部署、调试、后续固件升级，人工成本通常是硬件价格的 2-3 倍。
3. 3云服务器的钱可以省，数据库的钱不要省。见过太多项目在 4 核 8G 的机器上跑时序库，然后抱怨查询慢。

自建物联网平台还是买现成的？

看两件事：设备协议复杂度，和业务差异化程度。协议种类多、厂商杂（比如要对接几十家不同品牌的电表、空调、传感器），自建的对接成本很高，建议买现成平台再二次开发。业务逻辑是核心竞争力（比如停车场的计费规则、充电桩的分时电价），这部分必须自己写，但底层的接入和存储可以买。

MQTT 一定要用吗？能不能直接用 HTTP？

设备端能稳定保持长连接、需要服务端主动下发指令，就用 MQTT。设备只能短连接、上报频率很低（比如一天几次）、或者设备是电池供电且要极致省电，HTTP 或 CoAP 更合适。很多项目是混合的：主链路 MQTT，配置下发和文件传输走 HTTP。

边缘计算节点用什么硬件？

看算力需求。只做协议转换和数据聚合，ARM 架构的工控机（4 核 2G）就够，成本几百到一千多。要做视频分析和本地 AI 推理，才需要上带 GPU 或 NPU 的设备，成本会到几千。不要为了「以后可能要跑 AI」提前上高配，边缘设备的迭代周期比云端快得多。

架构设计阶段需要做压力测试吗？

必须做，而且要用真实设备或真实报文做。用脚本模拟的 MQTT 客户端，行为和真实设备差别很大——真实设备会有重连风暴、会有报文格式错误、会有半开连接。建议在架构定稿后、开发开始前，用 100 台真实设备跑一次 72 小时稳定性测试，能提前暴露大部分接入层问题。