写作与思考。

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

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

用户说页面慢，客服说订单偶尔失败，运营说活动转化掉了。开发打开服务器看 CPU，好像还行；看数据库，好像也没完全打满；翻日志，日志很多，但不知道该搜什么。最后大家只能在群里互相问：刚才谁发版了？哪个…

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

活动系统最怕的，不一定是全站流量都高。更麻烦的是一个商品突然爆了。首页总 QPS 看起来还能接受，但某个商品详情页、某条库存记录、某个活动资格接口被集中访问。平均值很好看，局部资源已经被打穿。热点和…

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

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

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

活动系统最开始只有几万条订单，大家不会认真讨论“数据生命周期”。后台想查就查，运营想导出就导出，日志临时塞数据库也没人觉得有问题。直到半年后，订单表越来越大，报表越来越慢，备份时间越来越长，连一次普…

活动系统运行了几个月后，最先被抱怨的不是下单，而是后台订单列表。运营同学按时间筛选订单，页面从 200ms 变成 3 秒，再后来变成 8 秒。开发第一反应通常是：SQL 慢了，优化一下。但数据库问题…