3. Strangler模式精讲

在核心银行系统这类“高耦合、长生命周期、强一致性”的遗留系统中，迁移往往不是一次性替换，而是长期共存、逐步替换。Strangler模式正是为这种渐进式演进提供方法论的模式。本节从起源、核心思想、与“绞杀者模式”的辨析、适用与不适用场景四个维度展开，帮助你在核心银行迁移中做出正确判断。

一、模式起源：从“绞杀榕”到软件演进

Strangler模式最早由Martin Fowler在2004年前后提出，灵感来自热带雨林中的绞杀榕（Strangler Fig）。绞杀榕的种子落在宿主树的枝干上，气根向下生长、逐渐包裹宿主，最终宿主树被替代，而绞杀榕独立成树。软件领域的类比是：新系统围绕遗留系统生长，逐步接管其功能，最终遗留系统被“绞杀”并安全下线。

在核心银行场景中，这一隐喻非常贴切：核心系统像一棵老树，根系深、牵涉广，不能直接砍掉；新能力以“外围包裹”的方式生长，先接管低风险、低耦合的功能，再逐步向账务、计息、总账等核心区域推进。

二、核心思想：以边界为支点，逐步转移职责

Strangler模式的核心可以概括为三点：边界识别、流量路由、职责转移。首先识别遗留系统中可被独立替换的功能边界；其次在边界上建立路由层（如API网关、服务代理、消息路由）；最后通过路由规则将请求逐步导向新实现，直到遗留实现不再被调用。

在核心银行中，边界通常不是“模块”，而是“业务能力”。例如：客户信息查询、账户余额查询、交易流水查询、限额校验、利息计算、手续费计算、对账文件生成等。每个能力都可以作为独立的绞杀单元。

上图展示了核心银行中典型的Strangler结构：路由层位于调用方与实现方之间，左侧遗留系统与右侧新能力并存，路由规则决定请求流向。迁移顺序遵循“查询类→计算类→账务类→总账类”的风险递增原则。

三、与“绞杀者模式”的区别：同一隐喻，不同侧重

中文语境中常出现“Strangler模式”与“绞杀者模式”混用的情况。严格来说，二者指向同一思想，但侧重点不同：Strangler模式强调“渐进替换”的工程方法，关注路由、适配、灰度、回退；绞杀者模式更强调“最终替代”的战略意图，关注遗留系统的退役与下线。在核心银行迁移中，二者应结合使用：用Strangler方法做过程管理，用绞杀者思维做终局规划。

四、适用场景与不适用场景

适用场景：

• 遗留系统庞大、耦合深、无法一次性替换，如核心银行账务、总账、计息模块。
• 业务需要持续运行，不能接受长时间停机或大爆炸式切换。
• 存在清晰的业务能力边界，可通过API、消息或文件接口进行隔离。
• 团队具备路由、灰度、监控、回退等工程能力。
• 迁移目标明确，且允许新旧系统在一段时间内共存。

不适用场景：

• 遗留系统规模小、耦合低，直接重写或替换成本更低。
• 业务要求一次性切换，且无法接受双轨运行带来的数据一致性风险。
• 系统边界模糊，无法识别可独立替换的能力单元。
• 缺乏路由与灰度能力，无法控制流量切换与回退。
• 组织缺乏长期投入意愿，期望短期完成全部迁移。

五、案例与复盘：某银行客户信息查询迁移

某银行核心系统迁移中，首先选择“客户信息查询”作为第一个绞杀单元。该能力读多写少、耦合低、风险可控。实施步骤如下：

1. 在API网关中建立路由规则，将客户信息查询请求按比例导向新服务。
2. 新服务通过适配层读取遗留系统数据，保证数据一致性。
3. 灰度比例从1%逐步提升至100%，期间监控响应时间、错误率与数据差异。
4. 确认无差异后，关闭遗留系统对应查询入口，完成下线。

# 路由灰度配置示例（伪代码）
route:
  - name: customer-info-query
    legacy: core-legacy:8080/customer/query
    modern: customer-service:8081/api/customer/query
    strategy: weighted
    weights:
      legacy: 90
      modern: 10
    fallback: legacy
    monitor:
      - latency_p99
      - error_rate
      - data_diff_count

复盘发现：迁移成功的关键不是技术，而是边界选择与回退机制。第一个单元选择查询类能力，风险最低、验证最快；回退机制确保任何异常都能在秒级切回遗留系统。后续迁移利息计算时，因涉及账务一致性，团队提前建立了双跑对账机制，才敢逐步放量。