Arch Day 31: 核心银行架构概览

日期: 2026-04-30 (Day 31) 阶段: 第二阶段 - 金融域深度 标签: #核心银行 #CBS #BIAN #分布式架构 #大型机迁移

---

核心概念

一句话定义

核心银行系统（Core Banking System, CBS）是银行的"操作系统"——它不仅仅处理"存贷汇"，而是管理银行所有金融产品的账户、交易、记账和状态的中枢平台，是银行数字化能力的基座。

为什么资深架构师仍需关注

1. 核心银行换代是十年一遇的超大型架构项目：全球主要银行仍在进行核心系统现代化（如汇丰的 Global Payment Transformation、蚂蚁的"三地五中心"），每个项目预算数亿到数十亿美元
2. 它定义了金融系统的架构约束边界：你能做什么样的产品创新、能支持多快的响应速度、能扩展到什么规模，全部由核心银行的架构决定
3. DeFi正在重建核心银行的每一层：理解传统CBS才能真正理解DeFi协议为什么这样设计、解决了什么痛点、缺失了什么
4. AI正在重塑核心银行的运维和决策：从智能日切编排到AI驱动的异常检测，核心银行是AI落地金融的最深水区

常见误区与反模式

---

知识点详解

1. 核心银行系统的本质：银行的"操作系统"

核心银行不是一个单一应用，而是一组紧密耦合的子系统集群。类比操作系统：

操作系统类比：
├── 内核（Kernel）      = 记账引擎（Accounting Engine）
├── 文件系统            = 账户体系（Account System）
├── 进程调度            = 交易处理（Transaction Processing）
├── 内存管理            = 资金管理（Fund Management）
├── 设备驱动            = 渠道适配（Channel Adapter）
├── 系统调用API         = 核心服务接口（Core Service API）
└── 定时任务（Cron）     = 日终批处理（End-of-Day Batch）

核心银行管理的核心实体：

• 客户（Customer）：KYC信息、客户分群、关系管理
• 账户（Account）：所有金融产品的载体
• 交易（Transaction）：资金流动的记录
• 产品（Product）：银行提供的金融产品定义
• 合约（Contract/Agreement）：客户与银行之间的契约关系

2. 核心银行分层架构

graph TB
    subgraph "渠道层 Channel Layer"
        MB[手机银行]
        IB[网上银行]
        CT[柜面系统]
        ATM[ATM/自助]
        OB[开放银行API]
        TP[第三方接入]
    end

    subgraph "服务层 Service Layer"
        AG[API Gateway / ESB]
        BFF[BFF服务]
        ORCH[编排服务]
    end

    subgraph "核心层 Core Layer"
        DEP[存款核心]
        LOAN[贷款核心]
        PAY[支付核心]
        ACC[账务核心/总账]
        PROD[产品工厂]
        CUST[客户中心]
        RISK[风控引擎]
    end

    subgraph "基础层 Infrastructure Layer"
        DB[(数据库集群)]
        MQ[消息中间件]
        CACHE[分布式缓存]
        BATCH[批处理平台]
        MON[监控平台]
    end

    MB & IB & CT & ATM & OB & TP --> AG
    AG --> BFF --> ORCH
    ORCH --> DEP & LOAN & PAY & ACC & PROD & CUST & RISK
    DEP & LOAN & PAY & ACC --> DB & MQ & CACHE & BATCH

各层职责详解：

3. 联机交易(OLTP) vs 日终批处理(Batch) 的架构二元性

这是核心银行最根本的架构特征之一：白天做交易，晚上做清算。

graph LR
    subgraph "白天：联机交易 OLTP"
        T1[转账]
        T2[存款]
        T3[取款]
        T4[查询]
        T5[支付]
    end

    subgraph "日切 Day-End Cut-off"
        DC[日切点]
    end

    subgraph "夜间：批处理 Batch"
        B1[计息]
        B2[结息]
        B3[总分核对]
        B4[报表生成]
        B5[数据抽取]
        B6[逾期计算]
    end

    T1 & T2 & T3 & T4 & T5 --> DC
    DC --> B1 --> B2 --> B3 --> B4 --> B5 --> B6

OLTP特征：

• 单笔交易延迟要求：< 200ms（柜面）、< 500ms（移动端）
• TPS要求：大行峰值10万+（如双十一支付宝峰值92.77万笔/秒）
• 事务模型：ACID强一致
• 失败策略：实时回滚、冲正

Batch特征：

• 时间窗口：通常4-6小时（22:00 - 04:00）
• 数据量：千万到亿级账户的利息计算
• 容错策略：断点续跑、分片重试
• 依赖管理：严格的Job DAG编排

架构挑战——日切缩短与7x24趋势：

传统大型机时代，日切期间系统不可用是可接受的。但现在用户期望7x24访问，这催生了几种架构解法：

