2. 旧核心系统认知
做产品参数迁移，第一步不是写脚本，而是把旧核心系统“看透”。旧核心往往运行了十几年甚至二十多年，它的架构、数据组织和参数语义，直接决定了迁移的难度、风险点和映射策略。本章从架构特点、参数存储方式、常见参数类型与业务含义三个层面，建立对旧核心的系统性认知。
一、旧核心架构特点：集中、耦合、批处理驱动
旧核心系统（常被称为“老核心”“主机核心”）大多诞生于集中式架构时代，其典型特征可以归纳为以下几点：
- 集中式单体架构：存款、贷款、卡、总账等模块运行在同一套应用与数据库实例中，模块间通过内部调用或共享表直接交互，边界模糊。
- 紧耦合：产品参数与交易逻辑、账务逻辑深度绑定，很多参数并非“配置”，而是硬编码在程序分支或存储过程中。
- 批处理驱动：日终批量（如计息、计提、结息、对账）是核心业务的主要执行方式，参数变更往往在日终或日初生效。
- 字符终端与定长报文：柜面通过终端界面操作，系统间通过定长报文或文件交换，字段长度、精度、编码规则严格受限。
- 数据库以关系型为主：常见 DB2、Oracle、Sybase，表结构高度范式化或反范式化并存，字段命名多用缩写。
理解旧核心的“批处理生效”特性非常关键：迁移窗口、参数生效时点、数据一致性校验，都必须围绕批量作业的节奏来设计。
二、产品参数存储方式：从参数表到硬编码
旧核心中“产品参数”并非集中存放，而是分散在多种载体中。迁移前必须逐一识别，否则会出现“参数漏迁”或“语义错迁”。常见存储方式如下：
| 存储方式 | 典型载体 | 迁移关注点 |
|---|---|---|
| 参数表 | 产品定义表、利率表、费率表、期限表 | 主键、生效日期、版本、状态字段 |
| 代码表/字典表 | 产品码、币种、账户类型、交易码 | 编码含义、映射关系、是否可扩展 |
| 配置文件 | 应用配置、批量参数、开关项 | 环境差异、默认值、覆盖规则 |
| 存储过程/程序分支 | 计息逻辑、费率计算、限额判断 | 隐式参数、硬编码阈值、条件组合 |
| 定长报文/接口定义 | 字段位置、长度、精度 | 精度截断、符号位、填充规则 |
下面是一段典型的旧核心参数表查询示例，用于定位某产品的利率参数：
SELECT PROD_CODE, CCY, RATE_TYPE, RATE_VAL,
EFF_DATE, EXP_DATE, STATUS
FROM T_PROD_RATE
WHERE PROD_CODE = 'SB001'
AND CCY = 'CNY'
AND STATUS = 'A'
ORDER BY EFF_DATE DESC;
查询结果中，EFF_DATE 与 EXP_DATE 构成时间区间，STATUS 表示启用状态。迁移时必须保留这种“时间切片”语义，否则新核心可能取到错误版本。
三、常见参数类型与业务含义
旧核心的产品参数种类繁多，但按业务含义可归为几大类。理解每一类的业务作用，是建立映射规则的前提。
- 产品定义参数：产品码、产品名称、账户类型、币种、起存金额、期限类型，决定“这是什么产品”。
- 利率参数：基准利率、浮动方式、浮动值、利率类型（固定/浮动）、计息方式（单利/复利），决定“利息怎么算”。
- 费率参数：手续费、管理费、提前支取费、费率计算基数与收取方式，决定“费用怎么收”。
- 期限与到期参数：存期、到期处理方式（转存/转活期/销户）、自动转存标志，决定“到期怎么办”。
- 限额与风控参数：单笔限额、日累计限额、透支额度、冻结规则，决定“能做多大”。
- 账务与核算参数：科目号、内部账户、核算码、计提标志，决定“账记到哪里”。
常见误区：把“利率参数”简单理解为一行数值。实际上利率往往由基准、浮动方式、浮动值、生效区间、客户等级等多个字段共同决定，漏掉任一维度都会导致迁移后计息错误。
四、案例与复盘：一次参数漏迁的排查
某银行迁移定期存款产品时，新核心上线后发现部分账户利息少算。排查过程如下：
- 对比新旧核心同一账户的计息结果，定位差异出现在“提前支取”场景。
- 回溯旧核心参数表，发现提前支取利率存放在
T_PROD_RATE中RATE_TYPE='ADV'的记录里。 - 迁移映射表只映射了
RATE_TYPE='STD'的标准利率，遗漏了'ADV'类型。 - 补充映射规则并重跑迁移，差异消除。
复盘结论：旧核心用同一张表的不同 RATE_TYPE 承载多种利率语义，迁移前必须做“参数类型枚举盘点”，而不是只按表名映射。
通过这张分布图可以看到，旧核心参数从“载体”到“业务类型”再到“迁移动作”是一条完整的链路。任何一环缺失，都会在迁移后以业务差错的形式暴露出来。因此，在动手迁移之前，先完成参数盘点、类型枚举和映射设计，是本章最核心的落地要求。