容量规划回答两个核心问题："系统能撑多少并发"和"峰值来了要不要扩容"——不是一次性的测试活动，而是基于业务增长持续迭代的工程实践。在银行业，容量规划受监管硬约束，是保障核心业务连续性的基础性工作。
基于历史监控数据（CPU、内存、TPS、并发数）通过时间序列分析预测资源消耗趋势。适用于稳态运行系统，数据采集周期建议≥6个月。
建立容量数学模型：所需CPU核数 = (峰值TPS × 单交易CPU耗时) / CPU目标利用率。适用于新建系统或架构变更场景。
通过全链路压力测试实际验证容量上限——最可靠的方法。适用于核心系统上线或重大活动前的容量确认。推荐"三位一体"策略：趋势分析做长期预测、模型推演做快速估算、压测验证做精确确认。
| 系统类型 | 典型TPS | CPU建议 | 数据库建议 | 安全水位 |
|---|---|---|---|---|
| 核心账务 | 3000-8000 | 32C×4节点 | Oracle RAC 4节点 | 极限的60% |
| 支付清算 | 5000-15000 | 32C×6-8节点 | 分布式数据库 | 极限的60% |
| 网银/手机银行 | 10000-50000 | 16C×20-50节点 | 读写分离+Redis | 极限的70% |
| 信贷审批 | 500-2000 | 16C×4节点 | MySQL主从 | 极限的70% |
| 风控引擎 | 10000-30000 | 16C×10节点 | 内存数据库 | 极限的50% |
| ESB服务总线 | 5000-20000 | 16C×6节点 | 无状态+MQ | 极限的60% |
操作：阶梯式加压（20%→40%→60%→80%→100%→120%），找到TPS不再随并发增加的拐点。拐点对应TPS就是系统的容量上限，安全运行容量取上限的60%-70%。
操作：模拟峰值流量触发自动扩容规则，记录从触发到完成扩容的冷启动时间，验证新节点加入后负载均衡是否立即生效。银行系统扩容窗口通常要求≤5分钟。
操作：模拟决算日+50%~200%峰值批量业务（结息、计提、损益结转），全链路压测验证12小时稳定运行能力。