4. 账户-分户-总账的关系

graph TB
    GL[总账 General Ledger] --> SL1[分户账-存款]
    GL --> SL2[分户账-贷款]
    GL --> SL3[分户账-内部户]

    SL1 --> CA1[客户账户A-活期]
    SL1 --> CA2[客户账户B-定期]
    SL1 --> CA3[客户账户C-活期]

    SL2 --> LA1[贷款账户X-房贷]
    SL2 --> LA2[贷款账户Y-消费贷]

    SL3 --> IA1[过渡户-ATM]
    SL3 --> IA2[备付金户]
    SL3 --> IA3[清算户]

三者的本质关系：

• 总账（General Ledger）：银行财务报表的基础，按科目汇总所有交易。总账必须借贷平衡
• 分户账（Sub-ledger）：按业务类型分类的明细账，是总账的分解。分户账之和 = 总账对应科目余额
• 客户账户（Customer Account）：面向客户的最小记账单元，是分户账的最底层明细

关键原则：

1. 总分核对：每日批处理必须验证"各分户账余额之和 = 总账对应科目余额"
2. 复式记账：每笔交易至少影响两个科目（一借一贷），保持会计等式平衡
3. 账户不灭原则：账户一旦创建，只能标记为销户状态，不能物理删除（审计要求）

5. 核心银行的演进路径

timeline
    title 核心银行架构演进
    section 1970s-1990s
        大型机时代 : COBOL + DB2
                   : 垂直扩展
                   : 批处理为主
                   : 单体架构
    section 2000s-2010s
        分布式时代 : Java + Oracle
                   : SOA/ESB
                   : 集群部署
                   : 开始互联网化
    section 2015s-2020s
        云原生时代 : 微服务 + 容器
                   : 分布式数据库
                   : DevOps
                   : 互联网核心
    section 2020s-
        智能核心时代 : Headless Banking
                    : AI驱动决策
                    : 事件驱动
                    : 嵌入式金融

各阶段架构特征对比：

6. BIAN Service Domain在核心银行的映射

BIAN（Banking Industry Architecture Network）定义了约300个服务域（Service Domain），覆盖银行所有业务能力。核心银行涉及的关键服务域：

BIAN核心银行相关服务域映射：

├── 产品管理
│   ├── Product Directory（产品目录）
│   ├── Product Design（产品设计）
│   └── Product Deployment（产品部署）
│
├── 账户管理
│   ├── Current Account（活期账户）
│   ├── Savings Account（储蓄账户）
│   ├── Deposit Account（存款账户）
│   ├── Loan（贷款）
│   └── Credit Card（信用卡）
│
├── 支付与清算
│   ├── Payment Execution（支付执行）
│   ├── Payment Order（支付指令）
│   ├── Clearing（清算）
│   └── Settlement（结算）
│
├── 财务与记账
│   ├── Financial Accounting（财务记账）
│   ├── General Ledger（总账）
│   └── Position Management（头寸管理）
│
└── 客户管理
    ├── Party（参与方）
    ├── Customer Profile（客户画像）
    └── Customer Agreement（客户协议）

BIAN的价值：不是告诉你怎么实现，而是提供一个银行业务能力的"公共语言"——当你说"Current Account"时，全球银行架构师都知道你在说什么，包含哪些能力（开户、存款、取款、转账、查询、冻结等）。

---

对比分析

主流核心银行产品对比

核心银行vs DeFi协议栈

---

架构设计实操

实操：画核心银行系统C4架构全景图（含BIAN映射）

设计目标：为一家新设立的数字银行设计核心银行系统的C4 Context和Container级架构图，要求云原生部署、7x24运行、支持开放银行。

C4 Context级：

graph TB
    subgraph "External Systems"
        PBOC[央行支付系统<br/>CNAPS/CIPS]
        CREDIT[征信系统]
        UNION[银联/网联]
        TP[第三方合作方]
        REG[监管报送]
    end

    subgraph "Users"
        RETAIL[个人客户]
        CORP[企业客户]
        STAFF[银行员工]
        DEV[第三方开发者]
    end

    CBS[核心银行系统<br/>Digital Core Banking<br/>处理所有金融产品的<br/>账户、交易、记账]

    RETAIL -->|手机银行/网银| CBS
    CORP -->|企业网银/API| CBS
    STAFF -->|柜面/管理后台| CBS
    DEV -->|开放银行API| CBS

    CBS -->|支付清算| PBOC
    CBS -->|征信查询/报送| CREDIT
    CBS -->|银行卡交易| UNION
    CBS -->|业务合作| TP
    CBS -->|合规报送| REG

C4 Container级（含BIAN映射）：

