2. Legacy核心银行系统剖析
在启动任何现代化改造之前，必须先看清“旧系统到底长什么样”。Legacy核心银行系统并非单一程序，而是由主机硬件、事务中间件、批处理调度、COBOL/PL/I程序、VSAM/DB2数据层共同构成的紧耦合技术栈。理解它的典型架构、关键模块与技术债分布，是制定改造路线的前提。
一、典型架构：集中式主机与分层耦合
多数Legacy核心银行采用集中式主机架构，以IBM z/OS或大型UNIX小型机为底座，通过CICS或IMS提供联机事务处理，通过JCL与批处理窗口完成日终结算。其典型分层如下：
- 接入层：ATM、柜面、网银、手机银行通过前置机与MQ/CICS网关接入。
- 联机事务层：CICS/IMS负责交易路由、会话管理与事务提交，单笔交易通常要求亚秒级响应。
- 业务逻辑层：COBOL/PL/I程序承载存款、贷款、支付、总账等核心逻辑，大量使用COPYBOOK共享数据结构。
- 数据层：VSAM文件、DB2表、IMS层次数据库并存，部分历史数据仍以顺序文件保存。
- 批处理层：夜间JCL作业链完成计息、对账、总账过账、报表生成，窗口通常只有4～6小时。
核心特征：联机与批处理共享同一套数据文件，任何字段变更都可能同时影响CICS交易和夜间JCL作业，这是改造中“牵一发而动全身”的根源。
二、关键模块：存款、贷款、支付、总账
核心银行系统的业务逻辑高度模块化，但模块之间通过共享文件和COPYBOOK紧密耦合。四个关键模块的职责与典型技术实现如下：
| 模块 | 核心职责 | 典型技术实现 | 改造难点 |
|---|---|---|---|
| 存款 | 账户开立、存取款、计息、冻结、销户 | COBOL + VSAM KSDS，CICS联机交易 | 计息规则复杂，历史账户结构差异大 |
| 贷款 | 放款、还款、展期、利率调整、五级分类 | COBOL + DB2，批处理计息与计提 | 利率模型与监管规则频繁变更 |
| 支付 | 行内转账、跨行清算、报文转换、对账 | CICS + MQ + 清算网关，PL/I报文处理 | 报文标准多版本并存，清算窗口刚性 |
| 总账 | 科目映射、分录过账、日终试算、报表 | COBOL批处理 + DB2，JCL作业链 | 科目体系与业务代码强绑定，难以解耦 |
三、技术债与业务痛点
Legacy系统的技术债并非单一问题，而是架构、代码、数据、运维四个维度叠加的结果。常见表现包括：
- 架构债：联机与批处理共享数据文件，无法独立扩展；CICS区域与DB2连接数成为性能瓶颈。
- 代码债：COBOL程序平均长度超过3000行，GO TO语句密集，缺乏单元测试；COPYBOOK变更需全量回归。
- 数据债：VSAM与DB2数据冗余，字段命名不一致，历史数据缺少主键约束，数据质量差。
- 运维债：JCL作业依赖人工排障，批处理窗口逐年压缩，夜间故障恢复时间不可控。
- 人才债：COBOL/PL/I开发人员老龄化，新员工学习曲线陡峭，知识传承断层。
常见误区：认为“把COBOL翻译成Java”就等于现代化。实际上，若不同时解耦数据层、重构批处理调度、建立自动化测试，翻译后的系统只是换了一种语言继续背负原有技术债。
四、场景复盘：一次计息变更引发的连锁反应
某银行拟调整存款计息规则，开发人员在COBOL计息程序中修改了利率计算逻辑。联机测试通过后上线，但次日日终批处理出现总账不平。排查发现：联机交易使用的计息副本与批处理JCL调用的计息程序并非同一版本，且总账过账程序依赖旧版计息结果中的舍入字段。最终通过回滚并同步修改三个COPYBOOK才恢复。
// 典型JCL作业链片段（简化）
//DAILYINT JOB (ACCT),'DAILY INTEREST',
// CLASS=A,MSGCLASS=X
//STEP01 EXEC PGM=INTCALC,REGION=4M
//VSAMIN DD DSN=PROD.ACCT.MASTER,DISP=SHR
//VSAMOUT DD DSN=PROD.ACCT.INT.DATA,DISP=(NEW,CATLG)
//STEP02 EXEC PGM=GLPOST,COND=(0,NE)
//INTFILE DD DSN=PROD.ACCT.INT.DATA,DISP=SHR
//GLFILE DD DSN=PROD.GL.MASTER,DISP=OLD
//* 注意：STEP02依赖STEP01的输出，且共享GL主文件
复盘启示：Legacy改造前必须建立“程序—文件—作业”的依赖图谱，识别联机与批处理的共享边界。任何字段级变更都应触发全链路影响分析，而非仅做单元测试。
综上，Legacy核心银行的剖析重点在于：看清集中式主机架构的分层耦合关系，理解存款、贷款、支付、总账四大模块的技术实现与改造难点，识别架构、代码、数据、运维、人才五类技术债，并通过依赖图谱和影响分析避免“翻译式改造”的陷阱。这些认知将直接决定后续现代化路线的选择与优先级排序。