4、迁移策略制定：Strangler Fig模式、双跑策略、全量+增量迁移方案设计
迁移策略这东西，说白了就是「怎么把大象塞进冰箱」——而且冰箱还不能停机。我见过太多团队一上来就搞「大爆炸」式迁移，结果业务停了三天，老板差点把数据团队给拆了。
所以这一章，咱们聊聊三种靠谱的迁移模式。我个人习惯把它们叫做「切香肠」、「走钢丝」和「搭积木」。别笑，这三个词背后是实打实的工程经验。
4.1 Strangler Fig模式：让老系统慢慢「窒息」
这个名字听着有点吓人，其实很形象。热带雨林里有一种榕树，种子落在宿主树上，慢慢生长，最终把宿主完全包裹、取代。迁移老系统也是一样——你不需要一刀砍掉它，而是让新系统一点点「长」出来。
核心思想：逐步用新组件替换老组件，直到老系统无组件可替，自然退役。
我在一个金融客户那里用过这个模式。他们的核心交易系统跑了十几年，没人敢动。我们怎么做？先挑一个最边缘的报表模块下手，新系统接过来，老系统那边直接路由切掉。用户根本没感觉。三个月后，整个交易引擎都换完了。
具体步骤其实不复杂：
- 识别边界——把老系统拆成功能模块，找到可以独立替换的「小单元」
- 架设路由层——在入口处加一个流量分发器，决定哪些请求走新系统
- 逐个替换——每次替换一个模块，验证通过后再切下一个
- 清理老系统——所有模块替换完成后，关停老系统
我的经验：路由层是关键。我曾经见过一个团队，路由层写得不够灵活，结果切到一半发现新系统有bug，想回退都回不去。所以路由层一定要支持「按用户、按地域、按时间」的灰度切流，而且必须能一键回滚。
这个模式最适合什么场景？嗯，老系统还在跑，业务不能停，而且你有足够的时间窗口。说白了，就是「慢工出细活」。
4.2 双跑策略：新旧并行，数据对账
双跑，也叫「并行运行」。新老系统同时跑同样的业务，数据两边都写，然后拿新系统的结果去和老系统对账。对上了，说明新系统没问题；对不上，赶紧查原因。
你想想看，这其实是最稳妥的方式。我参与过一个湖仓迁移项目，数据量大概200TB，业务方要求零数据丢失。我们当时就用了双跑策略，跑了整整两周，每天对账一次。前三天对出来一堆差异，全是老系统里隐藏的bug——新系统反而更准。
双跑的核心设计要点：
- 数据双写——业务数据同时写入老系统和目标系统
- 对账机制——按天/按小时比对两边的数据一致性
- 异常处理——对账不一致时，自动告警并记录差异明细
- 切换条件——连续N天对账通过率100%，才能切流
| 对比维度 | Strangler Fig | 双跑策略 |
|---|---|---|
| 切换粒度 | 按功能模块 | 按数据范围 |
| 回滚成本 | 低（路由层切回即可） | 中（需停止双写） |
| 对账要求 | 低（功能验证为主） | 高（必须逐条对账） |
| 适用场景 | 应用层迁移 | 数据层迁移 |
注意：双跑不是无限期跑下去的。我见过一个项目，双跑跑了半年，团队都疲了，对账脚本也没人维护。最后切换时发现新系统已经落后了三个版本。双跑一定要设定明确的「终止条件」——比如连续7天对账通过率100%，就强制切换。
4.3 全量+增量迁移：大数据量的标准打法
这个模式，说白了就是「先搬历史数据，再追实时增量」。数据量大的时候，你不可能让业务停下来等你慢慢搬。所以全量+增量就成了湖仓迁移的标配。
我记得有一次，一个电商客户要做湖仓迁移，数据量500TB，业务要求停机窗口不超过4小时。怎么办？我们用了全量+增量方案：
- 全量迁移——先把历史数据批量拷贝到目标系统，这个过程可以跑几天甚至几周
- 增量捕获——在全量迁移期间，老系统的增量数据通过CDC（Change Data Capture）实时同步到目标系统
- 数据校验——全量迁移完成后，对全量+增量数据进行一致性校验
- 业务切换——校验通过后，在停机窗口内完成最终切换
关键点：全量迁移和增量捕获必须「无缝衔接」。如果全量搬完，增量数据没追上，中间就会产生数据空洞。我习惯的做法是：全量迁移开始时，先记录一个「快照时间戳」，增量捕获从这个时间戳开始追。全量搬完后，增量数据已经追到了快照时间戳之后，两边自然对齐。
这里有一个常见的坑——增量数据的「乱序」问题。CDC捕获的数据，到达目标系统时可能不是严格按时间顺序的。尤其是跨分区的数据，晚提交的事务可能先到。所以目标系统必须支持「幂等写入」和「去重机制」。
我曾经在一个项目中，因为没处理好乱序问题，导致目标系统的汇总数据比老系统多了0.3%。排查了整整两天，才发现是CDC的Kafka分区策略导致的。从那以后，我要求所有增量同步方案都必须包含「去重逻辑」和「时序校验」。
4.4 三种策略如何选？
说实话，没有银弹。我一般会问自己三个问题：
- 业务能停多久？——能停超过4小时，全量+增量就够了；不能停，考虑双跑或Strangler Fig
- 老系统还能改吗？——能改，Strangler Fig最优雅；不能改，双跑更安全
- 团队有多少时间？——时间充裕，Strangler Fig慢慢切；时间紧，全量+增量一步到位
下面这张图，是我自己画的一个决策流程，帮你快速定位该用哪种策略：
4.5 混合策略：实战中的常态
说实话，纯用一种策略的项目我见得不多。大多数情况下，都是混合着来。比如：
- 先用全量+增量把历史数据搬过去
- 然后对核心业务模块启用双跑，跑一周对账
- 边缘模块直接用Strangler Fig切过去
我参与过的一个零售湖仓项目就是这么干的。历史数据500TB，全量搬了3天，增量同步跑了2天。然后核心的订单表双跑对账了5天，发现3个数据不一致的问题。边缘的报表模块直接Strangler Fig切，一周切完。整个迁移历时三周，业务零停机。
我的建议：不要追求「纯正」的策略。策略是工具，不是信仰。哪个好用就用哪个，能混着用就混着用。关键是——每个策略都要有明确的「退出条件」和「回滚方案」。
嗯，这一章的内容差不多就这些。三种策略，各有各的脾气。Strangler Fig适合应用层，双跑适合数据层，全量+增量适合大数据量。但真正的高手，是能把它们组合起来用的。