graph TB
    subgraph "渠道容器"
        MOBILE["移动银行 App<br/>[Container: Flutter]"]
        WEB["网上银行<br/>[Container: React]"]
        OPENAPI["开放银行API<br/>[Container: Spring Gateway]<br/>BIAN: Open Banking"]
    end

    subgraph "核心业务容器"
        DEP["存款服务<br/>[Container: Java/Spring]<br/>BIAN: Current Account,<br/>Savings Account"]
        LOAN["贷款服务<br/>[Container: Java/Spring]<br/>BIAN: Loan, Credit Facility"]
        PAY["支付服务<br/>[Container: Java/Spring]<br/>BIAN: Payment Execution,<br/>Payment Order"]
        ACCT["账务引擎<br/>[Container: Java/Spring]<br/>BIAN: Financial Accounting,<br/>General Ledger"]
        PROD["产品工厂<br/>[Container: Java/Spring]<br/>BIAN: Product Directory,<br/>Product Design"]
        CUST["客户中心<br/>[Container: Java/Spring]<br/>BIAN: Party,<br/>Customer Profile"]
    end

    subgraph "基础设施容器"
        DB[("分布式数据库<br/>[OceanBase/TiDB]")]
        MQ["消息队列<br/>[Kafka]"]
        CACHE["分布式缓存<br/>[Redis Cluster]"]
        BATCH["批处理引擎<br/>[自研/XXL-Job]"]
    end

    MOBILE & WEB & OPENAPI --> DEP & LOAN & PAY
    DEP & LOAN & PAY --> ACCT
    ACCT --> DB
    DEP & LOAN & PAY --> MQ & CACHE
    BATCH --> DB

ADR（Architecture Decision Record）：

# ADR-031: 核心银行采用"厚核心+薄渠道"架构

## 状态：已接受

## 背景
新数字银行需要决定核心银行的架构分层策略。有两种主流方案：
- 方案A：厚核心（业务逻辑集中在核心层）
- 方案B：薄核心（核心只做记账，业务逻辑上移到服务层）

## 决策
采用方案A"厚核心"，业务规则（计息、还款、费用计算）内聚在核心层。

## 理由
1. 金融业务规则与账务操作紧密耦合，分离会引入分布式事务
2. 核心层的一致性保证更强
3. 监管审计要求业务逻辑可追溯，集中管理更便于合规
4. 参考业界实践：Thought Machine Vault将产品逻辑用Smart Contract定义在核心层内

## 权衡
- 牺牲：核心层更重，变更周期可能更长
- 缓解：通过产品工厂（参数化配置+DSL）提供灵活性，避免硬编码
- 牺牲：渠道层无法独立测试业务逻辑
- 缓解：核心层提供沙盒环境，支持渠道层集成测试

---

AI增强实践

1. AI辅助核心银行架构评估

场景：评估一个传统核心银行系统的现代化方案

Prompt示例：

你是一位资深银行架构师，正在评估一家城商行的核心银行现代化方案。

当前状态：
- 核心系统：某国产厂商2015年上线的Java+Oracle方案
- 日交易量：50万笔
- 账户数：800万
- 日切窗口：4小时（22:00-02:00）
- 主要痛点：产品上线周期3个月、日切经常超时、无法支持开放银行

目标：
- 2年内完成核心现代化
- 支持7x24运行
- 产品上线周期缩短到1周
- 支持开放银行API

请从以下维度给出架构建议：
1. 渐进式迁移 vs 大爆炸替换的选择
2. 数据库选型（Oracle续用/迁移OceanBase/TiDB）
3. 日切改造方案
4. 风险评估和缓解措施

2. AI辅助BIAN服务域映射

场景：将银行现有系统功能映射到BIAN服务域

Prompt示例：

请将以下银行系统功能清单映射到BIAN v12服务域：

1. 开户、销户、冻结/解冻
2. 存款、取款、转账
3. 贷款申请、审批、放款、还款
4. 利息计算、费用收取
5. 信用卡授权、记账、对账
6. 报表生成、监管报送

对每个映射，请说明：
- 对应的BIAN Service Domain名称
- 该Service Domain的核心Control Record
- 可能的行为限定词(Behavior Qualifier)

3. 人机边界

---

与Web3/DeFi的关联

深度洞察：DeFi本质上是在用智能合约重建核心银行的每一个子系统——Aave是存贷核心、Uniswap是外汇/交易核心、MakerDAO是央行+记账引擎。但DeFi缺少的是：信用贷款能力（因为无身份）、监管合规层、以及面向普通用户的渠道层体验。这正是RWA和嵌入式金融的机会所在。

---

今日思考

1. 如果你从零设计一个核心银行系统，你会选择"日切"模式还是"无日切"模式？如果选择无日切，如何保证利息计算、总分核对等传统日终任务的正确性？

