Arch Day 43: 案例分析(4)：微众银行分布式核心架构 — 3亿客户背后的技术革命

日期: 2026-05-12 (Day 43) 阶段: 第二阶段 - 金融域深度 标签: #核心银行 #微众银行 #分布式架构 #单元化 #TDSQL #去IOE #互联网银行 #FISCO

---

核心概念

一句话定义

微众银行(WeBank)是中国首家互联网银行(2014年获批)，由腾讯牵头发起。其技术架构的核心创新在于完全基于分布式架构构建核心银行系统(无大型机、无Oracle、无EMC)，通过单元化(Unit-based)架构实现了每个账户的IT成本仅为传统银行的十分之一，支撑了3亿+零售客户和数千亿资产规模，是中国金融科技最成功的架构实践之一。

为什么资深架构师必须关注

常见误区与反模式

---

知识点详解

知识点1：微众银行背景与发展

微众银行发展时间线
━━━━━━━━━━━━━━━━

2014年12月: 获银监会批准开业
├── 中国首家互联网银行
├── 股东: 腾讯(30%) + 百业源(20%) + 立业集团(20%) + 其他
├── 定位: 服务小微企业和个人，无物理网点
└── 初始资本金: 30亿元

2015年: 首款产品上线
├── 微粒贷: 小额信用贷款(通过微信入口)
├── 日利率万分之五(年化约18%)
├── 首年放款: 数百亿
└── 技术: 全线上审批，秒级放款

2016-2018: 技术体系成型
├── 分布式核心系统全面投产
├── TDSQL分布式数据库大规模使用
├── 单元化架构落地
├── 微众智能风控系统
└── 客户数突破1亿

2019-2020: 开源与生态
├── FISCO BCOS区块链平台开源
├── WeIdentity去中心化身份开源
├── 微众银行科技能力对外输出
├── 资产突破3000亿
└── 客户数突破2亿

2021-2023: 规模化增长
├── 客户数突破3亿
├── 微粒贷累计放款超3万亿
├── 技术员工占比超过50%
├── AI全面融入业务流程
└── 每账户IT成本持续下降

2024-2026: 深化创新
├── AI Agent融入客服和风控
├── 联邦学习在隐私计算中大规模应用
├── FISCO BCOS 3.0发布(支持WASM)
└── 探索数字人民币(e-CNY)创新应用

知识点2：分布式核心架构——去IOE

传统银行 vs 微众银行 技术栈对比
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

传统银行(IOE架构):
├── I - IBM: 大型机(Mainframe)/小型机(AS400)
│   ├── 单机数百万TPMPC计算力
│   ├── 硬件成本: 数千万/台
│   └── 可靠性: 99.999%(五个9)
├── O - Oracle: 数据库
│   ├── RAC集群(最多4-8节点)
│   ├── License费: 数千万/年(大型银行)
│   └── 性能: 单机数万TPS
└── E - EMC: 存储
    ├── SAN存储(集中式)
    ├── 硬件成本: 数千万
    └── 扩展: 垂直扩展(加磁盘/加柜子)

总成本: 数亿级别/年(大型银行)
扩展方式: 垂直(买更大更贵的设备)
单点风险: 高(核心设备故障影响全局)


微众银行(分布式架构):
├── 计算: x86标准服务器(Dell/HP/浪潮)
│   ├── 每台服务器成本: 数万元
│   ├── 数千台服务器集群
│   └── 任意一台故障不影响服务
├── 数据库: TDSQL(腾讯分布式数据库)
│   ├── 基于MySQL改造，分布式事务
│   ├── 自研，无License费
│   └── 水平扩展(加节点)
├── 存储: 分布式存储(Ceph/自研)
│   ├── 多副本(3副本)
│   ├── 普通HDD/SSD
│   └── 水平扩展(加服务器)
├── 中间件: 全自研
│   ├── RocketMQ(消息队列)
│   ├── 自研RPC框架
│   ├── 自研配置中心
│   └── 自研注册中心
└── 运维: 自动化运维平台
    ├── 自动故障检测和恢复
    ├── 灰度发布
    └── 全链路监控

总成本: 传统银行的1/10
扩展方式: 水平(加服务器)
单点风险: 低(分布式容错)

