干了 8 年业务系统,最后只剩一句话:能不重写就不重写

8 年时间,做过订单结算、比价、实体匹配、主数据治理 4 个领域。

最近整理过往项目时发现一个规律:

我做过的几次大改造,跨度 5 年,没有一次是"推倒重来"成功 的——但全部"逐步替换"成功了。

不是我胆小。是真的踩过坑。 最近带 mentee 时这个判断反复被问,所以想完整写一次。

1. 老订单系统从 .NET 迁到 Java

跨 2 年。 方式不是停掉老的、上线新的——是同时跑,新订单走新系统、老 订单仍走老系统,通过比对工具持续校验差异。

切流粒度很细。从 0.1% 灰度开始,最小灰度颗粒到具体业务 ID 维度,最终切完用了 14 个月。

期间老系统改了 3 次,新系统改了 7 次,两边互相对照修了 11 个"看起来对但不对"的 bug——这种 bug 单独跑任何一边 都看不出来。

2. 比价系统的 Redis 重构

跨 1 年。 原系统有个增量更新机制,因为时间窗口判断 bug 导致比价数据 偶尔晚更新 30 秒,凌晨流量小时不易发现。

我没有重写整个 Redis 层。只重写了"时间窗口判断"这一段 ——把它从老系统拆出来,做成独立模块,通过开关控制走新逻辑还 是旧逻辑。

灰度过程是常规节奏:1% → 10% → 30% → 50% → 100%, 每阶段保持 2-4 周观察。

总改动:老系统代码改了不到 200 行。新模块约 1500 行。 但是这 200 行让"凌晨偶发数据延迟"这个 5 年没解决的问题彻 底消失。

3. 实体匹配的 SOA 改造

跨 1.5 年。 原系统是单体,匹配规则散落在 4 个 service 里互相调用。

我没急着拆。先把 4 个 service 之间的调用关系画成图 (drawio,约 60 个节点)——然后把每个调用边一条一条剪 掉,改成事件驱动。

不是一次性切——是一次切一条。每剪一条边,跑 1 周回归,确认 指标无变化,再剪下一条。

剪了 23 条边用了 11 个月。期间老的同步调用代码一直没 删——新事件链路稳定 3 个月后才彻底清理。

4. 主数据治理整合

跨 1 年。 4 个团队的主数据库要合并成一个。常规做法是搞个"统一数据中 心",大家停 2 周迁移过去。

我们的做法:老系统全部保留,只在中间加一层"主数据视图层"。 A 团队看视图 V1,B 团队看视图 V2,但底层数据已经合并。 6 个月后,老库一个一个下线——因为没人在用了。

这 4 件事的共同模式

不是"先想好架构再切一刀"。 是"先切一刀,看能不能切得动,切不动退回去"。

具体动作就 4 条:

1. 把要改的东西从大块切成小块——小到一周能做完
2. 新老并存——不是切完老的再上新的,是两边一起跑
3. 比对工具先做——不能比对的改动等于不存在
4. 回滚开关比上线更优先

什么时候不该用这套?

我也踩过一次。

某个项目我用同样套路想做"渐进迁移"。结果发现:

• 新需求每周改一次,老系统跟新系统都得跟着改
• 改一处,要在 2 个系统都改,工作量翻倍
• 6 个月后老系统不仅没"自然死掉",反而变得更复杂

最后我们停了渐进迁移,直接停 2 周做切换——结果反而很顺利。

事后总结:当业务还在快速变化时,渐进迁移会拉长事故面。 渐进式只适合"业务相对稳定、需要保留长期可对照"的场景。

写在最后

带 mentee 时最常说的一句话是: "先不要想架构图。先想第一刀切在哪、切错了怎么退回去。"

很多技术决策不是"什么是对的",是"什么是可逆的"。 可逆的方案,允许你在错的时候不死;不可逆的方案,要求你一开始 就对——但谁能保证一开始就对呢?

(以上 4 个项目都做了脱敏处理。 如果你做过类似改造, 欢迎评论区聊聊你踩过的坑—— 我特别想知道你们行业里"渐进式不适用"的具体场景是什么。)