干了 8 年业务系统,最后只剩一句话:能不重写就不重写 8 年时间,做过订单结算、比价、实体匹配、主数据治理 4 个领域。 最近整理过往项目时发现一个规律: 我做过的几次大改造,跨度 5 年, 没有一次是"推倒重来"成功 的——但全部"逐步替换"成功了 。 不是我胆小。是真的踩过坑。 最近带 mentee 时这个判断反复被问,所以想完整写一次。 1. 老订单系统从 .NET 迁到 Java 跨 2 年。 方式不是停掉老的、上线新的——是同时跑,新订单走新系统、老 订单仍走老系统,通过比对工具持续校验差异。 切流粒度很细。从 0.1% 灰度开始, 最小灰度颗粒到具体业务 ID 维度 ,最终切完用了 14 个月。 期间老系统改了 3 次,新系统改了 7 次, 两边互相对照修了 11 个"看起来对但不对"的 bug ——这种 bug 单独跑任何一边 都看不出来。 2. 比价系统的 Redis 重构 跨 1 年。 原系统有个增量更新机制,因为时间窗口判断 bug 导致比价数据 偶尔晚更新 30 秒,凌晨流量小时不易发现。 我没有重写整个 Redi...