成本对比详解：

知识点3：单元化(Unit-based)架构

微众银行单元化架构
━━━━━━━━━━━━━━━━━

核心思想: 将系统按用户维度分片，每个分片形成一个自治的"单元"

全局路由层 (DCN - Data Center Node)
├── 根据用户ID确定归属单元
├── 路由规则: unit_id = hash(user_id) % total_units
└── 所有请求先经过路由层

         ┌────────────────┐
         │  全局路由层(DCN) │
         │  user → unit   │
         └───┬────┬────┬──┘
             │    │    │
    ┌────────┤    │    ├────────┐
    ▼        ▼    ▼    ▼        ▼
┌───────┐┌───────┐┌───────┐┌───────┐
│Unit 0 ││Unit 1 ││Unit 2 ││Unit N │
│       ││       ││       ││       │
│┌─────┐││┌─────┐││┌─────┐││┌─────┐│
││App  │││ │App  ││││App  ││││App  ││
│├─────┤││├─────┤││├─────┤││├─────┤│
││Cache│││ │Cache││││Cache││││Cache││
│├─────┤││├─────┤││├─────┤││├─────┤│
││TDSQL│││ │TDSQL││││TDSQL││││TDSQL││
│└─────┘││└─────┘││└─────┘││└─────┘│
│       ││       ││       ││       │
│用户:  ││用户:  ││用户:  ││用户:  │
│0-N/4  ││N/4-N/2││N/2-3N/4││3N/4-N│
└───────┘└───────┘└───────┘└───────┘

每个单元包含:
├── 完整的应用服务(账户/交易/风控/...)
├── 独立的缓存(Redis)
├── 独立的数据库(TDSQL分片)
├── 独立的消息队列
└── 该单元用户的所有数据

单元化的核心特征:

1. 单元封闭性
   ├── 用户的所有操作在其归属单元内完成
   ├── 单元内操作 = 本地操作(无分布式事务)
   ├── 90%+的操作可以在单元内完成
   └── 目标: 最小化跨单元操作

2. 单元自治性
   ├── 每个单元独立部署、独立运维
   ├── 一个单元故障不影响其他单元
   ├── 可以对单个单元做灰度升级
   └── 故障影响 = 全部用户 / 单元数

3. 水平扩展
   ├── 增加用户 → 增加单元数
   ├── 新单元接收新用户
   ├── 旧单元可以分裂(split)
   └── 理论上可以无限扩展

4. 跨单元操作处理
   ├── 场景: Unit 0的用户A → Unit 1的用户B转账
   ├── 方案1: 路由到发起方单元，通过消息异步通知对方单元
   ├── 方案2: 分布式事务(TCC/Saga)
   ├── 实际: 微众使用异步消息+补偿的方式
   └── 保证: 最终一致性(不是强一致)

跨单元转账流程：

跨单元转账: Unit 0的A → Unit 2的B 转账1000元
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 1: 路由层识别跨单元操作
├── A的归属: Unit 0
├── B的归属: Unit 2
└── 判定: 跨单元转账

Step 2: Unit 0 (发起方处理)
├── 冻结A的1000元(本地事务)
├── 生成转账消息 → 消息队列
│   {from: A, to: B, amount: 1000, tx_id: "TX001"}
├── 记录半交易状态: PENDING
└── 返回客户: "转账处理中"

Step 3: 消息队列 → Unit 2 (接收方处理)
├── 收到转账消息
├── B账户入账1000元(本地事务)
├── 生成确认消息 → 消息队列
│   {tx_id: "TX001", status: "SUCCESS"}
└── B看到余额增加

Step 4: Unit 0 (确认处理)
├── 收到确认消息
├── A的冻结金额释放并扣减(本地事务)
├── 更新交易状态: COMPLETED
└── 通知客户: "转账成功"

异常处理:
├── Step 3失败: 重试N次 → 仍失败则回滚(解冻A的1000元)
├── 消息丢失: 定时对账发现未完成的交易 → 补偿
├── 超时: 超过5分钟未确认 → 自动回滚
└── 保证: 要么双方都成功，要么都不变(最终一致性)

知识点4：TDSQL分布式数据库

