2. 核心银行系统基础
在讨论“单体到微服务迁移”之前，必须先回到被迁移的对象本身。核心银行系统（Core Banking System，CBS）不是某一个具体软件，而是银行用于处理存款、贷款、支付、总账等核心账务与客户关系的基础系统集合。它承担“钱从哪里来、到哪里去、账是否平”的根本职责，是银行 IT 架构中变更成本最高、监管约束最严、容错要求最强的部分。理解它的业务边界与技术特征，是后续迁移规划能否成立的前提。
一、核心银行的定义与边界
核心银行系统通常指支撑银行基础业务运转、直接参与账务记录与资金清算的系统群。它的核心特征有三点：第一，账务准确性优先，任何交易都必须保证借贷平衡、可追溯、可审计；第二，客户与账户为中心，围绕客户信息、账户、产品、利率、费用等主数据展开；第三，强监管约束，受人民银行、金融监管总局等机构在数据、报送、连续性方面的硬性要求。与之相对，渠道类、营销类、报表分析类系统通常不被视为核心银行本体，但它们与核心系统存在高频交互。
二、主要业务模块与职责
核心银行系统内部通常按业务能力划分为若干模块，各模块之间通过账务联动形成闭环。下表列出常见模块及其关键职责与典型数据对象：
| 业务模块 | 关键职责 | 典型数据对象 | 迁移关注点 |
|---|---|---|---|
| 存款模块 | 活期/定期账户开立、存取、计息、冻结、销户 | 存款账户、利率、积数、交易流水 | 计息精度、账户状态一致性 |
| 贷款模块 | 放款、还款、展期、逾期、五级分类、拨备 | 贷款账户、合同、还款计划、担保 | 还款计划重算、利息与罚息规则 |
| 支付模块 | 行内转账、跨行清算、报文收发、对账 | 支付指令、清算报文、对账文件 | 幂等、冲正、清算窗口时序 |
| 总账模块 | 会计科目、分录、日终轧账、报表生成 | 科目、分录、余额、试算平衡表 | 借贷平衡、日切与会计日期 |
| 客户与产品 | 客户信息、产品参数、利率费率、合约 | 客户号、产品码、参数表 | 主数据共享与版本管理 |
这些模块在单体架构中往往共享同一数据库、同一事务、同一套账务逻辑。迁移到微服务时，最大的挑战不是“拆开”，而是拆开之后如何继续保持账务的强一致与可审计。
三、技术特点：为什么核心银行“不好动”
核心银行系统的技术特征决定了迁移策略必须保守而精细。典型特点包括：
- 强事务性：一笔交易常涉及存款、总账、手续费等多个表的写入，必须在一个事务内完成，否则会出现“钱扣了账没记”的严重问题。
- 批处理与联机混合：日间联机交易与夜间批量计息、对账、报表并存，日切窗口极短，迁移必须考虑批流切换。
- 高并发与低延迟：柜面、手机银行、ATM 等渠道同时发起请求，核心系统需在毫秒级完成账务处理。
- 数据模型复杂且历史包袱重：大量存储过程、触发器、遗留字段，文档缺失，逻辑隐含在代码中。
- 7×24 连续性要求：停机窗口以分钟计，迁移方案必须支持灰度、双写或在线切换。
四、监管要求与迁移约束
监管要求是核心银行迁移的“硬边界”。主要约束包括：
- 数据本地化与保密：客户金融信息不得随意出境，迁移过程中数据脱敏、加密、访问审计必须到位。
- 业务连续性：需满足监管对 RTO/RPO 的要求，迁移方案必须包含回退路径与演练记录。
- 账务可追溯：任何账务变更都要有完整流水与操作日志，微服务拆分后日志需跨服务关联。
- 报送与对账：监管报送、清算对账依赖固定数据口径，迁移不能改变对外报送的语义。
- 变更管理：重大架构变更通常需提前报备，并接受现场检查或第三方审计。
下面是一段典型的日终批处理日志片段，迁移后需要保证类似输出仍可被对账系统识别：
2025-03-31 23:58:01 [BATCH] start day-end interest accrual
2025-03-31 23:58:07 [ACCT] processed=128430 failed=0
2025-03-31 23:59:12 [GL] journal entries generated=256860
2025-04-01 00:00:03 [CHECK] trial balance: debit=credit OK
2025-04-01 00:00:05 [BATCH] day-end completed, next accounting date=2025-04-01五、案例场景：一次跨模块迁移的复盘
某银行在将“贷款还款”能力从单体核心中剥离时，最初只拆出了贷款服务，但还款动作仍需调用存款扣款与总账记账。由于三个服务各自独立事务，测试环境出现“贷款已销账、存款未扣款”的不一致。复盘后采取的措施是：先以“还款交易”为限界上下文，将扣款、销账、记账封装为同一业务服务内的本地事务；待一致性框架成熟后，再按账户维度逐步拆分。这个案例说明，核心银行迁移的粒度应由业务事务边界决定，而不是由组织架构或技术偏好决定。