架构演进踩坑手记

去年双11前一周，我接到杭州一个电商小厂的朋友的电话，声音都在抖——系统压测直接崩了。 他之前总觉得自己家的架构稳得不行，不过是个日活预估10万的小电商，能出啥问题？ 我连夜赶过去看了他们的部署架构，差点没背过气去。

不是加服务器就能解决的事

这团队总共10个人，连专职运维都没有，所有代码全堆在一个Spring Boot单体工程里，前端渲染接口、商品管理、库存扣减、支付回调、定时跑批、积分计算，全揉在同一个代码仓库里。 刚开始日活几百的时候，这套架构确实香——改完代码点一下发布按钮就上线，连个CI/CD流程都不用搞，开发效率高得飞起。去年618第一次做活动，日活冲到2万，当时卡了两次，加了两台应用服务器就扛过去了，团队上下都觉得，这架构能用到天荒地老。 这次双11预估日活10万，压测刚跑到3万，数据库连接池直接爆了。 为啥？ 所有模块全直连同一个主库，连接数上限就那么多，只要跑批的定时任务占了一半连接，剩下的下单链路直接拿不到连接，整个系统卡成PPT。更离谱的是，我翻代码的时候发现，库存扣减的逻辑居然和用户积分计算写在同一个方法里，上次发版的时候有个开发改积分规则，不小心碰坏了支付回调的逻辑，硬生生赔了二十多万的优惠券。

我当时给他们说，别琢磨着再加服务器了，主库就那么大的连接数，加再多应用服务器也是白搭。

拆服务不是拍脑袋切代码

当时有个从大厂跳过来的架构师，一上来就拍桌子说要全量上微服务，拆成20多个独立服务，上K8s，搞Service Mesh，链路追踪全配齐，才叫标准架构。 我差点笑出声。 双11还有一周就到了，你让这帮连Docker都玩不明白的开发，一周之内拆完20个服务？纯纯找死。 我给他们的方案是最小化拆分——先把最容易出问题的下单、库存、支付三个核心链路从单体里剥出来，剩下的用户管理、商品后台、积分系统，全留在原来的单体里，先不动。 拆的时候最头疼的就是分布式事务：总不能用户付了钱，库存扣减失败，就让用户白等吧？当时没敢上Seata这种重型组件，光配置就要折腾好几天，就用了最土的最终一致性方案：下单的时候先在主库写个待确认的订单记录，异步发消息去扣库存，扣成功了就把订单状态改成已支付，扣失败了自动触发退款，整个链路没有强一致性的要求，开发成本低，出问题了也容易排查。 说实话，很多人总觉得架构越新越牛，组件越复杂越显水平。上次我见个团队，业务刚起步，日活还不到1000，就把消息队列、分布式缓存、服务网格全配齐了，最后光维护这些中间件就花了一半的人力，业务反而没精力做。

就这简单的拆分，我们花了整整五天，赶在双11前一天上线了。

演进的节奏比方案重要

双11当天，系统扛住了15万的日活，数据库连接数直接比之前降了60%——因为现在只有三个核心服务直连主库，剩下的非核心模块全连只读从库，主库的压力直接下来了，全程没崩一次。 朋友当时在监控室盯着屏幕，手都在抖，说之前以为要花几十万搞云原生，没想到改几行代码、拆三个服务就搞定了。 后来我给他们定的演进节奏，从来不是一步到位： 双11过了之后，先把商品搜索的功能拆出去，因为搜索的QPS涨得快，而且和核心链路没什么强耦合； 等明年日活冲到50万的时候，再把用户中心拆出去，现在拆了纯纯增加维护成本； 至于积分系统？平时QPS就几十，占数据库的资源还不到10%，等哪天积分商城的流量真的上来了，再拆也不迟。 很多人对架构演进的误解，就是觉得要搞成最先进的样子，要对齐大厂的标准。根本不是。 你现在的架构能扛住接下来半年的业务量，能让开发团队的效率不被架构拖后腿，出了问题能在10分钟内定位修复，就是好架构。 我见过太多团队，业务还没跑通，先把架构搭得比阿里还复杂，最后光维护架构就要耗掉大半精力，业务死得悄无声息。 上周朋友给我发消息，说今年618他们日活冲到了30万，系统全程稳得一批，现在团队才12个人，比之前还裁了两个运维。 他说之前总觉得架构演进是啥遥不可及的技术活，现在才明白，说白了就是跟着业务的步子走，别跑太快把团队拖垮，也别被业务甩在后面追不上。