2. 核心银行系统概览

在讨论接口兼容与适配层之前，必须先建立对核心银行系统（Core Banking System，CBS）的整体认知。适配层之所以复杂，根本原因在于核心系统本身是一个高度耦合、模块众多、接口风格混杂的"历史沉积体"。只有看清它的架构分层、业务模块边界和接口生态，才能判断哪些接口可以直连、哪些必须经过适配转换、哪些应当被隔离或替换。

一、核心银行系统的分层架构

典型核心银行系统在逻辑上可划分为四层，自下而上依次为：数据层、核心业务层、渠道接入层与集成层。数据层承载客户信息、账户、交易流水、总账等主数据，通常以关系型数据库为主，部分老系统仍保留主机上的VSAM或IMS结构。核心业务层是系统的"心脏"，负责存款、贷款、支付、计息、总账等关键业务逻辑，强调事务一致性与账务准确性。渠道接入层面向柜面、网银、手机银行、ATM、开放银行等前端，负责协议转换与安全认证。集成层则通过ESB、API网关或消息中间件，把核心能力暴露给外围系统。

理解这一分层对适配层设计至关重要：适配层通常位于集成层与核心业务层之间，或嵌入渠道接入层内部。它需要屏蔽的，正是核心业务层对外暴露的"非标准化"接口形态。

二、主要业务模块与接口暴露方式

核心银行系统的业务模块通常按产品线划分，每个模块对外暴露的接口风格差异很大。存款模块提供开户、销户、存取款、账户查询等接口，老系统多以定长报文或COBOL copybook格式交互；贷款模块涉及放款、还款、试算、利率调整，接口往往带有复杂的参数结构和状态机；支付模块对接人行支付系统、银联、SWIFT，接口遵循ISO 8583或XML规范；总账模块负责会计分录与日终批处理，接口多为文件批量导入或存储过程调用。

这些模块的接口在协议、数据格式、同步方式、错误码体系上并不统一。例如，存款接口可能是同步的CICS交易，支付接口可能是异步的MQ消息，总账接口可能是T+1的批量文件。适配层的核心任务，就是把这些异构接口统一成外围系统可消费的一致契约。

三、常见接口类型与接口生态

从技术形态看，核心银行系统常见接口可分为五类：主机交易接口（CICS/IMS Transaction）、消息队列接口（MQ/IBM MQ）、文件接口（批量文件/定长记录）、数据库直连接口（存储过程/视图）以及现代API接口（REST/SOAP）。前四类属于"传统接口"，往往缺乏契约描述、版本管理和错误标准化；第五类是新核心或开放平台提供的，但多数银行处于新旧并存状态。

接口生态的复杂性还体现在调用方向上：外围系统调用核心（如查询余额）、核心调用外围（如支付结果通知）、以及核心内部模块互调。适配层需要同时处理入站和出站两个方向的转换。一个常见的误区是只关注入站适配，忽略核心主动发起的出站通知，导致异步场景下数据不一致。

四、案例与复盘：某银行渠道接入适配实践

某城商行在手机银行接入核心存款系统时，最初采用直连方式：手机银行直接调用核心CICS交易。上线后发现三个问题：一是核心定长报文对字段长度敏感，手机银行传入的备注超长导致交易截断；二是核心错误码为四位数字，渠道无法区分"余额不足"与"账户冻结"；三是核心交易为同步阻塞，高峰期渠道线程被占满。

引入适配层后，团队做了三件事：第一，在适配层定义统一的JSON契约，把定长报文转换为带字段名的结构，并对长度、精度做前置校验；第二，建立错误码映射表，把核心错误码翻译为渠道可理解的业务错误；第三，对查询类交易增加缓存与异步化，降低核心压力。复盘时发现，适配层最大的价值不是"转换"，而是"隔离"——核心升级或字段调整时，只需修改适配层，渠道无感知。

# 适配层错误码映射配置示例
error_mapping:
  core_code: "1001"
  channel_code: "BALANCE_INSUFFICIENT"
  message: "账户余额不足"
  retryable: false
---
core_code: "2003"
channel_code: "ACCOUNT_FROZEN"
message: "账户已冻结，请联系柜面"
retryable: false
---
core_code: "9999"
channel_code: "CORE_TIMEOUT"
message: "核心系统繁忙，请稍后重试"
retryable: true

综上，核心银行系统的架构分层决定了适配层的插入位置，业务模块的接口差异决定了适配层的转换复杂度，而接口生态的新旧并存决定了适配层必须长期演进。理解这三者，是后续设计兼容策略与适配模式的基础。