熬大夜换回来的架构演进

2019年我在南京建邺区那栋写字楼里，守着3台跑了4年的物理机。

崩了。

大促当天下午两点，下单量刚破平时的3倍，整个系统直接卡死。运营在群里@所有人，客服的投诉电话被打爆，我盯着屏幕上满屏的502报错，手都在抖。

单体时代的甜蜜和诅咒

那时候我们的系统是个标准的单体应用，所有代码都塞在一个1.2G的war包里，从用户注册到支付结算，甚至后台的库存管理，全在一个工程里。

好的地方是，一开始开发确实爽，写个新功能直接改代码，本地跑通就能上线，不用搞什么复杂的依赖，也不用跨团队对接。但是业务跑了两年，用户量从几千涨到十几万的时候，问题就来了。

改个优惠券的满减规则，要把整个war包重新打，停服半小时才能上线。每次上线都要挑凌晨两点的时间，同事们带着睡袋在公司待命，就怕上线出问题。有次运营改规则没测试，直接把支付链路搞挂了，赔了快20万的优惠券，那个月全组的绩效都扣了。

那时候我天天盼着什么时候能把系统拆了，再也不要受这种上线的气。

拆服务拆到全员吐槽

2020年年初，领导拍板搞微服务，全组人兴奋了快一周，终于要摆脱单体的束缚了。

谁懂啊，拆完第一个月，接口调用超时的告警从每天5次变成每天50次。

原本一个进程内的方法调用，现在要走三次网络请求，网络抖一下就报错。订单服务、用户服务、库存服务拆得明明白白，结果分布式事务搞不定，经常出现用户付了钱库存没扣，或者库存扣了订单没生成的情况。当时我们总觉得，只要拆成微服务，所有问题都会迎刃而解，现在想想，真的太天真了。

拆完微服务第一次大促，告警短信从晚上8点开始响，我手机都震到自动关机，第二天早上起来，光未读的告警就有300多条。那段时间我每天下班都要去楼下的鸭血粉丝汤店坐半小时，缓一缓。

那时候全组人都在吐槽，好好的单体不用，非要拆成一堆碎服务，问题比之前还多。

演进从来不是赶时髦

后来我们停了手里所有追热点的计划，没去搞什么Service Mesh，也没急着把所有服务搬上云。

最先动手的是商品详情页，直接做了静态化处理，全量扔到CDN节点上，用户刷商品页根本不用碰后端服务，大促的时候这块的流量直接降了70%。

然后是分布式事务的坑，我们没搞什么高大上的分布式事务框架，就用了最朴素的本地消息表，订单服务写完订单，往本地消息表插一条记录，定时任务扫到就发消息给库存服务，失败了就重试，虽然笨，但是稳定。

至于监控，之前我们的告警只有服务器CPU超过80%才发短信，现在每个接口的耗时、错误率，甚至用户端的打开成功率，都有对应的仪表盘，出问题5分钟就能定位到具体服务。

架构演进从来不是先选最先进的技术，而是先解决当下最痛的业务问题。

去年我们做大促，下单量是2019年的20倍，整个系统的可用性稳定在99.95%，团队的运维人数反而比2019年少了2个。

说实话，之前我也觉得搞架构就得追热点，什么火上什么，现在才明白，真不是。

不过话说回来，你要是个10人不到的小团队，做个本地的小工具，非要拆十几个微服务，那纯纯是给自己找罪受。

对吧，架构这东西，从来没有标准答案。那些熬大夜换回来的经验，比任何架构白皮书都管用。