2. 核心银行系统概述
核心银行系统（Core Banking System，CBS）是银行处理存款、贷款、支付、总账等基础金融业务的后台中枢。它并非单一应用，而是由客户信息、账户管理、产品合约、交易核算、总账清算等多个模块协同构成的业务与技术集合。理解其定义、模块划分、架构特征与交易类型，是开展性能基线与容量验证的前提。
一、核心银行的定义与业务模块
从业务视角看，核心银行系统承载银行“存、贷、汇”三大基础能力，并向下延伸至利息计算、费用扣收、账户状态管理、总账记账等。其典型业务模块包括：
- 客户与合约模块：管理客户基本信息、证件、联系方式，以及存款、贷款、理财等产品合约的开立、变更与终止。
- 账户管理模块：负责账户开立、冻结、解冻、销户、余额查询、账户状态维护。
- 交易处理模块：处理现金存取、转账、汇款、代收代付、贷款发放与还款等实时交易。
- 计息与费用模块：按日/月/季进行利息计提、结息、费用计算与扣收。
- 总账与清算模块：完成会计分录、科目汇总、日终轧账、与支付系统对账。
- 产品与参数模块：维护利率、汇率、费率、交易码、限额等参数，驱动业务规则。
这些模块之间通过交易码、账户号、客户号、机构号等关键字段紧密耦合，任一模块的性能瓶颈都可能沿调用链放大为全局问题。
二、技术架构与典型交易类型
现代核心银行系统多采用“集中式主机 + 分布式外围”或“分布式微服务 + 集中式数据库”的混合架构。典型分层如下：
| 层级 | 主要组件 | 性能关注点 |
|---|---|---|
| 渠道接入层 | 柜面、手机银行、网银、ATM、开放API | 并发连接数、报文解析、限流 |
| 应用服务层 | 交易路由、业务服务、批量调度 | 线程池、响应时间、服务依赖 |
| 核心业务层 | 账户、合约、计息、总账 | 事务边界、锁竞争、热点账户 |
| 数据存储层 | 关系型数据库、缓存、消息队列 | IOPS、连接数、主从延迟 |
| 基础设施层 | 主机、存储、网络、中间件 | CPU、内存、带宽、磁盘队列 |
核心银行交易可分为联机交易与批量交易两大类。联机交易如余额查询、行内转账、跨行汇款、贷款还款，要求毫秒级至秒级响应；批量交易如日终结息、总分核对、报表生成，强调吞吐量与窗口时间。典型联机交易示例：
交易码: 1001 余额查询
交易码: 2001 行内转账
交易码: 3001 跨行汇款
交易码: 4001 贷款发放
交易码: 5001 信用卡还款
批量作业: EOD_INTEREST 日终结息
批量作业: EOD_RECON 总分核对三、性能挑战与核心原理
核心银行的性能挑战集中体现在“高并发、强一致、热点集中、批量窗口紧”四个方面。其核心原理可归纳为：
- 事务一致性优先：账户余额、总账分录必须满足ACID，锁与日志写入成为关键路径。
- 热点账户效应：工资代发、商户归集等场景下，单一账户被高频更新，形成行锁或页锁竞争。
- 批量与联机争抢：日终批量与夜间联机交易共享数据库资源，IO与CPU相互挤压。
- 调用链放大：一笔转账可能触发账户校验、限额检查、计息、记账、通知等多个服务，任一环节延迟都会累积。
性能基线验证的本质，是在可控负载下测量核心交易在“正常、峰值、异常”三种状态下的响应时间、吞吐量与资源占用，并据此推导容量上限。
四、案例场景与常见误区
某银行在季度结息日发现联机转账成功率骤降。排查发现，日终结息批量作业与联机交易共用同一数据库实例，结息更新大量账户余额，导致行锁等待时间从5ms升至800ms。复盘结论是：批量与联机未做资源隔离，且未在基线测试中模拟“批量+联机”混合场景。
常见误区一：只测单交易TPS，忽略混合场景下的锁竞争与资源争抢。
常见误区二：用平均响应时间掩盖长尾延迟，P99可能已超监管阈值。
常见误区三：容量验证只关注应用服务器，忽视数据库连接池与存储IOPS上限。
因此，在后续章节中，我们需要围绕核心交易建立可复现的基线模型，明确交易配比、数据分布、并发梯度与观测指标，才能让容量验证结论真正支撑生产决策。