我见过一种很常见的冲动：一聊 MES，就想做平台化。
统一设备接入平台、统一数据中台、统一工厂模型、微服务、Kafka、数据湖、多基地治理。
这些东西不是没价值。但如果工厂现在只有两三条产线，最急的是让工单、扫码、测试和追溯跑起来，一上来就做平台化，很容易把项目拖重。
MES 部署要跟现场规模走。
MES 部署最容易一开始想大。
平台化、微服务、统一网关、统一采集、统一权限，听起来都很好。但如果第一条线还没跑稳，现场异常还没摸清，过早铺太大，后面维护压力会很重。
我更倾向于让系统先在一条产线上跑出闭环。
先把采集、过站、报工、追溯、异常补录这些基本动作跑稳，再考虑怎么复制到更多车间。现场系统最怕第一步还没踩实，就开始追求“完整平台”。
一、小工厂先跑通一条线
小工厂第一阶段，我会选一条最有代表性的产线。
比如一条散热器装配测试线，先跑通：
- 工单下发。
- SN 扫码。
- 锁螺丝机或测试机采集。
- 测试结果绑定。
- 质量判定。
- 产线看板。
- 基础追溯。
部署可以简单：
边缘 Agent
-> MQTT / RabbitMQ
-> .NET Worker
-> MES API
-> 业务库 + Redis + 采集库
-> Web 看板一台服务器或少量服务器就可以。
这个阶段不要追求所有车间、所有设备、所有报表一次做完。
先证明系统能在现场跑，并且跑出来的数据可信。
二、中型工厂开始补稳定性
当产线变成 5 条、10 条，设备数量明显增加，系统就不能只靠一个服务硬撑。
这时要考虑：
- 边缘节点按产线或车间部署。
- 消息队列削峰。
- 实时处理 Worker 多实例。
- Redis 保存实时状态。
- 采集库或时序库保存高频数据。
- 业务库只保存关键业务事件。
- 监控覆盖边缘节点、消息队列、Worker、数据库和看板。
中型工厂最重要的是稳定性。
某条线边缘节点异常，不能影响其他线。
某台测试机数据格式异常，不能拖垮整个消费服务。
看板慢了，不能影响工序过站。
三、多基地才真正需要平台化
如果有多个工厂、多个车间、不同设备品牌、不同产品线，平台化才真正有必要。
这时要解决的是治理问题：
- 统一设备模型。
- 统一点位配置。
- 统一工厂、车间、产线、工位模型。
- 统一边缘节点管理。
- 统一监控告警。
- 统一主数据。
- 统一外部系统集成。
- 统一数据口径。
到了这个阶段，再引入更完整的消息平台、数据湖、规则引擎、集中运维，会更合理。
太早做，团队会被复杂度拖住。
四、即使小规模，也要保留边界
小工厂不代表代码可以随便写。
即使部署简单，边界也要清楚：
设备接入
实时处理
业务 API
看板
外部系统同步
数据存储第一版可以部署在一起，但代码和数据模型不要揉成一团。
否则从一条线扩到多条线时，真正痛苦的不是加机器，而是拆代码。
五、我会按这个节奏演进
比较稳的路径是：
一条产线闭环
-> 多产线接入
-> 边缘节点分线部署
-> 消息和实时处理扩容
-> 监控告警补齐
-> 外部系统集成
-> 多工厂平台化每一步都对应现场的真实需要。
不要为了未来可能的复杂度，把第一阶段做成一个大平台。
也不要因为第一阶段简单，就把所有边界写死。
六、小结
MES 架构没有固定模板。
小工厂先打通现场闭环。
中型工厂重视稳定和监控。
多基地再做平台化和治理。
架构最怕两种极端：小系统过早复杂化，大系统长期简陋化。
合适的复杂度，才是现场落地的关键。
本系列：
暂无评论