4. 核心银行系统架构演进

在核心银行架构师面试中，架构演进几乎是必问题。面试官并不满足于你背出“集中式→分布式”这条时间线，而是想确认三件事：你是否理解每次演进背后的业务驱动力，你是否踩过真实迁移中的坑，以及你能否在“一致性、可用性、成本”之间做出可解释的取舍。本章围绕这条主线，给出可复用的回答框架与追问应对策略。

一、核心原理：三次演进解决的是三类不同矛盾

集中式架构（大型机/小型机+集中数据库）解决的是“强一致与稳定”，代价是横向扩展困难、发布耦合。SOA 解决的是“系统间复用与解耦”，通过 ESB 把能力服务化，但总线容易成为性能与治理瓶颈。微服务解决的是“独立部署与团队自治”，代价是分布式事务、链路治理和运维复杂度上升。单元化与多活解决的是“容量与业务连续性”，把流量按维度切分到多个单元，实现故障隔离与就近接入。

二、方法流程：从现状评估到单元化落地

1. 业务分域：按客户、账户、交易、清算等维度划分限界上下文，识别强一致边界。
2. 数据拆分：先做读写分离与分库分表，再评估单元化分片键（如客户号、机构号）。
3. 服务治理：注册发现、熔断限流、链路追踪、灰度发布同步建设。
4. 一致性方案：核心账务优先 TCC/SAGA，辅以对账与冲正兜底。
5. 多活切换：定义 RTO/RPO，演练单元级故障注入与流量调度。

单元化分片示例（伪配置）
unit: shanghai
  shardKey: customerId
  range: [0, 49999999]
unit: beijing
  shardKey: customerId
  range: [50000000, 99999999]
failover:
  mode: unit-isolation
  rto: 30s
  rpo: 0

三、案例场景：某行核心账务单元化迁移

场景：日交易量峰值 8000 TPS，原集中式数据库接近瓶颈，监管要求同城双活。团队按客户号做单元化，上海、北京双单元互为主备，跨单元交易通过异步消息+对账补偿。迁移采用“新老并行、灰度切流”，先切查询流量，再切非账务交易，最后切账务写入。上线后单单元故障可在 30 秒内隔离，RPO 为 0，RTO 控制在分钟级。

四、误区与复盘：面试中最容易失分的四点

• 只讲技术不讲业务：未说明演进由容量、监管或成本驱动。
• 忽视一致性代价：把分布式事务说成“加个消息队列就行”。
• 多活等于双活：未区分同城双活、异地多活与单元化隔离的差异。
• 没有回退方案：未说明灰度失败如何切回、数据如何对齐。