2. BIAN定义了约300个服务域，但实际项目中很少有银行完整采用。BIAN的真正价值是什么？在什么场景下ROI最高（如并购整合、核心替换、供应商评估）？

3. DeFi的"Code is Law"消除了核心银行中大量的运营流程（对账、日切、差错处理），但引入了新的风险（智能合约漏洞、预言机故障）。如果你要设计一个CeFi-DeFi混合架构，核心银行系统需要做哪些改造？

---

面试题准备

Q1: 核心银行系统最核心的质量属性是什么？为什么？

30秒版本： 核心银行最核心的质量属性是数据一致性（Consistency），其次是可用性（Availability）和可审计性（Auditability）。银行系统"账不能错"是底线——任何架构决策都不能以牺牲账务一致性为代价。

2分钟版本：

核心银行的质量属性优先级是：一致性 > 可用性 > 可审计性 > 性能 > 可扩展性。

一致性为什么第一：银行是"管钱"的，每一分钱都必须有去处。复式记账的"借贷必相等"是不可妥协的硬约束。一旦出现一致性问题（比如转账扣款成功但入账失败），不仅是技术故障，还涉及法律责任和监管处罚。

可用性为什么第二：ATM取不了钱、手机银行登不上，直接影响客户信任和品牌。监管也有明确要求（如银保监会对关键系统可用性要求99.99%）。但在一致性和可用性冲突时，银行会选择"暂停服务"而非"给出错误数据"——这是金融系统和互联网系统的本质区别。

可审计性为什么第三：金融监管要求所有交易可追溯、可回放。这影响了数据模型设计（不允许物理删除、必须保留完整历史）、系统架构（完整的操作日志链）、以及发布策略（变更必须有审批记录）。

架构影响：这个优先级直接决定了核心银行偏向CP（一致性+分区容忍）而非AP（可用性+分区容忍），这就是为什么银行长期依赖关系型数据库而非NoSQL。

追问准备：

• 追问：那互联网银行（如微众银行）如何平衡一致性和高并发？ → 采用分布式数据库（TiDB/OceanBase）提供强一致性+水平扩展；用TCC/Saga保证跨服务事务；"最终一致"只用于非关键路径（如通知、营销）
• 追问：CAP定理在核心银行中怎么应用？ → 核心账务系统选CP，渠道查询系统可选AP（用缓存提供最终一致读）

Q2: 核心银行现代化的最大挑战是什么？

30秒版本： 最大挑战不是技术，而是数据迁移和业务连续性。核心银行承载了银行几十年的账务数据和业务规则，"在飞行中换引擎"需要零停机迁移数亿账户数据，同时保证迁移前后业务逻辑完全一致。

2分钟版本：

核心银行现代化有三大挑战：

第一，数据迁移的完整性和正确性。银行核心系统通常运行10-20年，积累了海量历史数据和隐式业务规则。迁移时不仅要搬数据，还要确保新系统能正确处理所有历史场景（如10年前的老产品利率规则、已下架但仍有存量的产品合约）。

第二，业务连续性保证。银行不能"停业装修"，必须在系统持续运行的同时完成切换。常用策略是"绞杀者模式"（Strangler Fig）：新老系统并行运行，按产品/客群逐步切换，但这意味着要维护两套系统的同步和一致性。

第三，隐式知识的显性化。老系统中大量业务逻辑是通过COBOL代码、存储过程、甚至运维人员的操作习惯（"每月5号手动跑这个脚本"）实现的。这些隐式知识如果遗漏，新系统就会出"诡异"的bug。

追问准备：

• 追问：你会推荐Big Bang还是渐进迁移？ → 几乎所有成功案例都是渐进迁移。Big Bang风险太高，一旦失败无法回滚。推荐按"低风险产品→高风险产品"、"新客户→存量客户"的顺序逐步切换
• 追问：AI能在核心银行现代化中发挥什么作用？ → AI可以辅助：1)分析遗留代码提取业务规则；2)自动化回归测试生成；3)数据迁移的异常检测；4)并行运行期间的差异比对

---

学习资源

1. 《Modernizing Core Banking》 by ThoughtWorks — 核心银行现代化实践指南
2. BIAN官方文档 (bian.org) — 银行业架构网络标准
3. Thought Machine Vault技术博客 — 云原生核心银行的先锋实践
4. 蚂蚁金融科技开放平台技术文档 — 国内互联网核心银行实践
5. 《银行信息系统架构》张健 — 国内银行IT架构经典教材
6. Celent/Gartner核心银行报告 — 全球核心银行产品评估

---

明日预告

Day 32: 账户体系设计 — 深入核心银行最基础的数据模型。我们将探讨科目体系（Chart of Accounts）、多级账户模型、内部户设计、账户参数化（产品→合约→账户三层模型）、虚拟账户等高级话题。这是理解所有金融业务的基石。