8 年时间,做过订单结算、比价、实体匹配、主数据治理 4 个领域。
最近整理过往项目时发现一个规律:
我做过的几次大改造,跨度 5 年,没有一次是"推倒重来"成功 的——但全部"逐步替换"成功了。
不是我胆小。是真的踩过坑。 最近带 mentee 时这个判断反复被问,所以想完整写一次。
跨 2 年。 方式不是停掉老的、上线新的——是同时跑,新订单走新系统、老 订单仍走老系统,通过比对工具持续校验差异。
切流粒度很细。从 0.1% 灰度开始,最小灰度颗粒到具体业务 ID 维度,最终切完用了 14 个月。
期间老系统改了 3 次,新系统改了 7 次,两边互相对照修了 11 个"看起来对但不对"的 bug——这种 bug 单独跑任何一边 都看不出来。
跨 1 年。 原系统有个增量更新机制,因为时间窗口判断 bug 导致比价数据 偶尔晚更新 30 秒,凌晨流量小时不易发现。
我没有重写整个 Redis 层。只重写了"时间窗口判断"这一段 ——把它从老系统拆出来,做成独立模块,通过开关控制走新逻辑还 是旧逻辑。
灰度过程是常规节奏:1% → 10% → 30% → 50% → 100%, 每阶段保持 2-4 周观察。
总改动:老系统代码改了不到 200 行。新模块约 1500 行。 但是这 200 行让"凌晨偶发数据延迟"这个 5 年没解决的问题彻 底消失。
跨 1.5 年。 原系统是单体,匹配规则散落在 4 个 service 里互相调用。
我没急着拆。先把 4 个 service 之间的调用关系画成图 (drawio,约 60 个节点)——然后把每个调用边一条一条剪 掉,改成事件驱动。
不是一次性切——是一次切一条。每剪一条边,跑 1 周回归,确认 指标无变化,再剪下一条。
剪了 23 条边用了 11 个月。期间老的同步调用代码一直没 删——新事件链路稳定 3 个月后才彻底清理。
跨 1 年。 4 个团队的主数据库要合并成一个。常规做法是搞个"统一数据中 心",大家停 2 周迁移过去。
我们的做法:老系统全部保留,只在中间加一层"主数据视图层"。 A 团队看视图 V1,B 团队看视图 V2,但底层数据已经合并。 6 个月后,老库一个一个下线——因为没人在用了。
不是"先想好架构再切一刀"。 是"先切一刀,看能不能切得动,切不动退回去"。
具体动作就 4 条:
我也踩过一次。
某个项目我用同样套路想做"渐进迁移"。结果发现:
最后我们停了渐进迁移,直接停 2 周做切换——结果反而很顺利。
事后总结:当业务还在快速变化时,渐进迁移会拉长事故面。 渐进式只适合"业务相对稳定、需要保留长期可对照"的场景。
带 mentee 时最常说的一句话是: "先不要想架构图。先想第一刀切在哪、切错了怎么退回去。"
很多技术决策不是"什么是对的",是"什么是可逆的"。 可逆的方案,允许你在错的时候不死;不可逆的方案,要求你一开始 就对——但谁能保证一开始就对呢?
(以上 4 个项目都做了脱敏处理。 如果你做过类似改造, 欢迎评论区聊聊你踩过的坑—— 我特别想知道你们行业里"渐进式不适用"的具体场景是什么。)
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.