3. 银行系统架构概览
容量规划不是对所有系统套用同一套公式。银行IT架构经过多年演进，形成了以核心银行为账务底座、渠道系统为流量入口、支付系统为资金通道、信贷系统为资产引擎的分层格局。每一层的业务特征、数据一致性要求、峰值形态和扩容约束都不同，容量规划必须“分域施策”。本节先建立架构全景，再逐一拆解四类系统的容量规划要点。
一、银行系统分层架构与容量视角
从容量规划角度看，银行系统可划分为四个逻辑层：渠道接入层（手机银行、网上银行、柜面、开放银行API）、业务处理层（支付、信贷、理财、信用卡）、核心账务层（核心银行系统，负责存款、贷款、总账）、数据与集成层（数据仓库、ESB、消息中间件）。渠道层直面客户，流量波动最大；业务层承担规则计算与流程编排；核心层要求强一致与高可靠，扩容最谨慎；数据层则面临批量窗口与实时查询的双重压力。
容量规划的核心问题在每一层表现为不同形式：渠道层问“能扛多少并发会话”，业务层问“每秒能处理多少笔交易”，核心层问“日终批量能否在窗口内完成”，数据层问“跑批与联机查询如何错峰”。
二、四类典型系统的容量规划要点
核心银行系统是账务唯一真相源，通常采用集中式主机或大型分布式数据库，强调ACID。其容量瓶颈往往不在联机交易，而在日终批量：利息计提、总分核对、报表生成必须在凌晨窗口内完成。容量规划需测算批量作业的CPU分钟数、I/O吞吐和并行度，并预留监管报送等临时任务空间。联机侧则关注热点账户（如大型商户结算账户）的行锁竞争。
渠道系统是流量第一入口，具有明显的潮汐特征：工资日、理财发售日、节假日前后会出现数倍于日常的并发。容量规划以“并发用户数→TPS→线程池/连接池→后端承载”为主线，重点评估会话保持、网关限流和降级策略。渠道系统通常可水平扩展，但需警惕其放大效应——一次渠道重试可能对核心造成数倍压力。
支付系统连接行内与行外，涉及大小额、网联、银联、SWIFT等通道。其容量受对手方窗口和清算时点约束，峰值常出现在整点、日终和营销活动结束瞬间。规划时需区分“受理能力”与“清算能力”，并考虑通道限流、排队重试和差错处理带来的额外负载。
信贷系统以流程长、计算重为特征：授信审批涉及征信查询、评分卡、规则引擎、额度计算，单笔耗时可达秒级甚至分钟级。容量规划关注批量进件（如房贷集中放款）与联机申请的比例，以及规则引擎和外部数据接口的响应时间。信贷系统还常与核心、支付联动，需评估跨系统事务的容量传导。
| 系统类型 | 典型峰值场景 | 核心容量指标 | 扩容约束 |
|---|---|---|---|
| 核心银行 | 日终批量、结息日 | 批量窗口时长、热点账户TPS | 强一致、停机窗口有限 |
| 渠道系统 | 工资日、理财发售 | 并发会话数、网关TPS | 可水平扩展，需防重试放大 |
| 支付系统 | 整点清算、营销结束 | 受理TPS、清算笔数、通道限额 | 受对手方窗口与限额约束 |
| 信贷系统 | 集中放款、批量进件 | 审批吞吐、规则引擎响应时间 | 外部数据接口依赖强 |
三、跨系统容量传导与压测场景设计
真实峰值很少只压一个系统。以“双十一”式营销为例：渠道层涌入大量秒杀请求，支付系统受理激增，核心系统扣款频繁，信贷系统可能同时处理分期申请。容量规划必须做链路级压测，而非单系统压测。建议按以下流程组织：
- 梳理关键业务链路，标注各系统调用关系与同步/异步边界；
- 为每个系统设定独立容量基线，再按链路比例合成混合场景；
- 在压测中注入真实峰值模型，包括突发尖峰和持续高压；
- 监控各系统水位，定位最先达到瓶颈的环节；
- 验证限流、降级、熔断策略是否按预期生效。
四、常见误区与复盘要点
误区一：只压渠道不压核心。渠道扩容容易，核心扩容难，若只提升渠道吞吐，压力会全部传导至核心，导致核心先崩。误区二：用平均TPS代替峰值TPS。银行交易具有强脉冲性，平均值会严重低估资源需求。误区三：忽略批量与联机叠加。日间联机高峰与日终批量若在时间上重叠，资源竞争会急剧恶化。误区四：压测环境与生产配置不一致，导致容量结论不可用。
复盘时应回答三个问题：瓶颈首先出现在哪个系统、哪个资源（CPU/内存/连接池/数据库锁）？限流降级是否保护了核心账务？扩容后容量水位是否回到安全区间？只有把架构认知、容量模型和压测验证闭环，容量规划才真正落地。
# 链路压测容量核对清单（示例）
[ ] 渠道网关并发连接数上限
[ ] 支付系统受理TPS与清算笔数
[ ] 核心系统联机TPS与批量窗口余量
[ ] 信贷规则引擎平均/99线响应时间
[ ] 数据库连接池与慢SQL数量
[ ] 消息中间件积压量与消费速率
[ ] 限流阈值与降级开关验证结果