上篇文章评论区里，“雅华出品”说了一段话，点赞7个，是评论区最高的之一：

“MQTT只是标准了传输协议，和HTTP一样，其数据协议（topic，payload）也是自定义。怎么做标准化？瞎特么扯淡。”

这句话对不对？对了一半。 但恰恰是这“另一半”，决定了工业物联网项目里MQTT到底能不能用。

他说的对的部分：MQTT确实只标准化了“信封”，没有标准化“信纸”。

MQTT协议标准（OASIS MQTT 3.1.1/5.0）定义了：

连接建立的方式（CONNECT/CONNACK）

消息传输的格式（PUBLISH/PUBACK）

QoS等级（0/1/2）

主题的语法规则（主题层级用“/”分隔）

遗嘱消息、保留消息、心跳机制

但它没有定义：

Topic应该怎么命名（是device/001/data还是factory/line1/temp？）

Payload里应该放什么（是JSON、二进制、还是Protobuf？）

每个字段的含义是什么（{"v": 25.5}里的v是电压还是温度？）

所以“雅华出品”说得对——MQTT本身确实没有定义数据层面的标准化。

但“另一半”是：MQTT生态里有“事实标准”来解决这个问题。

工业物联网领域，有两个被广泛采用的“MQTT数据规范”：

第一个是Sparkplug B。

这是Eclipse基金会发布的MQTT数据规范。它定义了：

Topic的命名规则：spBv1.0/<1group id>/<1message<1 em="">type>/<1edge nodeid>/

Payload的编码格式：使用Protobuf

消息类型：NBIRTH（节点上线）、DBIRTH（设备上线）、NDATA（节点数据）、DDATA（设备数据）、NDEATH（节点离线）

每个数据点的元数据：名称、数据类型、时间戳、工程单位

Sparkplug B解决的就是“Payload自定义”的问题。 用了Sparkplug B之后，所有设备发的数据都遵循同一个结构——上位机不需要为每个厂家的设备单独写解析逻辑。

有研究对比了MQTT Sparkplug和OPC UA，发现即使是最基本的场景，MQTT Sparkplug的效率也比OPC UA高出几个数量级-。

第二个是OPC UA PubSub over MQTT。

OPC UA基金会定义了PubSub（发布/订阅）模式，可以把OPC UA的信息模型通过MQTT传输。这意味着——你既可以享受MQTT的高效传输，又可以保留OPC UA的语义信息模型。

研究明确指出：OPC UA和MQTT是互补而非替代关系。OPC UA解决“数据语义”问题，MQTT解决“传输效率”问题。OPC UA PubSub over MQTT是把两者结合起来的方向-。

那“游客7511111111”的评论呢？

他说：“这两个不在同一维度，MQTT也可以用Netty实现啊。”——完全正确。

Netty是网络框架，MQTT是应用层协议。用Netty完全可以实现一个MQTT Broker。事实上，开源社区里有不少基于Netty的MQTT Broker实现，比如tlmqtt、mqtt-netty-broker等-。

所以“Netty vs MQTT”这个说法本身就不严谨——它们不是竞争关系，是不同维度的东西。正确的说法是：“用Netty实现自定义TCP协议” vs “用现成的MQTT Broker和客户端库”。

那工业物联网到底该用哪个？

你的场景 推荐方案 理由 设备固件可控、实时控制、几十万台设备 Netty + 自定义TCP 延迟最低、效率最高、连接数无上限 多品牌设备、数据采集、标准化接入 MQTT + Sparkplug B 标准化Payload、多厂家兼容 既有语义需求又有传输效率要求 OPC UA PubSub over MQTT 兼顾信息模型和高效传输 团队有Netty开发能力、需要极/致性能 Netty实现自定义MQTT Broker 可定制、可优化 最后说一句。

“雅华出品”的批评是有价值的——它点出了MQTT在数据标准化上的不足。但“不足”不等于“不能用”。Sparkplug B和OPC UA PubSub就是来解决这个不足的。

技术选型不是选“完美的方案”，是选“最合适的方案”。

平时我也写写代码，维护两个开源项目：

ProtoForge（工业协议仿真平台，28种协议，130+设备模板）： GitHub：suoten/ProtoForge Gitee：suoten/ProtoForge

EdgeLiteGateway（AI物联网关，13种协议采集，边缘AI推理）： GitHub：suoten/EdgeLiteGateway Gitee：suoten/EdgeLiteGateway