架构演进从来不是凭空设计的

上周六在雨花客厅负一楼的咖啡馆碰着老周，他穿的藏青T恤上还沾着半圈咖啡印，手里攥着半杯冰美式，刚从公司逃出来躲清净。

说上周三他们团队刚把跑了三年的老单体拆了个口子，上线当天半夜告警直接炸穿了监控面板，支付回调链路丢了三笔订单的通知，三个人对着日志熬到四点，天快亮的时候才在会议室的沙发上眯了半小时。

最先垮的从来不是代码本身

最早他们做这个电商系统的时候，整个团队就三个人，两个后端一个前端。

那时候哪有什么架构概念。

Spring Boot打个war包扔到Tomcat里，数据库就是单库单表，订单、商品、用户、库存所有数据全堆在一个实例里，连个从库都没配。

爽。真的爽。

改完代码点一下发布按钮，两分钟就能全量上线，出了问题直接在数据库里改两笔数据，十分钟就能把用户的问题解决完。那时候谁要是上来就扯什么微服务拆分，团队估计得把他从会议室轰出去——三个人拆七八个服务？谁24小时盯着告警啊？

直到2021年618大促，日常访问量直接冲到平时的8倍，商品详情页的查询响应从200ms跳到2s，订单接口的线程池直接打满，数据库连接数爬满了整个监控面板，之前靠加应用服务器硬扛的路子，彻底走不通了。

说实话，那时候团队招了个从大厂过来的架构师，上来就甩了一套十二服务的拆分方案，订单拆成创建、支付、履约、售后四个独立模块，库存、商品、用户全部分库分表，连优惠券都要拆成两个服务。拉着团队干了三周，上线当天直接踩了大坑——之前单体里的所有调用都是本地方法，没有网络开销，拆成跨服务HTTP调用之后，超时时间只设了1秒，碰到机房网络抖动直接丢请求，那天半夜三点整个会议室闷得像蒸笼，咖啡喝到嘴里都是发涩的苦味，没人敢提回去睡觉。

拆的时候别想着一步到位

后来那个大厂来的架构师没撑过两个月就走了，剩下的几个人蹲在会议室重新捋方案，没人再提全量拆分的事儿。

先把最拖性能的商品详情查询，从主库的大表里拎出来放到Redis缓存里，热点数据直接提前预热到本地缓存，光这一步就把详情页的响应压回了200ms以内。然后把最容易出资金问题的支付回调链路，从原来的单体里单独拆出来，只做三件事：接收支付渠道的回调请求、更新订单的支付状态、发个消息给库存服务扣减对应商品的库存。

架构演进的核心从来不是追新，而是先解决当下最疼的那一个问题。

拆的过程里没人急着上那些花里胡哨的组件。注册中心就用最朴素的Nacos，没搞复杂的权限管控，反正团队就那么几个人，谁有权限改配置一眼就看得过来。链路追踪最开始连Jaeger都没装，就是在每个接口的日志里打个traceId，出了问题用grep搜就行。每次只拆一个模块，拆完之后观察两周，没有连续的告警了，再动下一个模块。

对吧，哪有什么一步到位的完美架构。所有现在看起来规整的服务边界，都是之前踩了无数次跨服务调用的坑，才慢慢磨出来的。最开始他们拆库存服务的时候，还因为消息重复投递扣错了库存，给用户发了两次退款，后来才慢慢加上了消息的幂等校验，把重试的逻辑补全。

别把架构演进搞成团队的自我感动

我见过太多团队，一提到架构演进，就觉得要把所有旧代码全推翻，要上最火的技术栈——云原生、Serverless、大模型嵌到业务流里，什么火就上什么。结果折腾了三个月，业务的迭代速度反而慢了一半，之前一周能上线三个需求，现在两周才能上一个，光跨团队对齐接口规范就耗掉了一半的开发时间。

真的没必要。

之前在软件谷碰到个做企业SaaS的团队，去年跟风拆了18个微服务，结果每次改一个用户登录的小功能，要动三个服务的代码，还要协调三个团队的排期，最后产品经理都忍不住吐槽，说之前单体的时候，改个登录按钮的颜色十分钟搞定，现在要走两周的审批流程。

很多人总觉得架构越复杂越能体现技术能力，实际上真正好用的架构，是让团队里的每个人写代码的时候，不用想太多额外的约束，改完代码能快速上线，出了问题能十分钟定位到根因，不用为了所谓的架构先进性，给日常开发加一堆没必要的负担。

老周他们现在的系统规模，比最早的单体大了三倍，但是算下来也就5个独立服务，每个服务的代码量控制在十万行以内，团队里的每个人都能说清楚每个服务的核心逻辑。上次聊到现在的618大促，他说系统的响应还是稳定在200ms以内，半夜的告警次数比当年跑单体的时候还少。

那天在咖啡馆聊到最后，他手机弹了个消息提醒，撇了一眼，是缓存命中率掉了2个百分点，他笑着按灭屏幕说，没事，小问题，等下回去调下缓存过期时间就行。风从落地窗吹进来，带着外面梧桐树的味道，突然觉得，哪有什么高大上的架构演进，不就是一群人在业务往前跑的路上，遇到一个坑填一个坑，慢慢把系统磨到能跟上自己的脚步而已。