TDSQL架构
━━━━━━━━━

TDSQL = Tencent Distributed SQL

历史:
├── 源自腾讯游戏的数据库中间件
├── 基于MySQL/MariaDB引擎
├── 增加了分布式事务、强同步复制等金融级特性
├── 2017年在微众银行核心系统全面使用
└── 现在也作为腾讯云产品对外提供

架构:
    ┌──────────┐
    │  应用层   │
    └────┬─────┘
         │ SQL
    ┌────▼─────┐
    │ Proxy层  │  SQL路由/分片/事务协调
    │ (TDProxy)│
    └────┬─────┘
         │
    ┌────┼────┬────────┐
    ▼    ▼    ▼        ▼
  ┌────┐┌────┐┌────┐┌────┐
  │Set1││Set2││Set3││SetN│  数据分片
  │主从 ││主从 ││主从 ││主从 │
  └────┘└────┘└────┘└────┘

每个Set:
├── 1个Master + 2个Slave (强同步复制)
├── 使用MySQL/MariaDB引擎
├── 存储该分片的数据
└── Master故障时Slave自动升主

核心特性:
├── 分布式事务: 基于XA协议 + 2PC
├── 强同步复制: 写入必须等待Slave确认(RPO=0)
├── 自动分片: 按分片键自动路由
├── 在线DDL: 不停机的表结构变更
├── 全局唯一ID: 分布式ID生成器
└── MySQL兼容: 应用层几乎无需修改

TDSQL vs OceanBase vs TiDB:

| 维度 | TDSQL | OceanBase | TiDB |
|------|-------|-----------|------|
| 架构 | MySQL增强+Proxy分片 | 原生分布式(Paxos) | 原生分布式(Raft) |
| 引擎 | MySQL/MariaDB | 自研 | 自研(TiKV) |
| 兼容 | MySQL | MySQL/Oracle | MySQL |
| 事务 | XA + 2PC | Paxos + 2PC | Percolator |
| 部署 | 有Proxy层 | 无Proxy(计算存储分离) | 无Proxy(TiDB+TiKV) |
| 运维 | 需要管理Proxy+Set | 统一管理 | 统一管理 |
| 优势 | MySQL生态兼容好 | 性能极限高 | HTAP能力 |
| 劣势 | Proxy是单点/瓶颈 | 学习曲线高 | 对大事务支持弱 |

知识点5：成本优势的架构根因

为什么微众每账户IT成本只有传统银行的1/10？
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

原因1: 硬件成本 (约省5倍)
├── 传统: IBM大型机 + Oracle数据库 + EMC存储
│   └── 单套核心系统硬件: 数千万-上亿
├── 微众: x86标准服务器 + 开源数据库 + 分布式存储
│   └── 同等计算力的x86集群: 数百万
└── 关键: 用数量(廉价x86)换质量(昂贵大型机)

原因2: 软件License (约省10倍)
├── 传统: Oracle License约5万/CPU核/年
│   └── 大型银行核心: 数千核 → 数亿/年
├── 微众: MySQL/MariaDB(免费) + 自研中间件
│   └── 零License费
└── 代价: 需要自研能力(微众技术人员占50%+)

原因3: 单元化架构 (线性扩展)
├── 传统: 垂直扩展(容量×2 = 成本×3-4)
│   └── 大型机性能翻倍价格翻3-4倍
├── 微众: 水平扩展(容量×2 ≈ 成本×2)
│   └── 加服务器即可，线性成本
└── 关键: 单元化让水平扩展变得可行

原因4: 自动化运维 (约省2倍)
├── 传统: 人工运维为主
│   └── 大型银行运维团队: 200-500人
├── 微众: 高度自动化
│   └── 运维团队: 50-100人(管理数千台服务器)
└── 实现: 自研运维平台 + AI运维

原因5: 无物理网点
├── 传统: 数千个网点(租金/装修/设备/人员)
├── 微众: 纯线上(微信/APP入口)
└── 节省: 渠道成本几乎为零

