上周在软件大道的咖啡馆跟之前做生鲜配送的老周碰了杯冰美式，他说去年双十一他们系统崩了三次，不是因为带宽不够，是三年前写的单体架构已经撑不住。
那时候团队才3个人。
写个后台接个支付就上线了，谁能想到现在单是早高峰的订单，就比当时全年的量还大。
别拿架构图当甩锅道具
老周说去年最蠢的一次操作，是团队刚招了个做过互联网大厂的架构师，上来就指着他们的单体代码库说“这架构迟早要完，赶紧拆微服务”。
团队当时被说动了，吭哧吭哧花了三个月，把原来的一个应用拆成20多个独立服务，每个服务配独立的数据库，上了注册中心、配置中心、链路追踪。
结果上线第一周就崩了。
跨服务调用的链路超时率直接从0.1%涨到15%，运维的同学每天光排查跨服务的依赖问题就熬到凌晨，有次一个优惠券服务改个配置，连带订单、支付、库存全挂了，整整停了40分钟，赔了商家快两万块。
真的亏。
说实话，太多团队的架构演进从一开始就走歪了。总觉得画在PPT上的架构越复杂，越能体现技术能力，上次去线下技术沙龙，有个团队算上实习生才20个人不到，架构图画了三层网关，两套消息队列，三个缓存集群，问他们为什么这么设计，说对标头部互联网公司的架构标准，我当时差点把手里的冰可乐喷出来。
架构从来不是用来比谁画得更花哨的。你一个做本地水果配送的小团队，非要学人家亿级用户的架构拆法，最后维护成本涨了三倍，业务增长没见快多少，纯粹是自己给自己找罪受。
所有的演进都得踩在业务的节奏点上
老周他们后来彻底换了思路。不再为了拆而拆，先拉着所有人列了个表，数清楚现在每天最痛的点到底是什么：第一是早高峰订单峰值上来的时候，库存模块的查询把数据库打满，连带整个后台都卡；第二是大促的时候营销活动发券，代码改一次就要全量重新发布，发版窗口赶不上活动上线的节奏。
第一步根本不需要拆微服务。先把库存模块的热点查询加本地缓存，把原来的同步发券改成异步走消息队列，就这俩改动，花了开发同学两周的时间，早高峰的数据库CPU直接从95%降到30%，发版时间从原来的2小时缩到20分钟。
当时负责这个事的开发小蔡，之前为了调缓存的过期时间，连续三天在仓库蹲到早上6点，盯着早高峰的订单数据改参数。一开始把缓存过期时间设成10分钟，结果出现了超卖，顾客下单之后库存数不对，退了快三百单，给小蔡郁闷了快一周。后来改成了三级缓存，本地存5秒，分布式缓存存30秒，数据库做最终一致性校验，才把超卖的问题压到万分之一以下。
哪有什么一步到位的完美架构啊。
所有的演进都不是提前画好蓝图照着建，而是每次遇到一个堵点，就花最小的成本把堵点通开，而不是一开始就把所有的墙都拆了重新建。毕竟业务不会等你花半年把完美架构搭好，用户也不会因为你架构设计得好看，就愿意多等两秒加载。
别把架构演进当成技术团队的独角戏
老周说之前踩过最冤的坑，是做架构调整的时候，关起门来改了订单查询接口的字段，根本没拉商家端的同事对接，结果上线之后商家端的APP直接显示不了待配送的订单，一堆商家早上打开APP看不到单，打电话把客服的电话打爆，最后技术团队挨个给商家道歉，折腾了整整一天才把问题解决。
后来他们定了个死规矩，每次架构调整之前，必须拉上所有依赖这个模块的业务方开半小时的对齐会，把可能影响的接口、变更的时间窗口、回滚的预案全摆出来，甚至连运维的同学都要提前一周知道要改什么，留够压测的时间。
真的，太多技术团队觉得架构是自己关起门来就能搞定的事，最后改完一堆业务方的投诉，最后背锅的还是自己，何必呢？
上周跟老周再碰面的时候，他说现在他们的系统既不是纯单体，也不是拆得稀碎的微服务，就是一个带着几个核心独立模块的“胖单体”——核心的交易、支付模块还是放在一起，减少跨服务调用的开销，把库存、营销、商家端这几个变更频繁的模块拆成独立的服务，发版的时候互不影响。团队现在也才20多个人，根本不需要搞那么复杂的东西。
他说现在最烦的就是新来的校招同学，上来就说要把现有架构全部重构，上云原生，上服务网格，每次他都把去年双十一故障的复盘文档甩给对方，说等你能把早高峰的超卖率压到千分之一以下，我们再聊重构的事。