最近在做几个工业项目时，遇到一个反复出现的问题，想和大家讨论一下。

现场设备大多是：

• TCP 私有协议

• 固定长度 / TLV / 混合报文

• 文档不完整，字段还会调整

但很多平台的处理方式是：

协议解析和业务逻辑强耦合

结果就是：

• 协议一改，代码就要动

• 规则、报警、报表全部跟着改

• 项目周期不可控

常见几种处理方式，各自的问题

1️⃣ MQTT 中间件套一层

优点：

• 上手快，看起来“标准化”

问题：

• 私有协议仍要写代码

• MQTT 解决的是传输，不是解析

• 最终复杂度没有下降

2️⃣ 微服务 + 消息中间件

优点：

• 架构“看起来很先进”

问题：

• 中小项目运维成本极高

• 现场机器资源有限

• 实际交付周期反而拉长

  
  

我在项目中尝试的一种思路

把协议当“数据结构”，而不是“业务入口”。

做法是：

• 协议只负责解析变量

• 业务规则基于变量执行

• 协议变化，不影响业务链

这样带来的变化是：

• 新设备接入不推翻原有规则

• 多协议可以并行存在

• 项目维护成本明显下降

架构上做了哪些取舍？

• 单体结构，避免过度拆分

• 不依赖消息中间件

• 网络层直接处理 TCP / UDP

• 规则、报警、控制在同一进程内完成

优点是：

• 部署简单

• 现场稳定

• 排错成本低

缺点也很明显：

• 不适合追求“平台生态”

• 更偏向工程交付场景

想听听大家的做法

想请教下各位工控同行：

• 私有协议经常变，你们是怎么处理的？

• 是忍着改代码，还是有更好的抽象方式？

• 对中小工业项目，微服务真的有必要吗？

有类似经历的朋友，欢迎交流一下。