综合成本模型:
┌─────────────────────────────────────────┐
│ 每账户年IT成本对比                       │
│                                         │
│ 传统大型银行:                            │
│ ├── 硬件折旧: 20元                      │
│ ├── 软件License: 30元                   │
│ ├── 运维人力: 15元                      │
│ ├── 网点分摊: 20元                      │
│ └── 合计: ~85元/账户/年                 │
│                                         │
│ 微众银行:                               │
│ ├── 硬件折旧: 1.5元                    │
│ ├── 软件License: ~0元                  │
│ ├── 运维人力: 1.5元                    │
│ ├── 网点分摊: 0元                      │
│ ├── 研发分摊: 0.6元                    │
│ └── 合计: ~3.6元/账户/年               │
│                                         │
│ 成本优势: 约23倍                        │
└─────────────────────────────────────────┘

知识点6：微众的开源贡献

微众银行开源项目矩阵
━━━━━━━━━━━━━━━━━━━━

1. FISCO BCOS (区块链)
   ├── 企业级联盟链平台
   ├── 由微众银行联合金链盟发起
   ├── 中国使用最广泛的联盟链之一
   ├── 应用: 供应链金融/存证/数字积分
   ├── 特点: 国产密码算法/高性能/易用
   └── GitHub Stars: 7000+

2. WeIdentity (去中心化身份)
   ├── 基于FISCO BCOS的DID方案
   ├── W3C DID标准兼容
   ├── 应用: KYC/信用证明/资质认证
   └── 与传统银行KYC的互补

3. WeDPR (隐私计算)
   ├── 零知识证明工具库
   ├── 联邦学习框架
   ├── 应用: 多方数据协作(不共享原始数据)
   └── 场景: 联合风控/反洗钱

4. EventMesh (事件网格)
   ├── 分布式事件驱动中间件
   ├── Apache孵化项目
   ├── 支持CloudEvents标准
   └── 微服务间异步通信

5. WeBankBlockchain (区块链中间件)
   ├── 数据导出/数据治理/密钥管理
   ├── 降低区块链应用开发门槛
   └── 配合FISCO BCOS使用

知识点7：与蚂蚁金服架构的对比

核心差异分析
━━━━━━━━━━━

1. 数据库选择
   微众: TDSQL (MySQL增强型)
   ├── 优势: MySQL生态成熟，DBA容易招
   ├── 劣势: Proxy层是潜在瓶颈
   └── 策略: 够用就好，不追求技术极致

   蚂蚁: OceanBase (原生分布式)
   ├── 优势: 性能极限高(TPC-C世界纪录)
   ├── 劣势: 学习曲线高，运维复杂
   └── 策略: 自研最优方案，追求技术边界

2. 异地容灾
   微众: 两地三中心(同城双活+异地灾备)
   ├── 够用: 满足监管要求
   ├── 简单: 架构复杂度可控
   └── 演进中: 逐步向异地多活演进

   蚂蚁: LDC异地多活
   ├── 极致: 三地五中心(杭州+上海+张北)
   ├── 复杂: 需要完整的单元化+数据同步体系
   └── 必要: 双11流量峰值要求资源最大化利用

3. 开源策略
   微众: 积极开源
   ├── FISCO BCOS成为行业标准联盟链
   ├── 开源建立生态，吸引人才
   └── 联盟链有政策鼓励

   蚂蚁: 选择性开源
   ├── 核心优势(OceanBase)开源是为了商业化
   ├── 部分组件(SOFAStack)开源建生态
   └── 核心业务逻辑不开源

---

对比分析

中国三大互联网银行架构对比

互联网银行 vs 传统银行架构差异

---

架构设计实操

实操：架构分析文章大纲

# 微众银行分布式核心架构: 如何用1/10的成本服务3亿客户

## 1. 为什么微众选择分布式架构？(300字)
- 互联网银行的先天优势: 没有历史包袱
- 成本压力: 服务小微客户必须极致降本
- 技术趋势: 去IOE+分布式+云原生

## 2. 核心架构设计 (800字)
### 2.1 单元化架构
- 用户分片 → 单元封闭 → 跨单元路由
- 与蚂蚁LDC的异同
- 单元化如何实现线性扩展

### 2.2 TDSQL分布式数据库
- MySQL增强 vs 原生分布式的选择
- 强同步复制保证金融级一致性
- Proxy层的角色和优化

