4. 渐进迁移 vs 大爆炸迁移
在核心银行系统现代化改造中，迁移策略的选择往往比技术选型更早决定项目成败。所谓大爆炸迁移，是指在一个明确的时间点，将旧核心整体下线，新核心全量接管所有业务；而渐进迁移（Strangler Fig Pattern，绞杀者模式）则是让新旧系统长期并行，按业务域、产品线或客户群逐步把流量与数据从旧系统“绞杀”到新系统，直到旧系统自然萎缩、最终退役。本节围绕两种策略的对比、风险收益、选择依据与混合策略设计展开。
一、核心原理：两种策略的本质差异
大爆炸迁移的本质是一次性切换，它假设新系统在切换前已经过充分验证，切换窗口内完成数据迁移、流量切换和回滚预案。其优势是目标清晰、旧系统可快速退役、团队注意力集中；但风险高度集中，一旦切换失败，影响面覆盖全行所有业务。
渐进迁移的本质是持续替换，它承认“新系统不可能一次做对”，通过路由层（如 API 网关、服务网格或业务路由表）把请求按规则分发到新旧系统。其优势是风险分散、可随时回滚单个业务域、业务连续性有保障；代价是双系统并行带来的数据一致性、运维复杂度和成本上升。
关键判断：大爆炸迁移赌的是“切换前验证充分”，渐进迁移赌的是“切换后可控收敛”。核心银行涉及账户、存款、贷款、支付、总账等强耦合域，绝大多数场景下渐进迁移更稳妥，但并非绝对。
二、方法流程：渐进迁移的典型落地路径
渐进迁移不是“慢慢做”，而是有明确节奏的工程化过程。典型流程如下：
- 业务域切分：按业务能力把核心银行拆成可独立迁移的域，例如客户信息、存款账户、贷款账户、支付结算、总账。
- 路由层建设：在旧核心前部署路由网关，支持按客户号、产品码、机构号等维度分流。
- 数据双写与同步：迁移域内新系统写入后，通过 CDC 或消息队列同步回旧系统，保证未迁移域仍可读取。
- 灰度放量：先内部客户、再小网点、再分行、最后全行，每阶段设定观察指标与回滚阈值。
- 旧系统退役：当某域流量归零且数据不再被依赖时，关闭对应旧模块。
# 路由分流配置示例（按客户号取模灰度）
routes:
- match: "customerId % 100 < 5"
target: "new-core"
- match: "productCode in ['DEP001','LOAN002']"
target: "new-core"
- default:
target: "legacy-core"
三、对比分析与风险收益
下表从多个维度对比两种策略，便于在方案评审时快速对齐认知。
| 维度 | 大爆炸迁移 | 渐进迁移 |
|---|---|---|
| 切换方式 | 单时点全量切换 | 按域/客户/产品逐步切换 |
| 风险分布 | 高度集中，切换窗口风险最大 | 分散到多个小批次，单次影响可控 |
| 回滚能力 | 整体回滚，代价极高 | 单域回滚，分钟级恢复 |
| 双系统成本 | 低，切换后旧系统下线 | 高，并行期需双写、双运维 |
| 数据一致性 | 切换时一次性迁移，逻辑简单 | 需持续同步，一致性设计复杂 |
| 团队要求 | 强切换指挥与演练能力 | 强架构治理与自动化能力 |
| 适用场景 | 系统耦合低、业务可停、监管允许 | 核心强耦合、业务不可停、监管严格 |
常见误区：把渐进迁移做成“永久并行”。若没有明确的域退役计划和收敛指标，双系统成本会持续吞噬收益，最终变成“两个核心都在跑，谁也不敢关”。
四、选择依据与混合策略设计
选择策略时，建议从四个维度评估：业务连续性要求、系统耦合度、监管与合规约束、团队工程能力。若业务不可停、耦合度高、监管严格，优先渐进；若系统边界清晰、可接受短时停业、团队切换经验丰富，可考虑大爆炸。
实践中更常见的是混合策略：整体采用渐进迁移，但对低耦合、独立度高的外围模块（如报表、查询、部分参数管理）采用小范围大爆炸切换，快速见效并积累信心。混合策略的关键是划定“爆炸边界”——只对可独立验证、可快速回滚的模块使用大爆炸，核心账务域仍走渐进。
复盘要点：某银行核心迁移项目初期试图全量大爆炸，演练中发现总账与存款账户强耦合，切换窗口无法覆盖日终批处理，最终改为“存款域渐进 + 报表域大爆炸”的混合方案，切换风险从全行级降到分行级，日终批处理窗口也得到保障。
综上，策略选择没有绝对优劣，只有与业务约束、系统现状和团队能力是否匹配。渐进迁移适合核心银行这类强耦合、不可停、监管严的场景；大爆炸迁移适合边界清晰、可停业验证的模块。混合策略则是在整体渐进框架下，对低风险模块局部使用大爆炸，兼顾速度与安全。真正决定成败的，是是否建立了清晰的域边界、可回滚的路由机制和明确的退役收敛计划。