3. 核心银行系统架构

要谈多活容灾与故障切换，必须先看清被保护的对象本身。核心银行系统并非一个单体应用，而是由渠道接入、联机交易、批量处理、账务核心、总账、客户信息、产品工厂、参数中心、数据服务等多层组件构成的复合体。它的架构决定了容灾的粒度：哪些单元可以独立切换，哪些必须整体迁移，哪些只能做数据级保护。理解这一层，后续的双活流量调度、单元化路由、数据库主备切换才有落脚点。

一、典型核心银行系统的组成分层

从纵向看，核心银行系统通常划分为五层。最上层是渠道接入层，包括柜面、手机银行、网上银行、ATM、开放银行API、银联/网联前置等，负责协议转换、报文校验与限流。第二层是集成与路由层，由ESB或API网关承担服务编排、渠道路由、灰度分流。第三层是业务服务层，承载存款、贷款、支付、结算、卡业务等联机交易逻辑。第四层是账务核心层，负责记账、余额更新、利息计提、总分核对，是数据一致性的关键。第五层是数据与基础设施层，包括核心数据库、批量调度、消息中间件、缓存、文件传输与数据仓库。

这种分层不是简单的技术堆叠，而是故障隔离的设计基础。渠道层可多活部署，业务服务层可按客户维度单元化，账务核心层往往受限于数据库一致性而采用主备或一主多读，数据层则决定RPO与RTO的物理下限。

二、联机交易链路与关键路径

一笔典型的转账交易，从渠道发起至返回结果，通常经过以下链路：渠道前置接收报文并完成格式校验，API网关进行鉴权与路由，业务服务层调用客户信息与账户服务校验状态，账务核心执行借贷记账并更新余额，同时写入交易流水，最后通过消息中间件异步通知渠道与外围系统。这条链路中，账务核心的数据库写入是强一致点，也是故障切换时最敏感的环节。

在双活架构下，交易链路被拆分为接入段、路由段、执行段与数据段。接入段可跨站点负载均衡，路由段依据客户号或账号进行单元化寻址，执行段在本地单元内闭环，数据段则通过数据库复制或分布式事务保证一致性。切换时，接入段与路由段可秒级调整，执行段需等待数据段确认，因此RTO往往由数据层决定。

三、数据库与中间件架构

核心银行数据库多采用集中式关系型数据库，如DB2、Oracle或国产分布式数据库。典型部署为“一主一备”或“一主多备”，通过日志复制实现数据同步。同城双活场景下，常采用数据库复制技术将主库日志实时传输至同城备库，备库可读或热备。异地灾备则通过异步复制或存储级复制实现，RPO通常在秒级至分钟级。

中间件层面，消息中间件承担交易异步解耦与最终一致性保障，常见有IBM MQ、Kafka、RocketMQ等。缓存中间件用于热点账户与参数缓存，需考虑双活下的缓存一致性。批量调度中间件负责日终批处理，其切换需与数据库切换协同，避免批量任务重复执行或漏执行。

四、关键业务模块与切换影响

核心银行的关键业务模块包括：客户信息模块（CIF）、存款模块、贷款模块、支付结算模块、卡模块、总账模块、利息模块、参数模块。各模块对容灾的敏感度不同。客户信息与参数模块读多写少，适合多活只读加主写；存款与贷款模块涉及余额与合同，强一致要求高；支付结算模块涉及跨行清算，需与外部网络协同；总账模块日终批量依赖强，切换窗口需避开批量时段。

五、场景复盘：某行同城双活切换中的链路断点

某银行在演练中将渠道层与业务服务层切换至同城双活中心，但账务核心数据库仍指向原主库。切换后，查询类交易正常，转账类交易在记账环节超时。排查发现，业务服务层已切换，但数据库连接池仍配置原主库地址，且DNS缓存未刷新。最终通过统一配置中心推送新数据库地址并刷新连接池解决。该案例说明：切换必须覆盖全链路配置，任何一跳的地址、证书、序列号未同步，都会成为断点。

# 切换检查清单示例
1. 渠道接入VIP是否已漂移
2. API网关路由规则是否指向新单元
3. 业务服务数据库连接串是否更新
4. 消息中间件队列是否已切换或重连
5. 缓存节点是否已加入新集群
6. 批量调度是否已暂停并确认断点
7. 对账文件传输目录是否可写
8. 监控告警是否已切换至新中心

综上，核心银行系统架构的容灾设计，本质是在分层结构中寻找可切换边界，在交易链路中识别强一致断点，在数据库与中间件中确认复制状态，在业务模块中评估切换影响。只有把架构看清，后续的多活流量调度、单元化路由与故障切换演练才能有的放矢。