架构设计 · 系统改造 · 业务里的 AI 智能体

二十多个服务仓、三个团队一起写：约定做成骨架，不靠评审兜底

当时新系统真正难的不是选哪个注册中心，是几十个人同时往里写——三个月后同一件事会有五种写法，而写在文档上的约定活不过第三个月。

怎么拆服务按两问切层：要不要独立看几个域要用、进哪一层看有没有业务规则——六个平台服务不带一条规则，财务这种整仓都是规则的留在业务域；每个仓固定六层、新服务从骨架复制；降级统一返回一个能被判出来的失败；全局事务只钉在开单、结算这类跨服务写入口；网关路由放进配置中心，接一个新服务不占发版窗口。

20+

服务仓

3

个团队

80

人协作

六周、484 次提交：只借鉴功能，客户那边一个字都不用改

当时一套跑了几年的系统还在赚钱，但业务规则已经和最初那批人的写法长在一起了。整体替换的风险和双轨维护的成本，同时摆在一张桌子上。

怎么拆功能照做、代码全重写：平台层沉进一个约 26 万行、带 3438 个测试方法与覆盖率门禁的底座，业务侧只写业务；对外的 URL、字段名、错误码原样保留，前端和第三方系统零改动；端点数 178 对 178、契约模块零越界引用，每一阶段都留一个能核对的量。

484

次提交

27

个模块

178

端点对齐

「能不能改」要能在白板上被证明

当时方案写得再细也没用。多数改造项目的死因是立项时没验三件事：流量能不能切过去、怎么证明改前改后行为一样、数据改歪了能不能退回来。

怎么拆把这三件事写成开工的前置条件，而不是登记成一条风险：流量能切、改前改后能比对上、数据能退。再配两份盘点——系统里到底有什么、哪些约定没人写在文档上。这三条过不了，「今年先不改」就是个正当结论。

改之前，先让它自己交代行为

当时没有测试、没有文档的系统里，最贵的不是写新代码，是「不知道它现在到底在做什么」。

怎么拆先让老系统把自己的行为录下来再动手改：录哪些输入、结果记到哪一层、写接口跑一遍会不会污染线上数据。比对出差异时每一条都要归到原因，不许写「先不管」。

代码能退回去，写歪的数据退不回去

当时改造里唯一真正不可逆的部分是数据，而它常被排在最后草草处理。

怎么拆四步逐步走：新旧字段同时留着、两边同时写、逐条对账、最后切读。每一步都写清会在哪儿出事——双写挂在哪一层，决定了两边不一致时听谁的；线上还在往里写的时候，「对上了」得有一个能核对的定义；从某一步起，退回去就要丢数据。

放量放的是这次最多赔多少，不是进度

当时放量被当成进度展示时，它真正的作用就丢了：把一个大失败换成若干个小失败。

怎么拆一次放给谁、放多少，按「哪块坏了最疼」来排，不是从 1% 加到 100% 了事；每个开关都要有主人、有到期那天；回滚要当场答出三件事——多久退完、退回去丢不丢数据、谁有权按那颗按钮；演练换一个没写过这套代码的人来执行。

工期估得准不准要能核对，什么时候停手要在开工前写下

当时改造估时的真正问题不是偏大或偏小，是口径不可核对：按模块估的工期，没有任何东西能校准它。

怎么拆一个批次一个批次地算四笔钱：摸清现状、动手改造、新旧两套同时跑的这段日子、老代码什么时候允许真删——最容易漏的是最后一笔。立项那天就把停手的条件写下来，别等烧了半年再坐到会议室里谈。

上线那天，「完成」这个词最容易被用坏

当时上线不等于改造完成，而验收口径含糊的项目会在半年后为同一批问题返工。

怎么拆验收时一次回答五个问题，每个都要拿得出能核对的东西：改前改后行为一样吗、数据对得上吗、有没有变慢、运维接得住吗、换一个没参与过的工程师还能改吗。再加一条常被整段跳过的判据——老代码什么时候才允许真删。