Arch Day 44: 核心银行系统总结 — 14天知识图谱与架构设计文档
这是核心银行系统子模块(Day 31-44)的收官总结——将14天的学习内容整合为一份可实操的核心银行架构设计文档，包含知识图谱、技术选型指南、演进路线图、与DeFi的架构映射，以及精选的面试题Top 10。目标是从"学过了"升级到"能用了"。
日期: 2026-05-13 (Day 44) 阶段: 第二阶段 - 金融域深度 标签: #核心银行 #总结 #知识图谱 #架构设计 #技术选型 #演进路线 #DeFi映射 #面试精选
核心概念
一句话定义
这是核心银行系统子模块(Day 31-44)的收官总结——将14天的学习内容整合为一份可实操的核心银行架构设计文档，包含知识图谱、技术选型指南、演进路线图、与DeFi的架构映射，以及精选的面试题Top 10。目标是从"学过了"升级到"能用了"。
14天回顾
Day 31-44: 核心银行系统深度学习
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Week 5 (Day 31-37): 核心银行基础
├── Day 31: 核心银行架构概述(什么是核心银行/演进历程)
├── Day 32: 账户与记账系统(复式记账/科目体系/账务引擎)
├── Day 33: 存款系统(产品参数化/计息引擎/日切)
├── Day 34: 贷款系统(审批流/还款计划/五级分类)
├── Day 35: 支付与清结算(支付路由/清结算流程/对账)
├── Day 36: 风控与反洗钱(规则引擎/实时风控/AML)
└── Day 37: 渠道与开放银行(全渠道架构/Open Banking API)
Week 6 (Day 38-44): 核心银行进阶
├── Day 38: 核心银行系统选型(Build vs Buy/产品对比/迁移策略) ✅
├── Day 39: 日终批处理架构(DAG编排/容错/性能优化) ✅
├── Day 40: 金融系统数据库设计(分库分表/NewSQL/审计) ✅
├── Day 41: 金融级高可用设计(两地三中心/异地多活/混沌工程) ✅
├── Day 42: 案例:Thought Machine Vault(不可变分类账/Smart Contract) ✅
├── Day 43: 案例:微众银行(单元化/TDSQL/成本优势) ✅
└── Day 44: 核心银行系统总结(本文) ✅
知识点详解
知识点1：核心银行知识图谱
核心银行系统知识图谱
━━━━━━━━━━━━━━━━━━━
┌──────────────┐
│ 核心银行系统 │
└──────┬───────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│业务领域 │ │技术架构 │ │工程实践 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
┌─────┼─────┐ ┌──────┼──────┐ ┌─────┼─────┐
│ │ │ │ │ │ │ │ │
┌─▼─┐┌─▼─┐┌─▼─┐ ┌─▼─┐ ┌─▼─┐ ┌─▼─┐ ┌─▼─┐┌─▼─┐┌─▼─┐
│存款││贷款││支付│ │数据││高可用││安全│ │选型││批处理││案例│
│系统││系统││清算│ │库 ││设计 ││合规│ │迁移││编排 ││分析│
└─┬─┘└─┬─┘└─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘└─┬─┘└─┬─┘
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │
计息 审批 路由 分库 两地 审计 Build DAG TM
引擎 流引 对账 分表 三中 追踪 vsBuy 容错 Vault
产品 擎 清结 NewSQL 心 加密 TCO 性能 微众
参数 五级 算 归档 异地 脱敏 矩阵 优化 银行
化 分类 消息 多活
驱动 混沌
工程
知识点2：核心银行架构设计完整文档
核心银行架构设计文档(综合版)
━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 架构愿景与原则
━━━━━━━━━━━━━━━━
愿景: 构建可扩展、高可用、低成本的下一代核心银行系统
架构原则:
├── P1: 业务连续性优先 — RPO=0, RTO<15min
├── P2: 数据一致性不妥协 — 资金交易强一致，查询可弱一致
├── P3: 水平可扩展 — 通过单元化实现线性扩展
├── P4: 松耦合 — 微服务+事件驱动，服务间通过API/消息通信
├── P5: 可审计 — 所有操作可追溯，数据不可篡改
├── P6: 信创优先 — 优先选择国产化技术栈
└── P7: AI就绪 — 架构支持AI能力嵌入
2. 系统架构(C4 Context)
━━━━━━━━━━━━━━━━━━━━━━
外部系统:
├── 人行支付系统(大额/小额/网联)
├── 银联(卡支付/云闪付)
├── 央行征信系统
├── 监管报送系统(1104/反洗钱)
├── 第三方数据(工商/法院/社保)
└── 合作方(渠道/场景/助贷)
核心银行(内部):
├── 账户管理服务
├── 存款产品服务
├── 贷款产品服务
├── 支付清算服务
├── 风控决策服务
├── 记账引擎
├── 计息引擎
├── 渠道接入层
├── 开放银行API
├── 批处理引擎
├── 监管报表服务
├── 数据分析平台
└── AI中台
3. 分层架构
━━━━━━━━━━
Layer 1: 渠道接入层
├── 手机银行/网银/小程序
├── 开放银行API Gateway
├── 合作方接入SDK
└── 内部管理后台
Layer 2: 业务服务层(微服务)
├── 客户域: 客户管理/KYC/认证
├── 账户域: 开销户/冻结解冻/账户查询
├── 存款域: 活期/定期/通知/结构化存款
├── 贷款域: 申请/审批/放款/还款/催收
├── 支付域: 转账/汇款/代收代付/跨境
├── 理财域: 产品管理/申购赎回/收益计算
└── 风控域: 准入/交易/催收/反洗钱
Layer 3: 核心引擎层
├── 记账引擎(复式记账/总分核对)
├── 计息引擎(积数计息/阶梯利率)
├── 产品引擎(参数化配置/Smart Contract)
├── 规则引擎(Drools/自研)
├── 工作流引擎(Camunda/自研)
└── 批处理引擎(Spring Batch+DAG)
Layer 4: 数据层
├── 在线数据库: OceanBase(核心账务)
├── 分析数据库: TiDB(HTAP查询)
├── 缓存: Redis Cluster
├── 消息: RocketMQ
├── 搜索: Elasticsearch
├── 文件: MinIO(对象存储)
└── 归档: 冷数据存储
Layer 5: 基础设施层
├── 容器平台: Kubernetes
├── 服务网格: Istio
├── 监控: Prometheus+Grafana
├── 日志: ELK Stack
├── 链路追踪: Jaeger
└── CI/CD: GitLab CI + ArgoCD
4. 数据架构
━━━━━━━━━━
分库策略:
├── 第一级(垂直): 按业务域分库(存款/贷款/支付/风控)
├── 第二级(水平): 按account_id Hash分表(128片)
└── 第三级(时间): 交易流水按月分区
数据同步:
├── 在线→分析: CDC(Debezium) → Kafka → TiDB
├── 在线→缓存: 双写+消息同步
├── 在线→归档: 定时迁移(热→温→冷)
└── 跨中心: OceanBase Paxos同步
数据治理:
├── 数据分类分级(个人金融信息三级标准)
├── 敏感数据加密(TDE+列级加密)
├── 数据脱敏(动态脱敏/静态脱敏)
├── 审计日志(append-only, 不可篡改)
└── 数据生命周期(15年保存+合规销毁)
5. 高可用架构
━━━━━━━━━━━━
部署架构: 两地三中心+同城双活
├── DC-1(城市A): Active, 50%流量
├── DC-2(城市A): Active, 50%流量
├── DC-3(城市B): Warm Standby
数据复制:
├── DC-1 ↔ DC-2: OceanBase Paxos同步(RPO=0)
├── DC-1/2 → DC-3: 异步复制(RPO≈0, 秒级)
└── 切换: 同城自动(<5min) + 异地半自动(<15min)
容灾演练:
├── 桌面演练: 每月
├── 功能演练: 每季度
├── 全流程演练: 每半年
└── 监管演练: 每年
知识点3：核心银行技术栈选型指南
| 技术领域 | 推荐选型(信创优先) | 备选方案 | 选择理由 |
|---|---|---|---|
| 核心数据库 | OceanBase | TiDB / GaussDB | 金融级一致性、信创合规、TPC-C验证 |
| 分析数据库 | TiDB(HTAP) | ClickHouse / StarRocks | HTAP能力、MySQL兼容 |
| 缓存 | Redis Cluster | Tair(阿里) | 成熟稳定、生态丰富 |
| 消息队列 | RocketMQ | Kafka / Pulsar | 金融级可靠性、事务消息 |
| 微服务框架 | Spring Cloud Alibaba | Dubbo / gRPC | 生态最全、社区活跃 |
| 服务网格 | Istio | MOSN(蚂蚁) | 标准化、多云支持 |
| 容器平台 | Kubernetes | OpenShift | 行业标准 |
| API网关 | Apache APISIX | Kong / Spring Cloud Gateway | 国产开源、高性能 |
| 工作流 | Camunda | Flowable / 自研 | 功能全面、BPMN标准 |
| 规则引擎 | Drools | Easy Rules / 自研 | 成熟稳定 |
| 批处理 | Spring Batch | 自研 | 生态成熟、容错完善 |
| 调度 | DolphinScheduler | XXL-Job | 国产开源、DAG编排强 |
| 监控 | Prometheus+Grafana | Zabbix | 云原生标准 |
| 日志 | ELK | Loki | 生态最全 |
| 链路追踪 | SkyWalking | Jaeger | 国产开源、Java生态优 |
| CI/CD | GitLab CI + ArgoCD | Jenkins + Flux | GitOps标准 |
知识点4：核心银行演进路线图
核心银行架构演进路线图
━━━━━━━━━━━━━━━━━━━━━
第一代: 遗留系统 (1970-2000)
├── 大型机(Mainframe)
├── COBOL/RPG程序
├── 文件系统/层次数据库
├── 批处理为主
├── 特征: 稳定但封闭、昂贵、人才断层
└── 代表: IBM z/OS, AS/400
│ 驱动力: 互联网兴起/成本压力
▼
第二代: 分布式改造 (2000-2015)
├── 从大型机迁移到x86
├── Java/SOA/Oracle
├── 分库分表/读写分离
├── 渠道服务化
├── 特征: 性能提升、成本下降、但架构复杂度上升
└── 代表: Temenos T24, TCS BaNCS
│ 驱动力: 云计算/数字银行/信创
▼
第三代: 云原生 (2015-2025)
├── 微服务/容器/Kubernetes
├── 分布式数据库(OceanBase/TiDB)
├── 事件驱动/CQRS
├── DevOps/CI/CD
├── 特征: 弹性扩展、快速迭代、但运维复杂度高
└── 代表: Thought Machine Vault, 微众银行
│ 驱动力: AI/开放银行/嵌入式金融
▼
第四代: Headless Banking (2025-未来)
├── 核心能力API化(Banking-as-a-Service)
├── AI-native(AI嵌入每个环节)
├── 产品引擎代码化(Smart Contract)
├── 实时处理(无日终批处理)
├── 与DeFi互操作(链上链下混合)
├── 特征: 极致灵活、AI驱动、开放组合
└── 代表: 概念阶段，部分产品已出现(Pismo/Vault)
演进不是"推倒重来":
├── 大型银行: 3-5年从第二代到第三代(渐进式)
├── 中型银行: 2-3年(可以跳过一些中间步骤)
├── 新设银行: 直接从第三代或第四代开始
└── 关键: 每次演进都要保证业务连续性
知识点5：核心银行 vs DeFi协议的架构映射
完整的架构映射表
━━━━━━━━━━━━━━━
核心银行组件 DeFi等价物 差异
───────────── ────────── ────
账户(Account) → 地址(Address) 银行账户有KYC，地址匿名
余额(Balance) → Token Balance 银行余额在数据库，链上在State Trie
复式记账 → 双向Transfer 原理相同(借方=贷方)
科目体系 → Token Standard 银行科目复杂，DeFi用ERC标准
交易(Transaction) → 链上Transaction 银行可撤销，链上不可逆
记账引擎 → EVM执行 银行中心化引擎，DeFi去中心化虚拟机
产品参数化 → Smart Contract参数 银行用配置表，DeFi用合约参数
计息引擎 → Lending Protocol利率模型 银行按日计息，DeFi按区块累积
支付路由 → DEX Aggregator路由 银行走支付网络，DeFi走流动性池
清结算 → 原子结算(Atomic Settlement) 银行T+1，DeFi即时
对账 → 不需要(区块链=唯一真相源) 银行需要对账，DeFi天然一致
日终批处理 → 不需要(实时处理) 银行批量，DeFi逐笔
风控(审批) → 抵押率检查/清算Bot 银行人+AI审批，DeFi自动化
监管报表 → The Graph/Dune查询 银行定期报送，DeFi实时可查
审计追踪 → 区块链不可篡改记录 银行需要额外建设，区块链天然
高可用(两地三中心) → 全球节点分布式 银行精心设计，区块链天然
数据库(OceanBase) → 区块链状态数据库 银行用关系型，链上用Patricia Trie
消息队列 → Event Log 银行用MQ，链上用合约事件
核心银行完全没有的DeFi概念:
├── 可组合性(Composability): DeFi协议像乐高可以任意组合
├── 无许可(Permissionless): 任何人可以使用，无需银行审批
├── 不可变性(Immutability): 部署的合约不可修改(可升级除外)
├── 治理(Governance): 用户通过投票决定协议变更
└── 流动性挖矿(Yield Farming): 通过激励机制引导流动性
DeFi完全没有的核心银行概念:
├── KYC/AML: 身份验证和反洗钱(DeFi正在引入)
├── 信贷审批: 无抵押贷款需要信用评估(DeFi只有超额抵押)
├── 日终批处理: 会计日切/监管报表(链上不需要)
├── 线下渠道: 网点/ATM(DeFi纯线上)
└── 人工干预: 人工审批/差错处理(DeFi自动化)
知识点6：14天面试题精选Top 10
Top 10 核心银行面试题
━━━━━━━━━━━━━━━━━━━━
Q1: 如果从零设计一个数字银行核心系统，你的架构方案是什么？
30秒版本： 我会采用四层架构：渠道接入层(API Gateway+BFF)、业务服务层(DDD微服务按存款/贷款/支付域划分)、核心引擎层(记账引擎+计息引擎+产品引擎)、数据层(OceanBase+Redis+RocketMQ)。部署采用两地三中心+同城双活，数据库用OceanBase Paxos三副本。关键设计决策：单元化架构支持水平扩展，产品引擎参数化支持快速上线新产品。
2分钟版本： 设计一个数字银行核心系统，我会从以下五个维度展开：
业务架构：按DDD划分限界上下文——客户域、账户域、存款域、贷款域、支付域、风控域。每个域是一个或多个微服务，通过API和事件通信。核心原则是每个域内强一致，域间最终一致。
数据架构：核心账务用OceanBase（金融级一致性+信创合规），分析查询用TiDB（HTAP能力），缓存用Redis，消息用RocketMQ。按account_id做水平分片（128片），交易流水按月分区。
高可用架构：两地三中心+同城双活。OceanBase Paxos三副本（同城两副本+异地一副本），同城RPO=0，异地RPO≈0。灾备切换采用半自动策略。
产品引擎：参数化+规则引擎的混合方案。标准产品（如活期存款）用参数配置，复杂产品（如结构化存款）用规则引擎或类Smart Contract的代码化方式。
运维体系：Kubernetes容器化部署，GitOps流程（ArgoCD），全链路监控（Prometheus+SkyWalking），混沌工程验证（每季度演练）。
Q2: 复式记账的核心原则是什么？为什么金融系统必须用复式记账？
30秒版本： 复式记账的核心原则是"有借必有贷，借贷必相等"——每笔交易至少涉及两个科目，借方和贷方金额相等。金融系统必须用复式记账因为：(1)天然对账——借方总额=贷方总额，不平说明有错；(2)资金流向可追踪——每一分钱的来龙去脉都有记录；(3)监管要求——银行监管报表基于复式记账体系。
Q3: 自研vs购买核心银行如何决策？
（完整答案见Day 38）
Q4: 如何设计不影响在线交易的日终批处理？
（完整答案见Day 39）
Q5: 金融系统分库分表的分片键如何选择？
（完整答案见Day 40）
Q6: 异地多活在金融系统的最大挑战是什么？
（完整答案见Day 41）
Q7: Thought Machine的架构创新在哪里？
（完整答案见Day 42）
Q8: 微众银行单元化架构如何实现？
（完整答案见Day 43）
Q9: 核心银行系统的日终计息引擎如何设计？
30秒版本： 计息引擎的核心是积数计息法——利息=积数×日利率，积数=每日余额×天数之和。设计要点：(1)白天实时维护积数（每笔交易更新），日终只做最后的乘法运算（减少80%计算量）；(2)分片并行处理（按账户分片，50个Worker并行）；(3)阶梯利率支持（不同余额档位不同利率）；(4)多币种处理（不同币种计息基准不同，360/365/实际天数）；(5)精度控制（小数点后保留到分，尾差处理规则明确）。
Q10: 核心银行与DeFi协议在架构上的核心差异是什么？
30秒版本： 核心差异在三个方面：(1)信任模型——银行是中心化信任(银行保证资金安全)，DeFi是去中心化信任(代码和数学保证)；(2)结算方式——银行T+1批量清结算(需要对账)，DeFi交易即结算(无需对账)；(3)产品灵活性——银行产品需要合规审批(慢但安全)，DeFi产品可自由组合(快但风险高)。未来趋势是两者在技术上趋同(不可变分类账/智能合约)，但在治理和合规模式上保持差异。
对比分析
14天学习内容关联矩阵
| 主题 | 与选型的关系 | 与批处理的关系 | 与数据库的关系 | 与高可用的关系 |
|---|---|---|---|---|
| 选型(D38) | - | 选型影响批处理架构 | 选型决定数据库 | 选型包含HA需求 |
| 批处理(D39) | 不同产品批处理能力不同 | - | 批处理性能依赖数据库 | 批处理窗口影响HA |
| 数据库(D40) | 数据库是选型核心维度 | 数据库架构决定批处理方式 | - | 数据库是HA的基础 |
| 高可用(D41) | HA需求是选型权重最高项 | 批处理容错是HA的一部分 | 数据库HA是系统HA基础 | - |
| TM Vault(D42) | Vault是选型候选 | Vault用Smart Contract替代批处理 | Vault用不可变分类账 | Vault的K8s HA |
| 微众(D43) | 微众是自研案例 | 微众用单元化优化批处理 | 微众用TDSQL | 微众的两地三中心 |
核心银行架构决策清单
| 决策项 | 选项A | 选项B | 推荐 | 依据 |
|---|---|---|---|---|
| Build vs Buy | 自研 | 外购 | 视银行类型 | 大行自研，中小行外购 |
| 数据库 | 分库分表 | NewSQL | NewSQL | 长期运维成本更低 |
| 记账模型 | 可变状态 | 不可变分类账 | 不可变 | 审计追踪+一致性 |
| 产品引擎 | 参数配置 | Smart Contract | 混合 | 标准产品配置+复杂产品代码 |
| 批处理 | 集中式 | 分布式 | 分布式 | 性能+容错 |
| 高可用 | 两地三中心 | 异地多活 | 两地三中心先 | 复杂度可控 |
| 微服务粒度 | 粗粒度 | 细粒度 | 中等 | 平衡复杂度和灵活性 |
| 事务模型 | 强一致 | 最终一致 | 混合 | 资金强一致，查询弱一致 |
架构设计实操
完整核心银行架构设计文档目录
核心银行架构设计文档
━━━━━━━━━━━━━━━━━━
1. 架构愿景与原则 (Day 31)
├── 1.1 业务目标
├── 1.2 架构原则(7条)
└── 1.3 约束条件
2. 领域模型 (Day 32-36)
├── 2.1 限界上下文划分
├── 2.2 核心域: 账户/记账
├── 2.3 支撑域: 存款/贷款/支付
├── 2.4 通用域: 风控/客户/渠道
└── 2.5 上下文映射(Context Map)
3. 系统架构 (Day 37-38)
├── 3.1 C4 Context图
├── 3.2 C4 Container图
├── 3.3 C4 Component图(核心服务)
└── 3.4 技术栈选型
4. 数据架构 (Day 40)
├── 4.1 数据库选型(OceanBase+TiDB)
├── 4.2 分库分表策略
├── 4.3 数据同步方案
├── 4.4 数据归档策略
└── 4.5 审计与合规
5. 高可用架构 (Day 41)
├── 5.1 两地三中心部署
├── 5.2 数据复制策略
├── 5.3 灾备切换流程
├── 5.4 演练计划
└── 5.5 监控告警
6. 批处理架构 (Day 39)
├── 6.1 日终批处理DAG
├── 6.2 容错设计
├── 6.3 性能优化
└── 6.4 监控与告警
7. 安全架构 (Day 36)
├── 7.1 数据加密
├── 7.2 访问控制
├── 7.3 审计日志
└── 7.4 合规要求
8. ADR记录
├── ADR-031: 核心银行架构风格选择
├── ADR-032: 记账引擎设计
├── ADR-038: 核心银行选型决策
├── ADR-039: 批处理架构选型
├── ADR-040: 数据库选型决策
├── ADR-041: 高可用架构决策
└── ...
9. 案例分析
├── 案例1: 蚂蚁金服架构演进 (Day 28)
├── 案例2: Stripe支付架构 (Day 29)
├── 案例3: Thought Machine Vault (Day 42)
└── 案例4: 微众银行分布式架构 (Day 43)
核心银行演进路线图(针对中型银行)
中型银行核心银行演进路线图(3年规划)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Year 1 H1: 基础设施现代化
├── 容器化(K8s)部署核心系统
├── 数据库从Oracle迁移到OceanBase(分批)
├── 建设CI/CD流水线
├── 建设全链路监控平台
└── 里程碑: 第一个业务域上线K8s
Year 1 H2: 核心服务拆分
├── 渠道层与核心层解耦(API Gateway)
├── 支付服务独立(优先级最高)
├── 开放银行API上线
├── 批处理优化(分布式Spring Batch)
└── 里程碑: 支付服务独立运行
Year 2 H1: 单元化改造
├── 按业务域垂直分库(存款/贷款/支付)
├── 核心账务单元化(按account_id分片)
├── 跨单元消息通信建设
├── 同城双活改造
└── 里程碑: 单元化架构上线(灰度)
Year 2 H2: 产品引擎现代化
├── 新产品引擎(参数化+规则引擎)
├── 新产品在新引擎上线
├── AI风控模型上线
├── 数据中台建设(实时+离线)
└── 里程碑: 新产品上线时间从月到周
Year 3 H1: 存量迁移
├── 存量存款产品迁移到新引擎
├── 存量贷款产品迁移
├── 旧核心系统逐步退役
├── AI能力深化(智能客服/智能运维)
└── 里程碑: 50%+业务运行在新架构
Year 3 H2: 全面云原生
├── 完成存量迁移
├── 旧系统退役
├── 混沌工程常态化
├── 信创合规验收
└── 里程碑: 核心银行全面云原生化
AI增强实践
AI在核心银行全生命周期中的应用
AI增强核心银行系统全景
━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────┐
│ AI中台 │
│ ┌────┐┌────┐┌────┐┌────┐ │
│ │NLP ││CV ││ML ││LLM │ │
│ └──┬─┘└──┬─┘└──┬─┘└──┬─┘ │
└────┼─────┼─────┼─────┼───┘
│ │ │ │
┌─────────────────────┼─────┼─────┼─────┼──────────────┐
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌──────┐ ┌──────┐┌──────┐┌──────┐ ┌──────┐
│客户 │ │风控 ││产品 ││运维 │ │合规 │
│智能 │ │智能 ││智能 ││智能 │ │智能 │
├──────┤ ├──────┤├──────┤├──────┤ ├──────┤
│智能客│ │实时反│ │AI定价││故障预│ │自动报│
│服 │ │欺诈 ││ ││测 │ │表生成│
│智能营│ │信用评│ │个性化││根因分│ │合规检│
│销 │ │估 ││推荐 ││析 │ │查 │
│人脸识│ │反洗钱│ │智能合││容量预│ │异常检│
│别 │ │ ││约 ││测 │ │测 │
└──────┘ └──────┘└──────┘└──────┘ └──────┘
AI能力成熟度路线:
├── Level 1: 辅助决策(AI推荐，人工决策)
│ └── 现阶段大多数银行在这里
├── Level 2: 自动决策(AI决策，人工监督)
│ └── 微众/蚂蚁的信贷审批
├── Level 3: 自主决策(AI全自动，极端情况人工介入)
│ └── 未来方向，监管仍在评估
└── Level 4: AI-native(AI驱动产品设计/运营/风控)
└── 概念阶段
与Web3/DeFi的关联
核心银行与DeFi协议的融合趋势
CeDeFi: 传统金融 × DeFi 的融合趋势
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
趋势1: 传统银行采用区块链技术
├── JP Morgan Onyx: 基于区块链的代币化资产平台
├── 渣打银行: 用区块链做贸易融资
├── 新加坡星展: 数字资产交易平台
└── 意义: 区块链成为核心银行的补充层(不是替代)
趋势2: DeFi协议引入合规框架
├── Aave Arc: 机构级DeFi池(需要KYC)
├── Compound Treasury: 合规的DeFi收益产品
├── Ondo Finance: RWA(真实资产代币化)
└── 意义: DeFi正在构建"合规层"，向传统金融靠拢
趋势3: Headless Banking + DeFi
├── 银行核心系统API化(BaaS)
├── DeFi协议集成银行API(如法币出入金)
├── 嵌入式金融(任何App都能提供金融服务)
└── 意义: 核心银行成为"后端"，前端可以是DeFi
趋势4: CBDC(央行数字货币)连接两者
├── 数字人民币(e-CNY)的技术架构
├── 欧洲数字欧元的设计
├── CBDC可以同时在传统银行和DeFi中流通
└── 意义: CBDC可能成为CeFi和DeFi的桥梁
未来架构愿景:
┌──────────────────────────────────────┐
│ 用户层(统一入口) │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │App │ │Web │ │DApp │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ └────────┼────────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 统一API Gateway │ │
│ └───────┬────────┘ │
│ ┌───────┼───────┐ │
│ ▼ ▼ ▼ │
│ ┌──────┐┌──────┐┌──────┐ │
│ │核心银│ │DeFi ││CBDC │ │
│ │行系统││协议 ││钱包 │ │
│ │(CeFi)││(DeFi) ││(CBDC) │ │
│ └──┬───┘└──┬───┘└──┬───┘ │
│ └────────┼────────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 结算层 │ │
│ │ (区块链/分类账) │ │
│ └────────────────┘ │
└──────────────────────────────────────┘
今日思考
深度问题1
"如果从零设计一个数字银行核心系统，你的架构方案是什么？"
（见面试题Q1的完整回答）
深度问题2
"14天学习中，哪个知识点对你的认知冲击最大？"
对我冲击最大的是Thought Machine的不可变分类账设计。它改变了我对"账户余额"的理解——余额不是一个需要维护的"状态"，而是所有交易事件的"衍生值"。这个思维转变让我理解了为什么区块链本质上是一个"账本"而不是一个"数据库"。同时也让我反思：传统系统中有多少"状态"其实可以被"事件流"替代？Event Sourcing不仅是一种架构模式，更是一种思维方式。
深度问题3
"核心银行架构的下一个十年会是什么样？"
我预测三个方向：(1)Headless Banking——核心银行能力完全API化，成为"后端即服务"，前端可以是任何应用(包括DeFi协议)；(2)AI-Native——AI不再是"加上去"的功能，而是架构的核心——AI驱动产品设计、AI驱动风控、AI驱动运维；(3)CeFi+DeFi互操作——通过CBDC和合规框架，传统银行核心系统和DeFi协议可以互相调用，形成"混合金融"生态。
面试题准备
面试题: 如果从零设计一个数字银行核心系统，你的架构方案是什么？
30秒版本： 四层架构+单元化+云原生。渠道层(API Gateway)、业务层(DDD微服务按域划分)、引擎层(记账+计息+产品引擎)、数据层(OceanBase+Redis+RocketMQ)。部署两地三中心+同城双活，OceanBase Paxos三副本。单元化架构支持水平扩展，产品引擎参数化+规则化支持快速创新，AI嵌入风控和运维。
2分钟版本： （见上文知识点2的完整架构设计文档）
可能的追问：
-
Q：为什么不选Thought Machine Vault？
-
A：如果是在中国市场，Vault缺乏本地化支持和监管经验；如果是海外市场且预算充足，Vault是很好的选择。核心是看组织能力和市场环境。
-
Q：3年后会不会过时？
-
A：架构设计本身不会过时，因为遵循了好的原则(松耦合/可扩展/事件驱动)。技术组件可能更新(如更好的数据库出现)，但架构的骨架可以保持10年。
-
Q：预算估算？
-
A：中型银行(500万客户)，三年总投资约5-8亿人民币(含人力+硬件+软件+咨询)，其中第一年最高(约2.5-3亿)。
学习资源
| 资源 | 类型 | 推荐理由 |
|---|---|---|
| 全部Day 31-43笔记 | 自己的笔记 | 复习巩固 |
| 《银行信息系统架构》陈绍英 | 书籍 | 中国银行IT架构最全面的参考 |
| Thought Machine技术博客 | 博客 | 下一代核心银行的设计理念 |
| 微众银行技术分享 | 技术文章 | 中国互联网银行架构实践 |
| BIAN (Banking Industry Architecture Network) | 标准 | 银行业架构标准参考 |
| DeFi协议文档(Aave/Uniswap) | 技术文档 | 对比理解DeFi与CeFi的差异 |
明日预告
Day 45: 支付系统架构(1) — 进入核心银行的下一个子模块：支付系统。支付是金融系统中交互最多、性能要求最高、合规最复杂的领域。我们将从支付的基本概念开始，深入探讨支付路由、清结算机制、跨境支付架构，以及支付系统如何与DeFi的原子结算对比。