1. 课程导入

欢迎进入《核心银行Legacy现代化改造路线实战》。在动手写第一行迁移脚本之前，我们必须先建立三个共识：什么是核心银行Legacy系统、为什么现在必须改、以及这门课将带你走完怎样一条路线。本章不涉及具体代码实现，但它决定了你后续29章的学习坐标系——方向错了，技术越熟练，返工越昂贵。

一、核心银行Legacy系统的定义与典型特征

核心银行系统（Core Banking System）是银行处理存款、贷款、支付清算、客户账户与总账的“心脏”。而Legacy系统并非简单的“老旧系统”，它通常指那些仍在承载关键业务、但技术栈已脱离主流维护周期、且变更成本极高的系统。判断一个系统是否属于Legacy，不能只看上线年份，而要看它是否同时具备以下特征：

• 技术栈封闭：以COBOL、PL/I、RPG、汇编为主，运行在IBM z/OS、AS/400或UNIX小型机上，依赖VSAM、IMS、CICS、MQ等中间件。
• 业务逻辑内嵌：利率计算、手续费规则、账户状态机直接写在过程式代码里，缺少领域模型与接口契约。
• 数据耦合严重：账户、客户、交易、总账共享同一套物理表结构，字段被数百个程序复用，牵一发动全身。
• 知识断层：原始开发者大量退休，文档缺失，系统行为只能靠“读代码+问老人+跑批验证”还原。
• 变更窗口极窄：日终批处理占用夜间数小时，任何改动都要抢在批处理窗口前完成并回滚预案。

很多团队误以为“把COBOL翻译成Java”就是现代化。实际上，Legacy的真正负担不在语言，而在隐式业务规则、数据语义和批处理时序。这三者才是改造中反复踩坑的根源。

二、现代化改造的紧迫性：四股力量同时施压

为什么不能“再撑五年”？因为四股力量正在同时收紧：

1. 业务压力：开放银行、实时支付、个性化定价要求系统支持秒级响应与高频产品迭代，而Legacy的批处理周期以“天”为单位。
2. 人才压力：COBOL工程师平均年龄持续上升，招聘成本高、培养周期长，关键系统逐渐进入“无人敢改”状态。
3. 监管压力：数据治理、反洗钱、灾备演练、审计追溯对系统可观测性和数据血缘提出更高要求，黑盒式Legacy难以满足。
4. 成本压力：主机MIPS费用、专有中间件授权、维护合同逐年上涨，而系统吞吐与灵活性却停滞不前。

这四股力量叠加的结果是：不改，风险在累积；乱改，风险会提前爆发。因此本课程强调“路线”而非“工具”——先评估、再解耦、后迁移、最后重构，每一步都有可验证的退出条件。

三、课程整体框架：四阶段路线图

本课程共30章，按“评估—解耦—迁移—重构”四阶段推进，每阶段都有明确的交付物与验收标准。下表给出整体框架，帮助你建立全局视角：

四、案例场景：一次“翻译式改造”的复盘

某城商行曾启动“COBOL转Java”项目，团队用自动化工具将80%的过程式代码逐行翻译为Java，半年后上线。结果第一个月就出现三类问题：

• 利息计算偏差：COBOL使用定点十进制运算，翻译后的Java使用double，累计误差导致对账不平。
• 批处理时序错乱：原系统依赖JCL作业流顺序，翻译后并行执行，总账更新早于交易入账。
• 隐式规则丢失：某段代码中“余额小于0时自动冻结”的逻辑未被识别，翻译后变成普通日志。

这个案例也解释了为什么本课程把“评估与盘点”放在最前面：没有规则清单和数据血缘，后续所有迁移都是在流沙上盖楼。

五、学习目标与常见误区

完成本课程后，你应当能够：

1. 独立完成一个Legacy模块的业务规则提取与数据血缘分析。
2. 设计合理的服务边界与防腐层，避免“分布式单体”。
3. 制定双跑对账与灰度切流方案，并编写可回滚的切流脚本。
4. 识别批处理时序依赖，设计新旧系统并行运行策略。
5. 输出Legacy退役清单与知识转移文档，完成闭环。