凌晨三点的软件大道便利店，只有蒸包子的机器在嗡嗡转。
我朋友盯着屏幕上的502报错，脸比手里的菜包还白。
他那套从公司刚成立就写的单体电商系统，在当天的直播大促里，硬生生把主库的CPU干到了98%。
说实话，这场景我见得太多了。很多人一提到架构演进，第一反应就是要上微服务、搞云原生、照着大厂的技术栈抄一遍，仿佛不把系统拆得七零八落，就不配叫技术团队。但那天我帮他排查了半小时问题，最后给出的方案根本没有任何新技术——先把最占资源的商品查询接口从主库里拆出来，前面挂一层Redis缓存，就这么简单。
被吹上天的微服务，真的是救命稻草吗
我见过太多本末倒置的团队。业务还没到百万DAU，就急着把单体拆成二十几个微服务，最后光排查一次跨服务的调用失败，就要翻三四个日志平台，比原来的单体调试还麻烦三倍。更离谱的是有些小团队，总共3个开发，就敢上K8s搞服务网格，最后光运维集群就耗掉一个人的全部精力，业务功能半个月没更新，用户投诉堆了一箩筐。
其实架构演进的本质从来不是追新技术，是给当前的业务痛点找匹配的解法。那天朋友团队最开始的痛点，根本不是系统不够高级，是所有的用户、商品、订单、支付逻辑全塞在一个代码包里，哪怕改个商品详情页的文案，也要全量重新发版，每次发版至少停服20分钟，大促的时候根本连动都不敢动。
就按这个思路改，他们没搞什么复杂的服务注册发现，甚至连RPC都没用到，就用最朴素的HTTP接口互相调用，把商品详情和用户评论两个模块从单体里拆了出来，前面挂了一层CDN加Redis。就这点改动，没花两周时间，没额外买多少服务器，大促的时候80%的流量都走缓存和这两个独立服务，主库的CPU直接降到了30%不到。
你敢信？
很多人觉得架构演进要大动干戈，要写厚厚的技术方案，要拉着整个团队熬几个通宵重构，其实根本不是。
演进的节奏，永远跟着业务的脉搏走
我刚工作那会也犯过傻。天天抱着《微服务设计》的书啃，觉得将来一定要把所有系统都拆得碎碎的才叫厉害，直到第一次帮团队拆了个用户积分的小服务，结果因为机房网络抖动，导致积分接口调用超时，用户兑换不了优惠券，前后赔了几千块的红包，才突然反应过来——所有脱离业务实际的架构升级，本质上都是技术团队的自嗨。
你仔细观察就会发现，那些真正做对了架构演进的团队，从来不会跟着技术热点跑。日活还没到10万的时候，单体足够用，就别瞎拆；团队人数超过10个，不同模块的开发经常因为代码合并吵起来的时候，再考虑拆最耦合的部分；系统每个月要发十几次版本，每次发版都要停服影响用户的时候，再搭CI/CD、搞灰度发布。节奏踩对了，每一步改动都是给业务加分，踩错了，就是给自己加活。
之前接触过一个做本地生鲜的团队，之前跟风上了云原生全家桶，后来发现每个月光云服务的费用就要花十几万，系统稳定性还不如原来的单体。他们咬着牙把K8s集群直接下线，回到最开始的单体+静态资源CDN的模式，把省下来的钱和精力全部放到配送路径优化的功能上，当月的用户留存直接涨了12个点。
架构的价值从来不是用来写在简历上给面试官吹的，是真的能帮业务省成本、提效率的。我见过跑了快10年的单体系统，一年稳定支撑几十亿的交易额，比很多花了几百万搞的花里胡哨的云原生系统靠谱多了。
普通人能落地的演进checklist
经常有人问我，那我到底什么时候该动现有架构？我一般不会直接给方案，先让他们自己捋清楚三个事。
先问自己，现在的系统，是不是已经出现了反复解决不了的痛点？比如每次大促必宕机，每次发版必出bug，团队里的新人三个月都看不懂整个代码库？如果没有，就别瞎动。老系统能跑，就是最大的价值。
再想想，你准备做的改动，是不是用最小的成本就能解决这个痛点？比如原来的问题是商品详情查询占了主库90%的资源，那你先加缓存，再把查询接口拆出去就行，没必要一上来就把整个系统拆成20个微服务。能用一万块钱解决的问题，别花一百万。
最后摸个底，你有没有做好兜底的准备？比如拆服务的时候，有没有留好降级开关，万一新的服务出问题，能不能10秒内切回原来的单体逻辑？没有兜底的改动，全是在给用户埋雷。
昨天那个朋友给我发消息，说他们今年的大促，系统峰值扛了平时的12倍，全程没宕机。他说现在的架构还是当年那个半拆的状态，没有什么高大上的技术栈，但是够用。
你看，架构演进这回事，从来没有什么终极正确答案。
适合当下的，就是最好的。