### 2.3 异步消息驱动
- 跨单元操作的最终一致性保证
- 消息可靠性和幂等性
- 对账机制作为安全网

## 3. 成本优势的技术根因 (400字)
- 硬件: x86 vs 大型机
- 软件: 开源 vs License
- 架构: 水平扩展 vs 垂直扩展
- 运维: 自动化 vs 人工

## 4. 与蚂蚁金服架构的对比 (400字)
- 数据库: TDSQL vs OceanBase
- 容灾: 两地三中心 vs 异地多活
- 策略: 够用就好 vs 追求极致

## 5. 开源贡献与行业影响 (300字)
- FISCO BCOS联盟链的行业意义
- WeIdentity与去中心化身份
- 互联网银行的技术外溢效应

## 6. PM视角：架构决策的启示 (300字)
- "够用就好"vs"追求极致"的trade-off
- 从零开始 vs 存量改造的不同挑战
- 互联网银行模式的可复制性

ADR: 微众银行架构选择分析

# ADR-043: 微众银行"去IOE"分布式架构选择分析

## 状态
EVALUATED (用于学习分析)

## 核心决策分析

### 决策1: 为什么选择MySQL增强(TDSQL)而非原生分布式(OceanBase)?

分析:
- 2014-2015年OceanBase尚未成熟(未经大规模金融验证)
- MySQL生态成熟，DBA人才池大，招聘成本低
- 腾讯内部有MySQL运维经验(QQ/微信数据库团队)
- TDSQL在腾讯游戏中已有大规模使用经验
- "够用就好"的务实策略

### 决策2: 为什么选择单元化而非传统分库分表?

分析:
- 微众的业务模式(微粒贷为主)天然适合按用户分片
- 单元化不仅分库，还分应用——故障隔离更彻底
- 可以对单个单元做灰度发布——降低发布风险
- 跨单元操作比例低(<5%)——最终一致性可接受

### 决策3: 为什么不直接使用公有云?

分析:
- 2014年中国金融监管不允许核心系统上公有云
- 银行对数据主权和安全有极高要求
- 自建私有云成本在微众的规模下更优
- 后续趋势: 监管逐步放开，部分非核心系统已上云

## 启示
微众银行的架构选择体现了"实用主义"——不追求最先进的技术，
而是选择最适合当前阶段的方案。这与蚂蚁金服的"技术极致主义"
形成了有趣的对比。两种策略都成功了，说明架构没有绝对的好坏，
关键是与业务需求和组织能力匹配。

---

AI增强实践

微众银行的AI实践

微众银行AI应用矩阵
━━━━━━━━━━━━━━━━━━

1. 联邦学习(Federated Learning) ★核心差异化
   ├── 场景: 多方数据协作建模(不共享原始数据)
   ├── 案例: 与其他银行联合建立风控模型
   │   ├── 微众有行为数据(腾讯生态)
   │   ├── 合作银行有信贷数据
   │   └── 双方不交换数据，联合训练模型
   ├── 开源: FATE(Federated AI Technology Enabler)
   │   └── 全球最大的联邦学习开源平台
   └── 意义: 解决了"数据孤岛"问题(不违反隐私法规)

2. 智能风控
   ├── 申请风控: 秒级自动审批(99%+自动化率)
   ├── 模型: XGBoost/LightGBM + 深度学习
   ├── 特征: 腾讯社交图谱 + 信用数据 + 行为数据
   ├── 不良率: 微粒贷不良率约1%(行业领先)
   └── AI能力: 千人千面的额度和利率定价

3. 智能客服
   ├── 覆盖率: 90%+的客户咨询由AI处理
   ├── 技术: NLP + 知识图谱 + 对话管理
   ├── 多模态: 文字/语音/视频客服
   └── 效果: 客服人力成本降低80%

4. 智能运维(AIOps)
   ├── 故障预测: 基于监控数据预测故障
   ├── 根因分析: 故障发生时自动定位原因
   ├── 容量规划: 预测未来资源需求
   └── 效果: 故障恢复时间缩短60%

5. 隐私计算
   ├── 多方安全计算(MPC)
   ├── 可信执行环境(TEE)
   ├── 零知识证明(ZKP)
   └── 应用: 跨机构数据验证(不暴露原始数据)

