工业现场数据上云的四种传输方式对比：MQTT、HTTP、OPC UA发布订阅与消息队列怎么选

结论：设备数据上云没有万能协议。弱网、多设备、需要下行控制时优先MQTT；数据量小、对实时性要求低时HTTP批量上报更简单；已有OPC UA体系可考虑其发布订阅；云端内部解耦再用消息队列。

一、MQTT：边缘到云的常见选择

MQTT基于发布订阅，头部开销小，支持三档QoS：0最多一次，1至少一次，2恰好一次。现场通常用QoS1，再靠消息中的唯一ID在云端做幂等去重。主题设计建议分层，例如 工厂/产线/设备/数据类型，便于按层订阅和授权。需要注意：保持连接的心跳间隔与遗嘱消息（LWT）要设置，才能及时发现设备离线；会话保持（持久会话）可在短暂断线后补收下行指令。

二、HTTP批量上报：简单但有边界

边缘网关把数据攒成批，按固定周期POST到云端接口。优点是穿越防火墙容易、排查直观；缺点是实时性受批周期限制，且没有天然的下行通道。适合温湿度、能耗等低频数据。务必在报文里带上批次号和采集时间戳，失败后用相同批次号重试，云端据此去重。

三、OPC UA发布订阅：适合已有统一信息模型的场景

OPC UA PubSub可以通过MQTT或UDP传输，优势是沿用设备的信息模型，语义信息完整。代价是配置复杂，不同厂商支持程度不一，上线前需逐台确认设备是否支持，不能默认可用。

四、消息队列：云内解耦，不是边缘接入

Kafka、RocketMQ之类用在云端接收后的分发：一份数据同时给存储、告警、报表消费。它一般不直接面向设备，设备侧仍需MQTT或HTTP作为入口。

选型判断清单

1. 网络是否经常中断？是则优先MQTT加本地缓存。
2. 是否需要云端下发指令或参数？需要则排除纯HTTP上报。
3. 单设备上报频率与设备总数是多少？据此估算连接数和吞吐。
4. 设备本身支持哪些协议？先查设备手册，再定网关方案。
5. 数据丢失可接受到什么程度？据此决定QoS和重传策略。

常见坑

时间戳用云端接收时间而不是采集时间，导致补传数据乱序；主题层级过深，权限难以管理；证书过期后设备集体掉线，需要提前规划证书轮换。

FAQ

问：MQTT QoS2要不要用？

答：开销较大，多数场景QoS1加幂等已足够。

问：能否多种方式混用？

答：可以，按数据类型分流，高频走MQTT，低频报表数据走HTTP。

小结：先看网络、下行需求和设备能力，再选协议；无论哪种，都要有唯一ID、采集时间戳和本地缓存。