2. 高频面试问题与回答框架
核心银行架构师的面试，很少停留在“你用过什么技术”这一层。面试官真正想确认的是：你是否理解银行核心系统的业务约束、监管要求与架构演进路径，以及你能否在高压场景下做出可落地的技术决策。因此，回答框架的价值不在于背诵模板，而在于让你在有限时间内呈现出“结构化思考 + 业务敏感度 + 工程判断力”。本章围绕高频问题、答题结构、公司侧重点三个维度展开，帮助你建立可复用的表达路径。
一、核心原理：面试官在评估什么
核心银行系统承载账户、存款、贷款、总账、利息计算、日终批处理等关键能力，任何架构决策都直接关联资金安全与监管合规。面试官通常从四个层面评估候选人：第一，业务理解力，即你是否清楚产品规则、会计科目与交易生命周期；第二，架构判断力，即你能否在分布式与集中式、微服务与单体、自研与外购之间做出有依据的取舍；第三，风险意识，包括幂等、对账、冲正、灾备、审计留痕；第四，落地能力，即方案是否考虑迁移窗口、并行运行、数据一致性与回退策略。理解这四层，你的回答就不会沦为技术名词堆砌。
二、方法流程：高频问题与答题结构
高频问题大致可分为五类：架构演进类、分布式事务类、高可用与灾备类、数据迁移类、性能与批处理类。建议统一采用“场景定位—约束分析—方案分层—风险兜底—量化结果”的五段式结构。以“核心系统如何做分布式事务”为例，先说明业务场景是跨账户转账还是跨行清算，再指出强一致与最终一致的边界，然后分层给出本地事务表、TCC、消息最终一致等方案，最后补充对账与冲正机制。
| 问题类型 | 答题结构 | 公司侧重点 |
|---|---|---|
| 架构演进 | 现状痛点 → 目标架构 → 演进路径 → 风险控制 | 业务连续性与监管合规 |
| 分布式事务 | 一致性边界 → 方案选型 → 补偿机制 → 对账验证 | 资金安全与幂等设计 |
| 高可用灾备 | RTO/RPO → 多活策略 → 切换演练 → 数据校验 | 切换真实性与演练频率 |
| 数据迁移 | 数据盘点 → 映射规则 → 并行验证 → 回退方案 | 迁移窗口与数据一致性 |
| 性能批处理 | 批量拆分 → 并行调度 → 资源隔离 → 监控告警 | 日终时效与可观测性 |
三、案例/场景：一次完整的回答示范
面试官问：“如果核心系统要从集中式迁移到分布式，你会怎么设计？”低分回答会直接说“用微服务拆分、上云、加缓存”。高分回答会先界定范围：哪些模块必须保持强一致，哪些可以异步化。例如存款核心与总账保持集中式或强一致数据库，查询与报表类能力下沉到分布式服务。接着给出迁移路径：先做服务边界梳理与数据解耦，再通过双写或影子库并行验证，最后按业务灰度切换。
迁移阶段示例：
阶段一：服务边界梳理，输出领域模型与依赖矩阵
阶段二：影子库双写，比对交易流水与余额一致性
阶段三：灰度切流，按客户号段或产品维度逐步放量
阶段四：回退预案，保留原系统只读入口与反向同步通道
关键指标：交易成功率、对账差异率、日终批处理时长、RTO/RPO四、误区与复盘：常见失分点
- 只谈技术不谈业务：核心银行的架构决策必须回到产品规则与监管要求，脱离业务的方案容易被追问击穿。
- 回避一致性难题：直接说“最终一致就行”而不说明补偿、对账与冲正，会被认为风险意识不足。
- 缺少回退方案：迁移与切换类问题必须包含回退路径，否则面试官会质疑你的生产经验。
- 忽视批处理与日终：核心银行日终批处理是硬约束，性能优化不能只谈在线交易。
- 不区分公司侧重点：国有大行更看重合规与稳定，股份制银行关注敏捷与成本，互联网银行强调弹性与自动化。
最后提醒一点：回答框架是骨架，真实项目细节是血肉。面试官追问时，往往会沿着你提到的某个技术点深入，例如“你说的TCC，空回滚和悬挂怎么处理？”因此每个框架节点背后都要准备至少一个可展开的技术细节。把本章的表格与五段式结构内化为自己的表达习惯，你就能在核心银行架构师面试中做到既有高度、又有落地感。