2. 银行系统架构基础

要做好故障隔离与降级设计，第一步不是写熔断规则，而是把银行系统的“地形图”画清楚：钱在哪里记账、请求从哪里进来、一次转账要穿过多少系统、哪些环节一旦卡住会直接引发客诉与资金风险。本章从架构形态、系统分层、调用链路和故障影响四个角度，建立后续所有隔离与降级策略的判断基础。

一、集中式与分布式：两种架构的故障特征

集中式架构以大型机或高性能小型机为核心，核心账务、存款、贷款等模块通常运行在同一套主机与同一数据库中，通过事务保证强一致。它的优势是账务一致性强、链路短、运维边界清晰；劣势是扩容依赖纵向升级，单点故障影响面大，一次主机或数据库异常可能直接导致全行核心业务停摆。

分布式架构把业务拆成多个微服务或子系统，数据库按业务域拆分，通过服务注册发现、消息队列、分布式事务框架协同。它提升了弹性与横向扩展能力，但也引入了新的故障面：网络抖动、注册中心异常、下游超时、消息积压、分布式事务悬挂等。集中式怕“主机倒”，分布式怕“链路断”，两者的隔离与降级思路因此不同。

二、核心银行与渠道系统：分层与职责

银行系统通常按“渠道层—网关层—业务服务层—核心系统层—数据层”分层。渠道系统包括手机银行、网上银行、柜面、ATM、开放银行API等，负责交互与流量入口；网关层负责鉴权、限流、路由；业务服务层承载转账、支付、理财、信贷等组合逻辑；核心银行系统负责账户、余额、记账、利息等强一致账务处理；数据层包括核心数据库、缓存、消息队列与数据仓库。

三、服务调用链路：一次转账的完整路径

以手机银行转账为例，请求从客户端发起，经API网关鉴权与限流，进入转账服务；转账服务先调用客户服务校验身份，再调用账户服务检查余额，随后调用核心系统记账，最后通过消息队列通知账务、风控与通知系统。链路中任一节点超时或异常，都可能让整笔交易失败或处于“未知状态”。

客户端 → API网关 → 转账服务
                ├─ 客户服务（身份校验）
                ├─ 账户服务（余额检查）
                ├─ 核心系统（记账）
                └─ 消息队列 → 风控 / 通知 / 对账

链路越长，故障传播越快。若核心系统响应变慢，转账服务线程池会被占满，进而拖垮网关，形成雪崩。因此，隔离与降级必须落在链路的每个关键节点上：超时控制、线程隔离、熔断、限流、异步化与兜底返回。

四、常见故障场景与业务影响

银行系统常见故障可分为基础设施故障、应用故障、数据故障与依赖故障四类。基础设施故障包括主机宕机、网络分区、机房断电；应用故障包括服务崩溃、内存泄漏、线程池耗尽；数据故障包括数据库主从延迟、缓存击穿、消息积压；依赖故障包括第三方支付超时、征信接口不可用、短信通道阻塞。

• 核心系统不可用：记账失败，转账、存款、贷款全部受阻，属于最高级别故障，必须优先恢复或切换。
• 网关鉴权异常：全量请求被拒绝，影响所有渠道，需快速降级为本地鉴权或白名单放行。
• 消息队列积压：通知、对账延迟，短时间不影响交易，但持续积压会引发数据不一致。
• 第三方接口超时：支付、征信、短信等外部依赖变慢，需熔断并返回兜底结果，避免拖垮主链路。

五、复盘视角：从架构图到故障预案

复盘一次典型故障：某行手机银行转账大面积超时，根因是核心系统数据库主从切换导致写操作阻塞，转账服务未设置合理超时，线程池被占满，进而拖垮网关。改进措施包括：为核心调用设置独立线程池与超时阈值，增加熔断与快速失败，网关层对转账接口限流，渠道层提供“交易处理中”兜底页面，并建立核心系统健康探测与自动切换预案。