上周跟老周在南京珠江路吃牛油火锅，毛肚刚烫到七成熟，他把手机往油碟边一放，脸皱得像被花椒麻了——他们公司刚把跑了三年的单体应用拆成微服务，上线第三天，订单服务崩了三次。
冰粉都化了半盒。
当初拍胸脯说的“拆完就爽”，怎么全是坑
老周他们公司是做家居电商的，前两年业务涨得快，从最初的日活几百，冲到了大促时候的百万级流量。之前的单体应用是刚创业时三个人敲出来的，代码堆了近百万行，改个商品详情的文案，都要等运维半夜停服发版。那时候全公司吐槽最多的就是架构——运营要上个活动，光等发版就要等三天，竞品的同款活动都卖爆了，他们家的页面还没上线。
于是去年年底技术部立了个大项目：拆微服务，上K8s，搞统一网关，搭链路追踪平台。当时拍板的技术总监说，等这套架构跑通，以后发版不用停服，扩容按分钟算，大促流量来了也不怕。全公司都觉得这是个能拿年度创新奖的项目。
结果上线就给了所有人一闷棍。
第一次崩是上线第二天，用户付完款跳不到成功页。运维查了俩小时 traces，才发现是支付服务的一个超时参数设成了3秒，刚好赶上数据库慢查询，把整个订单链路堵得死死的。第二次崩是大促预热的时候，网关的限流规则配错了，把正常的用户请求全拦在了外面。最离谱的是第三次，开发改了个用户服务的字段名，忘了同步给订单服务，直接把下单接口搞成了500。
老周说，这三个月团队光是补窟窿，就耗掉了一半的开发精力。本来计划要做的用户积分体系、会员等级功能，全被推后了。之前单体的时候，大家虽然发版麻烦，但出问题了顺着代码查，半小时就能定位；现在倒好，一个请求跨了6个服务，日志散在七八个系统里，查问题的时间比写新功能的时间还多。
架构演进从来不是“换个更牛的系统”
说实话，我见太多团队把架构演进当成技术升级的KPI了。好像不搞点云原生、不拆微服务、不上个大模型，就不好意思说自己是做技术的。
真的。
我之前见过一个做校园二手交易的小团队，一共4个开发，日活刚过五千，就急着把之前的单体应用拆成了八个微服务，还搭了一整套Prometheus监控、ELK日志平台。最后运维的活全压在一个刚毕业的小孩身上，光日常维护这些组件，就要花掉每天一半的时间，根本腾不出手做新功能。最后产品上线半年，没跑过竞品，团队先散了。
其实架构演进的核心从来不是追新技术，而是匹配当下的团队规模、业务增速、故障容忍度。老周他们刚创业的时候，三个人写代码，一天发版八次都没事，那时候单体就是全世界最好的架构——编译快、部署快、出问题了大家凑在一块看半小时代码就能修好。那时候要是有人说要拆微服务，老板能直接把他赶出去：连稳定的用户量都没有，搞那么复杂的东西给谁看？
等业务涨到日活几十万，团队从3个人变成30个人，大家改同一个代码库，每天合并代码都要冲突半小时，大促的时候流量翻10倍，单体应用的数据库连接池直接被打满，这时候才真的到了该动架构的时候。
别上来就all in，先算清楚手里的账
老周他们这次踩的最大的坑，就是一开始太想“一步到位”。觉得既然要拆，就要把所有服务全拆完，把所有最新的技术栈全用上，搭一套完美的、能扛未来十年流量的架构。
结果呢？算完账才发现，光给每个服务加监控、写规范的日志、打通全链路追踪，前后就花了两个多月。之前大家熟悉的单体开发流程全换了，新的微服务治理规则一堆，开发写个接口都要反复对照文档，生怕哪里没配置对，上线就出问题。上次故障损失的十几万销售额，加上这三个月多花的人力成本，算下来比之前单体应用扛不住流量造成的损失还大。
后来他们调整了策略。
不追求全拆完了。先把最容易出问题、流量占比最高的订单、支付两个核心服务拆出来，剩下的用户、商品、内容服务，暂时还是放在原来的单体应用里。等大家把新的运维流程、故障排查方法练熟了，再慢慢拆其他的服务。就这么调整了一个月，发版的效率反而比之前全拆完的时候高了30%，故障的次数也少了一大半。
我特别烦那种一上来就说“单体已经过时了”的人。真的，架构从来没有绝对的好坏。你一个几个人的小团队，日活还没到一万，非要搞一套复杂的微服务架构，最后光维护这些技术组件，就能把你耗得没精力碰业务。等业务真的涨上来了，再慢慢拆也不迟。
别追求一步到位的“完美架构”，小步迭代试错，才是普通人能走的稳路。
火锅吃到最后，老周把最后一块毛肚捞出来，蘸满麻酱，长舒了一口气。他说早知道当初先拆两个服务试试，也不至于现在天天加班补窟窿。
窗外的珠江路车来车往，旁边的小店放着南京话的老歌。其实哪有什么完美的架构啊，不过是你走一步，看一步，算一步手里的成本，别被所谓的“技术先进”冲昏了头而已。