用 .NET 做 MES，我觉得是很自然的。
ASP.NET Core 做业务 API，Worker Service 做后台消费，SignalR 做看板推送，Redis 存实时状态，RabbitMQ 或 MQTT 接设备消息，SQL Server 或 PostgreSQL 存业务数据。
但真正进现场以后会发现，Web API 只是 MES 的一部分。
很多麻烦活都不在页面请求里。
用 .NET 做 MES，真正麻烦的地方往往不在 Web API。
Web API 只是最容易被看到的一层。后面还有采集服务、后台任务、实时推送、日志、部署、Windows 服务或 Linux 容器、和现场网络打交道的一堆细节。
我见过一些系统，接口写得很整齐，但一到现场就暴露问题：服务重启后状态没恢复，日志查不到设备原始报文，采集程序异常退出没人知道。
这些才是 .NET 落到 MES 现场时真正要补齐的部分。
一、Web API 不要吞下所有职责
如果把所有逻辑都塞进 Web API，早期开发会很快。
工单、质检、扫码、设备上传、看板刷新、ERP 同步，全在一个项目里。
但设备数据一多，它就会变成大杂烩。
我更倾向于拆成这些边界：
MES.Api
MES.Worker.Realtime
MES.Worker.Integration
MES.Edge.Agent
MES.Web
MES.Shared.Contracts
MES.InfrastructureMES.Api 处理工单、质检、追溯、报表、设备档案。
MES.Worker.Realtime 消费设备消息，做清洗、去重、状态计算、事件化和落库。
MES.Worker.Integration 同步 ERP、WMS、PLM 等外部系统。
MES.Edge.Agent 部署在边缘侧，读 PLC、测试机、扫码枪或现场文件。
MES.Web 做管理端和看板。
二、Worker 是现场数据的处理工位
设备数据不是典型的请求响应。
它是持续流入的。
边缘节点把数据发到消息队列，中心 Worker 持续消费：
- 校验消息格式。
- 判断是否重复。
- 更新 Redis 实时状态。
- 写入时序库或采集库。
- 识别过站、报警、测试完成等业务事件。
- 写入业务库。
- 推送看板刷新。
这样 Web API 不需要被设备高频写入拖垮。
更重要的是，现场数据处理可以单独扩容、单独重启、单独监控。
三、边缘 Agent 要能在车间活下来
边缘 Agent 可能部署在工控机、边缘服务器或产线旁的小主机上。
它不一定要功能很花，但要可靠。
它要做：
- 加载点位配置。
- 连接 PLC 或设备。
- 轮询或订阅数据。
- 做数据类型和字节序转换。
- 本地缓存关键数据。
- 上传中心。
- 记录本地日志。
- 暴露健康检查。
- 支持自动重启。
如果边缘 Agent 出问题，现场数据就断了。
所以它的设计要比普通后台任务更谨慎。
比如本地缓存不能只放内存，日志不能只写控制台，配置变更要能追溯，重启后要能继续补传。
四、数据库选型要看数据类型
业务库可以用 SQL Server 或 PostgreSQL。
设备高频数据可以用 TimescaleDB、InfluxDB，或者先用 PostgreSQL 分区表过渡。
Redis 用来放当前状态和看板缓存。
文件存储放检测图片、测试报告和设备日志。
不要为了“统一”把所有数据都塞 SQL Server。
也不要为了“先进”引入一堆团队不会维护的组件。
现场系统最重要的是稳定可维护。
五、第一版可以小步走
我会按这个顺序落地：
1. 接一条产线的关键设备。
2. 打通边缘采集 -> 消息 -> Worker -> 看板。
3. 接工单和 SN。
4. 绑定测试结果和质量追溯。
5. 补断网缓存、幂等、监控告警。
6. 再扩多产线和外部系统。这比一开始就做完整平台更稳。
第一阶段不要把所有技术一次上满，但要把边界设计清楚。
六、小结
.NET 做 MES，技术栈本身不是问题。
真正要想清楚的是：哪些逻辑在 API，哪些逻辑在 Worker，哪些逻辑在边缘 Agent，哪些数据进业务库，哪些进 Redis、采集库或文件存储。
边界清楚了，系统才有机会从一条产线长到一个工厂。
本系列：
暂无评论