📌 容量规划

1. 定义与目的

容量规划（Capacity Planning）是指根据业务增长预测、历史运行数据和系统架构特性，科学评估系统在未来一段时间内所需的计算、存储和网络资源，并制定相应扩容策略的过程。在银行业，容量规划是保障核心业务连续性的基础性工作，直接关系到系统能否平稳支撑业务高峰。

容量规划的核心目的包括：

💡 银行业特殊性 银行核心系统（如核心账务、支付清算、网银等）的容量规划受监管要求严格约束。银保监会要求重要信息系统具备足够的容量冗余能力，关键业务系统必须经过容量压力测试验证方可上线。

银行业普遍采用三种容量评估方法，通常结合使用以确保评估结果的全面性和准确性。

基于历史监控数据（CPU、内存、TPS、并发数等），通过时间序列分析预测资源消耗趋势。适用于稳态运行系统，业务增长模式相对稳定的场景。

通过建立系统的容量数学模型，根据业务量和单交易资源消耗计算所需资源总量。适用于新建系统或发生重大架构变更的场景。

所需CPU核数 = (峰值TPS × 单交易CPU耗时) / CPU目标利用率

所需内存 = 基础内存 + (峰值并发 × 单会话内存)

所需带宽 = 峰值TPS × 单交易平均报文大小 × 8 / 带宽目标利用率

通过全链路压力测试实际验证系统的容量上限，是容量评估中最可靠的方法。适用于关键核心系统上线或重大业务活动（如双十一、年终决算）前的容量确认。

✅ 方法选择建议 银行系统容量评估推荐"三位一体"策略：趋势分析做长期预测（半年至一年），模型推演做快速估算（新系统/架构变更），压测验证做精确确认（上线前/活动前）。三种方法相互校验，显著降低容量风险。

下表给出了银行业几类典型系统的容量模型参考值，数据来源于行业实践与公开基准。实际值因架构、代码质量、网络环境而异，仅供参考。

系统类型	典型TPS范围	CPU配置建议	内存配置建议	数据库建议	网络带宽
核心账务系统	3000-8000 TPS	32C × 4节点（应用层）	64GB × 4节点	Oracle RAC 4节点	10 Gbps
支付清算系统	5000-15000 TPS	32C × 6-8节点	128GB × 6-8节点	分布式数据库	10-25 Gbps
个人网银/手机银行	10000-50000 TPS	16C × 20-50节点（弹性）	32GB × 20-50节点	读写分离 + Redis	25-100 Gbps
信贷审批系统	500-2000 TPS	16C × 4节点	32GB × 4节点	MySQL主从	1 Gbps
风控决策引擎	10000-30000 TPS	16C × 10节点	64GB × 10节点	内存数据库/Redis	10 Gbps
ESB/服务总线	5000-20000 TPS	16C × 6节点	32GB × 6节点	无状态（MQ+缓存）	25 Gbps

⚠️ 容量规划误区 常见的容量规划误区包括：忽视数据库层瓶颈（80%的性能问题源于数据库）、仅关注CPU忽略IO与网络、未考虑资源争抢（虚拟化/容器化环境的Noisy Neighbor效应）、使用平均值代替P99进行容量估算。银行系统尤其需要关注长尾延迟对客户体验的影响。

某股份制银行年终决算期间，核心账务系统需要处理比平日高3-5倍的批量业务量（结息、计提、损益结转等）。要求系统在年终决算窗口（12月31日18:00至次日6:00）内完成所有批量任务，且联机交易不受影响。

✅ 容量规划最佳实践总结

⚡ 性能测试知识体系 · 内容持续更新中