标签：架构设计

用 .NET 做 MES，我觉得是很自然的。ASP.NET Core 做业务 API，Worker Service 做后台消费，SignalR 做看板推送，Redis 存实时状态，RabbitMQ …

车间网络断了十分钟，产线不会停下来等 MES 恢复。锁螺丝机还在跑，扫码枪还在扫，测试机还在出结果。等网络恢复，如果系统只留下一句“连接失败”，这十分钟的生产过程就像从系统里消失了一样。所以 MES…

有一次看产线看板，班长指着屏幕说：这台锁螺丝机明明在跑，为什么 MES 显示停机？软件侧先查日志。接口正常，消息队列没有积压，实时处理服务也没报错。电气侧看 PLC。设备运行点位在跳，自动模式点位也…

如果让我解释 MES 总体架构，我不会先画七八个方框。我会先拿一张纸，跟着一条产线从开工走到收线。比如一条散热器装配测试线。早上 8 点，班长领到工单，切换产品型号。操作员扫码上料，锁螺丝机开始跑，…

我以前也觉得，做 MES 架构，第一步应该先画一张完整的大图。设备层、采集层、消息层、业务层、数据层、看板层，再把 ERP、WMS、PLM、QMS 接在旁边。图画出来以后，看起来很稳，很像一个系统该…

回头看这个活动商品与订单系统，它并不是一开始就需要复杂架构。最早只有商品页、下单接口和一张订单表。后来商品详情访问量上来了，于是加缓存；订单表变大了，于是优化索引、冷热分离；活动峰值来了，于是引入 …

有一次团队以为自己有备份，直到真的需要恢复。备份文件确实存在，但恢复脚本很久没跑过；恢复出来的数据还要校验；应用连接怎么切，缓存怎么处理，消息积压怎么补，都没有完整演练。那一刻才会明白：高可用不是文…

活动高峰时，库存服务先慢了。订单服务调用库存服务，原本 100ms 返回，现在变成 2 秒。订单服务等不住，开始超时；客户端看到失败，又发起重试；订单服务自己也配置了重试；库存服务本来已经吃紧，又被…

系统没拆开之前，下单这件事很简单。一个数据库事务里，创建订单、扣库存、核销优惠券。提交成功就是成功，回滚失败就是失败，边界很清楚。后来系统拆开了。订单是订单服务，库存是库存服务，优惠券是营销服务，支…

活动开始后，下单接口最先扛不住。用户点击下单，接口里要校验活动、检查库存、创建订单、扣优惠券、发通知、更新报表。平时这条链路没问题，活动流量一上来，接口开始超时。这时候很多人会说：加 MQ。这个判断…