# 联邦学习在风控中的应用(概念示意)
class FederatedRiskModel:
    """
    微众银行联邦学习风控模型概念
    多方协作训练，数据不出域
    """

    def federated_train(self, local_data, remote_parties):
        """
        联邦学习训练流程:
        1. 各方用本地数据训练本地模型
        2. 上传模型参数(不上传数据)到协调方
        3. 协调方聚合参数生成全局模型
        4. 下发全局模型到各方
        5. 重复直到收敛
        """
        for round in range(self.max_rounds):
            # Step 1: 本地训练
            local_model = self.train_local(local_data)
            local_params = local_model.get_parameters()

            # Step 2: 上传加密后的参数
            encrypted_params = self.encrypt(local_params)
            self.coordinator.upload(encrypted_params)

            # Step 3: 协调方聚合(同态加密下操作)
            global_params = self.coordinator.aggregate(
                all_parties_params  # 各方的加密参数
            )

            # Step 4: 下发全局模型
            self.update_local_model(global_params)

        return self.local_model

    def predict_risk(self, applicant):
        """
        联邦模型预测:
        使用联合训练的模型进行风控决策
        模型融合了多方数据的知识，但没有交换原始数据
        """
        features = self.extract_features(applicant)
        risk_score = self.local_model.predict(features)
        return RiskDecision(
            score=risk_score,
            approved=risk_score < self.threshold,
            rate=self.pricing_model.get_rate(risk_score)
        )

---

与Web3/DeFi的关联

微众架构与DeFi的映射

微众银行 ←→ DeFi 架构映射
━━━━━━━━━━━━━━━━━━━━━━━━

微众架构元素           DeFi等价物
─────────────         ─────────
单元化架构         ←→  分片链(Sharding)
TDSQL分库分表      ←→  区块链状态分片
跨单元消息         ←→  跨链消息(LayerZero/Wormhole)
最终一致性         ←→  最终确认(区块确认后)
联邦学习           ←→  隐私计算(ZKP/FHE/MPC)
FISCO BCOS联盟链   ←→  Hyperledger/企业区块链
WeIdentity(DID)    ←→  ENS/Ceramic/Worldcoin

深度对比:

1. 单元化 vs 区块链分片
   ├── 微众: 按用户ID分片到固定单元
   │   └── 中心化路由(确定性)
   ├── 以太坊Danksharding: 按数据分片
   │   └── 去中心化路由(验证者分配)
   ├── 共同挑战: 跨分片通信
   └── 本质相同: 将大系统拆分为可独立运行的小系统

2. 联邦学习 vs 链上隐私计算
   ├── 微众联邦学习: 多方协作建模，数据不出域
   │   └── 中心化协调方(微众)
   ├── DeFi隐私: ZKP/FHE保护交易隐私
   │   └── 去中心化(无需信任第三方)
   └── 趋势: 两者正在融合(联邦学习+区块链=去中心化联邦学习)

3. FISCO BCOS vs 公链
   ├── FISCO: 联盟链(许可制/高性能/合规)
   ├── 以太坊: 公链(无许可/去中心化/抗审查)
   ├── 微众选择联盟链: 因为金融监管要求(实名/合规)
   └── 未来: 联盟链和公链可能通过跨链桥互通

微众在Web3方面的探索

微众的Web3布局
━━━━━━━━━━━━━

1. FISCO BCOS 3.0
   ├── 支持WASM虚拟机(与以太坊EVM互补)
   ├── 支持PBFT+Raft混合共识
   ├── 跨链协议(链间互操作)
   └── 目标: 成为中国金融区块链标准

2. 分布式数字身份(DID)
   ├── WeIdentity: W3C DID标准实现
   ├── 应用: 银行间KYC互认(减少重复认证)
   ├── 与Web3的DID(如ENS)的理念相同
   └── 差异: WeIdentity是合规框架内的DID

3. 数字人民币(e-CNY)
   ├── 微众作为试点银行参与e-CNY运营
   ├── 技术: 基于分布式核心架构的钱包服务
   └── 与CBDC全球趋势一致

