1. 课程导入

核心银行系统是银行所有存、贷、汇、账户、计息、清算与总账能力的“心脏”。它往往运行了十年以上，承载着数百万乃至上亿账户，任何一次停机、错账或数据不一致都可能直接演变为监管事件与声誉风险。因此，核心银行迁移从来不是一次简单的技术升级，而是一场在“飞行中更换发动机”的系统工程。本课程聚焦一种被反复验证的渐进式路径——Strangler（绞杀者）模式，帮助你在不中断业务的前提下，把旧核心的能力一块块“绞杀”并迁移到新平台。

一、核心银行迁移的真实挑战

要理解Strangler模式的价值，先要看清传统“大爆炸式”迁移为何频频受挫。核心银行迁移的难点并非单点技术，而是多重约束叠加：

• 业务连续性不可妥协：7×24小时对外服务，日终批处理、计息、对账窗口极短，无法接受长时间停机切换。
• 数据强一致与账务准确：账户余额、积数、利息、总账必须分毫不差，迁移过程中新旧系统并存极易产生“双写不一致”。
• 耦合深、边界模糊：旧核心常把产品、利率、费用、账务、接口逻辑糅合在存储过程与单体代码中，缺少清晰的服务边界。
• 监管与审计要求：每一笔资金变动都要可追溯、可解释，迁移方案必须通过监管评审与内部审计。
• 组织与技能断层：熟悉旧核心的专家逐渐退休，新团队对历史逻辑理解不足，知识传承风险高。

这些挑战决定了：一次性重写并整体切换的“大爆炸”方案，风险与成本都极高。我们需要一种能够分而治之、可回退、可验证的迁移策略。

二、Strangler模式的核心原理

Strangler模式得名于“绞杀榕”：新系统像藤蔓一样围绕旧系统生长，逐步接管其功能，最终旧系统被完全替代或仅保留少量遗留能力。其核心思想是在旧系统前方建立一层路由/门面（Facade），按业务能力把流量逐步从旧核心切到新核心，而不是一次性替换。

在核心银行场景中，Strangler的落地通常包含三个关键机制：

1. 能力切片：把旧核心拆成可独立迁移的能力单元，如客户信息查询、账户余额查询、交易明细、转账、计息、总账过账等。
2. 路由与双跑：通过API网关或服务路由层，将指定流量导向新核心；对关键交易采用“双写+比对”或“影子流量”验证一致性。
3. 绞杀与退役：当新核心能力稳定、数据一致、监管验收通过后，逐步关闭旧核心对应模块，最终完成退役。

下面的SVG展示了Strangler模式在核心银行迁移中的整体结构：旧核心仍在运行，新核心按能力逐步接管，路由层负责流量分配与灰度控制。

三、方法流程：从评估到绞杀的六步法

Strangler迁移不是“边做边看”，而需要一套可复用的方法流程。结合核心银行特点，我们将其归纳为六步：

步骤	关键动作	核心产出	风险控制点
1. 能力盘点	梳理旧核心功能清单、调用关系、数据表与批处理依赖	能力地图、迁移优先级矩阵	避免遗漏隐性依赖
2. 边界划分	按业务能力定义新核心服务边界与接口契约	服务清单、API契约、数据模型	边界过粗或过细都会增加成本
3. 路由建设	部署网关/门面，支持按客户、产品、交易类型灰度	路由规则、开关配置、监控看板	路由层自身高可用
4. 双跑验证	新旧并行处理，比对结果，影子流量验证	一致性报告、差异清单	差异必须归零或可解释
5. 灰度切换	按比例、按客群、按交易类型逐步切流	切换记录、回滚预案	设置熔断与快速回退
6. 绞杀退役	关闭旧模块，清理数据与接口，完成验收	退役报告、监管验收材料	保留只读归档与审计追溯

在技术实现上，路由层通常通过配置驱动。例如，一个简化的灰度路由配置可能如下：

route:
  - capability: account.query
    target: new-core
    percentage: 20
    match:
      customerSegment: "retail"
  - capability: transfer.create
    target: legacy-core
    percentage: 100
    match:
      channel: "mobile"
  - capability: interest.calculate
    target: shadow
    compareWith: legacy-core
    logDiff: true

这段配置表达了：账户查询对零售客户放量20%到新核心；转账仍全部走旧核心；计息采用影子模式双跑并记录差异。通过调整percentage与target，即可实现渐进迁移。

四、案例场景：某银行账户查询能力迁移

某全国性银行在迁移“账户余额与明细查询”能力时，采用了典型的Strangler路径。该能力读多写少、对账务一致性要求相对可控，适合作为首批迁移对象。

• 第1周：在网关配置路由，将1%的内部测试流量切到新核心，验证接口连通性与数据格式。
• 第2-3周：开启影子流量，新旧核心同时处理查询请求，逐笔比对余额、可用余额、冻结金额等字段，差异率从0.3%降至0。
• 第4周：按客户号尾号灰度，先切10%，再切50%，最后全量。期间监控响应时间、错误率与数据库负载。
• 第5周：旧核心查询模块转为只读备份，保留30天后正式退役。

五、常见误区与复盘要点

在实际项目中，团队常因急于求成而陷入以下误区：

1. 把Strangler当成“简单加一层网关”：路由只是表象，真正的难点在于能力边界划分与数据一致性治理。
2. 忽视批处理与日终依赖：核心银行大量逻辑在夜间批处理中，若只迁移联机交易，日终仍会回写旧核心，导致数据分裂。
3. 双跑差异长期不归零：差异若被“暂时忽略”，会在切换后集中爆发，必须建立差异归零机制。
4. 缺少回滚演练：灰度切换前必须验证回滚路径，确保开关一拨即可恢复旧核心。
5. 组织协同不足：迁移涉及业务、开发、测试、运维、合规多方，需要建立统一的迁移指挥机制。

六、课程学习目标与整体框架

通过本课程，你将系统掌握核心银行Strangler渐进迁移的完整方法论与实战技能。具体学习目标包括：

• 理解核心银行迁移的约束条件与Strangler模式的适用边界；
• 掌握能力盘点、边界划分、路由建设、双跑验证、灰度切换与绞杀退役的六步法；
• 能够设计路由灰度策略、双写比对方案与回滚预案；
• 识别迁移过程中的数据一致性、批处理依赖与监管合规风险；
• 通过案例演练，形成可落地的迁移计划与验收标准。

课程整体框架围绕“认知—方法—实战—复盘”展开：前段建立迁移认知与Strangler原理；中段深入能力切片、路由网关、双跑比对、数据迁移与批处理改造；后段通过综合案例完成从评估到退役的全流程演练，并总结常见故障与治理经验。每一章都配有可操作的工具、配置示例与检查清单，帮助你把方法带回真实项目。

现在，你已经对核心银行迁移的挑战、Strangler模式的价值以及本课程的整体脉络有了清晰认识。接下来，我们将从迁移评估与能力盘点开始，一步步拆解这场“飞行中更换发动机”的工程实践。