2. 核心银行系统概述
核心银行系统（Core Banking System，CBS）是银行处理存款、贷款、支付、账户与总账等基础业务的“心脏”。它并非单一应用，而是一组围绕客户账户与会计总账构建的集中化系统集合。理解它的定义、架构与模块划分，是掌握批处理与实时事件协同的前提。
一、核心银行的定义与边界
核心银行系统通常指支持银行核心业务运转、以客户账户和总账为中心、具备集中化账务处理能力的系统。它的边界可以从三个维度界定：
- 业务维度：覆盖存款、贷款、支付结算、卡、总账等基础业务。
- 数据维度：以客户、账户、交易、余额、总账为核心主数据。
- 技术维度：强调高可用、强一致、可审计，通常采用集中式数据库与批量调度框架。
需要区分的是，核心银行不等于“所有银行系统”。渠道系统、风控系统、反欺诈、报表平台等通常围绕核心银行构建，通过接口或事件与之协同。
二、典型架构分层
现代核心银行系统一般分为四层：渠道接入层、业务服务层、核心账务层与数据支撑层。渠道层负责手机银行、网银、柜面等接入；业务服务层负责产品组合与流程编排；核心账务层负责账户、交易、余额与总账；数据支撑层负责批量调度、数据仓库与报表。
三、主要业务模块
核心银行系统通常包含以下主要模块，它们共同支撑银行日常运营：
| 模块 | 核心职责 | 典型处理方式 |
|---|---|---|
| 客户信息管理 | 客户主数据、证件、关系维护 | 实时查询 + 批量同步 |
| 存款与账户 | 开户、销户、余额、冻结 | 实时联机 + 日终计息 |
| 贷款管理 | 放款、还款、计息、逾期 | 批量计提 + 实时还款 |
| 支付结算 | 转账、汇款、清算 | 实时受理 + 批量清算 |
| 总账与会计 | 科目、凭证、试算平衡 | 日终批量过账 |
| 卡管理 | 发卡、授权、交易入账 | 实时授权 + 批量入账 |
四、批处理与实时处理的定位与关系
批处理与实时处理并非对立，而是核心银行系统中互补的两种处理模式。实时处理负责“当下发生”的交易，强调低延迟与用户体验；批处理负责“周期汇总”的任务，强调吞吐量、一致性与可审计性。
核心关系：实时交易产生事件与流水，批处理在日终或周期节点对流水进行汇总、计息、对账与过账。实时是“点”，批量是“面”；实时保证体验，批量保证准确。
典型协同流程如下：
- 客户发起一笔转账，实时联机交易完成账户扣款与入账，并写入交易流水。
- 交易同时发布事件到事件总线，供风控、通知、反欺诈等系统消费。
- 日终批量任务读取当日流水，进行计息、手续费计提、总账过账。
- 批量完成后生成对账文件，与渠道、清算机构进行核对。
- 若批量发现异常，通过差错处理流程回补或冲正。
下面是一段典型的日终批量调度配置示例，用于说明批处理任务的编排方式：
# 日终批量调度配置示例
job:
name: eod_interest_posting
schedule: "0 30 23 * * ?" # 每日23:30触发
steps:
- step: load_transaction_flow
desc: 加载当日交易流水
- step: calculate_interest
desc: 按账户计息
- step: post_to_gl
desc: 总账过账
- step: generate_reconciliation
desc: 生成对账文件
retry: 3
timeout: 7200
五、常见误区与复盘
误区一：认为实时处理可以完全替代批处理。实际上，计息、总账过账、对账等任务对一致性和审计要求极高，批量仍是主流选择。
误区二：忽视实时与批量的数据一致性。若实时交易未正确落流水，批量将无法准确汇总，导致账务差错。
误区三：批量窗口过短导致任务堆积。应通过任务拆分、并行调度与事件驱动补跑机制来缓解。
复盘建议：在设计核心银行系统时，先明确哪些业务必须实时、哪些可以批量，再定义两者之间的数据契约与事件契约。实时与批量的边界清晰，系统才能既快又稳。
综上，核心银行系统以账户与总账为中心，通过分层架构支撑多渠道业务。批处理与实时处理各司其职、协同工作，共同保障银行账务的准确性与服务的连续性。理解这一关系，是后续学习批处理调度、事件驱动与差错处理的基础。