4. 隐私计算
   ├── WeDPR: 融合MPC+TEE+ZKP
   ├── 与Web3隐私方案(Aztec/Tornado)目标相同
   └── 差异: WeDPR面向企业间数据协作

---

今日思考

深度问题1

"微众银行单元化架构如何实现？"

单元化的核心是三步：(1)用户归属确定——通过Hash(user_id) % N将用户映射到固定单元，这个映射关系一旦确定通常不变(除非单元分裂)；(2)单元封闭——每个单元包含完整的应用+缓存+数据库，该用户的所有操作在单元内完成(本地事务)；(3)跨单元路由——少量跨单元操作(如跨用户转账)通过消息队列异步处理，保证最终一致性。实现的关键挑战是确定分片粒度(太粗导致单元过大，太细导致跨单元操作增多)。

深度问题2

"互联网银行vs传统银行的架构差异根源是什么？"

根源不是技术而是业务模式。互联网银行(微众)的特点：产品少(主要是微粒贷)、标准化(无特殊条款)、全线上(无网点)、小额高频(平均贷款<5万)。这使得架构可以做到极致简化和标准化。传统银行(工行)的特点：产品多(数千种)、定制化(大客户特殊条款)、线上线下混合(数万网点)、全客群(从个人到国企)。这要求架构具备极高的复杂度和灵活性。两者面临的问题根本不同，所以架构也不同。

深度问题3

"微众的成本优势是否可持续？如果传统银行完成信创改造呢？"

微众的成本优势有结构性和非结构性两部分。结构性优势(长期存在)：无网点、产品简单、自动化程度高——这些是业务模式决定的，传统银行很难复制。非结构性优势(可能缩小)：硬件成本(传统银行完成信创后x86成本接近)、软件License(Oracle替换后消除)。所以传统银行信创改造后会缩小差距，但微众仍有2-5倍的成本优势(因为业务模式差异)。

---

面试题准备

面试题1：微众银行单元化架构如何实现？

30秒版本： 微众将所有用户按user_id哈希分配到不同的"单元"(Unit)。每个单元包含完整的应用层+缓存+数据库，是一个自治的子系统。同一用户的所有操作在其归属单元内完成(本地事务)。跨单元操作(如跨用户转账)通过消息队列异步处理，保证最终一致性。这样实现了线性水平扩展——用户增长时只需增加单元数量。

2分钟版本： 微众的单元化架构有三层设计：

路由层：全局DCN(Data Center Node)负责根据用户ID确定归属单元。路由规则通常是 unit_id = hash(user_id) % N。这个路由层是无状态的，可以水平扩展。

单元层：每个单元是一个完整的微系统，包含应用服务、Redis缓存、TDSQL数据库分片。该单元用户的所有数据都在本单元内。单元间不共享数据。

跨单元层：少量跨单元操作通过消息队列处理。以转账为例：发起方单元先冻结金额并发送消息，接收方单元收到消息后入账并回复确认，发起方收到确认后完成交易。通过消息可靠性+对账补偿保证最终一致性。

这个架构的核心优势是：(1)线性扩展——加单元即可支持更多用户；(2)故障隔离——单个单元故障只影响1/N的用户；(3)灰度发布——可以先在一个单元测试新版本。

可能的追问：

• Q：跨单元操作的一致性如何保证？
• A：通过消息可靠性(至少投递一次)+业务幂等(重复消息不重复处理)+定时对账(发现不一致自动补偿)三层机制保证最终一致性。对于资金类操作，还有人工差错处理作为最后防线。

面试题2：互联网银行vs传统银行的架构差异？

30秒版本： 核心差异源于业务模式不同。互联网银行产品少、标准化、全线上，可以用简单的分布式架构(单元化+微服务)实现极致的成本效率。传统银行产品多、定制化、线上线下混合，需要复杂的架构支撑多样化业务。在技术选型上，互联网银行倾向全自研+开源(零License费)，传统银行倾向外购+逐步替代(降低风险)。

---

学习资源

---

明日预告

Day 44: 核心银行系统总结 — 14天核心银行知识图谱整理、完整架构设计文档、技术栈选型指南、演进路线图(遗留→分布式→云原生→Headless)、核心银行与DeFi的架构映射、14天面试题精选Top 10。这是第二阶段第一个子模块的收官。