2. 核心银行系统基础
在讨论 Strangler 渐进迁移之前，必须先建立对“核心银行系统”本身的准确认知。很多迁移项目失败，并非技术选型错误，而是团队对核心银行系统的边界、耦合方式和业务语义理解不足，导致绞杀者策略在错误的位置切入。本节从定义、业务模块、技术架构特征和迁移驱动因素四个维度，为后续实战建立共同语言。
一、核心银行系统的定义与边界
核心银行系统（Core Banking System，CBS）是银行用于处理存款、贷款、支付、账户和总账等基础金融交易的后台系统集合。它的核心特征是：以客户账户为中心，以交易记账为主线，以总账一致性为约束。与渠道系统、风控系统、报表系统不同，核心银行系统直接持有账户余额和交易流水，是银行“账本”的最终权威来源。
理解边界时，可以用一个判断标准：如果一个系统的数据错误会直接导致客户余额或银行总账不平，它大概率属于核心银行域。这个标准在后续划分绞杀边界时非常关键。
核心银行系统的本质不是“很多功能的集合”，而是“一套强一致的记账约束”。迁移时若只迁移功能而忽略约束，就会出现账实不符。
二、典型业务模块
不同银行的核心银行系统模块划分略有差异，但通常包含以下典型模块：
- 客户与账户管理：客户信息、账户开立、账户状态、账户层级关系。
- 存款业务：活期、定期、通知存款的存入、支取、计息、结息。
- 贷款业务：放款、还款、计息、罚息、展期、核销。
- 支付与清算：行内转账、跨行支付、清算轧差、对账。
- 总账与会计：会计分录、科目余额、日终试算平衡。
- 利息与费用：利率表、计息规则、手续费计算。
- 日终与批量：日切、批量计息、对账、报表生成。
这些模块之间并非独立，而是通过账户、交易流水和总账科目紧密耦合。例如一笔贷款放款，会同时触发账户余额变化、会计分录生成和总账科目更新。这种跨模块的事务一致性，是核心银行迁移中最难处理的部分。
三、技术架构特征
传统核心银行系统的技术架构通常具有以下特征：
| 特征维度 | 典型表现 | 迁移影响 |
|---|---|---|
| 部署形态 | 集中式主机或大型机，单体应用 | 难以按业务拆分，绞杀切入点需谨慎选择 |
| 数据存储 | 关系型数据库，强事务，存储过程密集 | 业务逻辑藏在存储过程中，迁移需先剥离 |
| 事务模型 | 本地强一致事务，跨模块两阶段提交 | 微服务化后需引入分布式事务或补偿机制 |
| 批处理 | 日终批量窗口固定，依赖文件交换 | 迁移后需保证批量时序和依赖关系不变 |
| 接口方式 | 文件、消息队列、专有协议混合 | 需建立统一防腐层隔离新旧接口差异 |
| 代码规模 | 数百万行，历史包袱重，文档缺失 | 需通过绞杀者逐步替换而非重写 |
这些特征决定了核心银行迁移不能采用“推倒重来”的方式，而必须采用渐进式策略，在保持现有系统运行的前提下，逐步将业务能力迁移到新系统。
四、迁移的常见驱动因素
银行启动核心银行迁移，通常不是单一原因，而是多重压力叠加的结果。常见驱动因素包括：
- 业务敏捷性不足：新产品上线周期长达数月，无法响应市场变化。
- 技术栈老化：主机语言、存储过程、专有协议导致人才断层和维护成本高企。
- 扩展性瓶颈：集中式架构难以支撑高并发和互联网级流量。
- 合规与监管：新监管要求（如数据本地化、实时报送）旧系统难以满足。
- 成本压力：主机授权、运维和人力成本逐年上升。
- 生态集成需求：开放银行、第三方支付、云原生生态要求系统具备开放接口能力。
驱动因素决定了迁移的优先级。如果主要驱动是业务敏捷性，应优先绞杀产品配置和渠道接入；如果主要驱动是成本，则应优先绞杀高运维成本的批量模块。
五、常见误区与复盘
在核心银行迁移的早期阶段，团队常陷入以下误区：
- 误区一：把核心银行当成普通单体应用。忽略总账一致性和批量时序，导致迁移后账务不平。
- 误区二：先迁移数据层。数据层耦合最深、回滚最难，应放在最后而非最先。
- 误区三：没有防腐层直接调用旧系统。新旧接口差异渗透到新代码，绞杀者变成“缠绕者”。
- 误区四：忽略日终批量窗口。新系统批量时间与旧系统不一致，导致对账失败。
复盘经验：成功的核心银行绞杀迁移，通常先在渠道层做流量路由，再逐步下沉到业务层，每一步都保留可回滚能力。任何一步失去回滚能力，都应暂停并重新设计。
理解核心银行系统的定义、模块、架构特征和迁移驱动，是设计绞杀策略的前提。只有准确识别系统边界和耦合关系，才能选择正确的切入点，避免在迁移过程中破坏账务一致性和业务连续性。