1. 容量压测概述：定义、目标与价值
1.1 容量压测的定义
容量压测（Capacity Load Testing）是一种通过模拟真实用户负载，逐步增加系统并发请求量，以测量系统在预设或极限负载下的性能表现、资源消耗与行为特征的测试方法。其核心目的是确定系统的最大安全承载能力，并识别在负载增长过程中出现的性能拐点与瓶颈。
关键区分：容量压测不同于常规的性能基准测试（Benchmark）或稳定性测试（Soak Test）。基准测试关注单次响应速度，稳定性测试关注长时间运行下的资源泄漏，而容量压测聚焦于“系统还能承受多少并发”这一容量边界问题。
1.2 容量压测的核心目标
| 目标维度 | 具体描述 | 量化指标示例 |
|---|---|---|
| 最大并发用户数 | 确定系统在响应时间SLA（如TP99 < 500ms）内能支持的最大并发用户数 | MaxConcurrentUsers = 12,000 |
| 吞吐量上限 | 测量系统在单位时间内能处理的最大事务数（TPS/QPS） | MaxTPS = 2,500 req/s |
| 资源利用率拐点 | 识别CPU、内存、磁盘IO、网络带宽等资源在负载增长下的饱和点 | CPU利用率 > 85% 时TPS不再增长 |
| 弹性伸缩阈值 | 为自动扩缩容策略提供触发阈值依据 | CPU > 70% 触发扩容 |
| 故障恢复能力 | 验证系统在过载后恢复至正常服务水平的时长与行为 | 恢复时间 < 120s |
1.3 容量压测的业务价值
- 风险前置：在线上故障发生前，提前暴露容量不足、资源争抢、连接池耗尽等隐患。
- 成本优化：基于实测数据制定合理的资源规格与集群规模，避免过度配置或配置不足。
- SLA保障：为生产环境的容量规划提供可量化的依据，支撑业务高峰（如大促、秒杀）的稳定运行。
- 架构验证：检验系统架构（如微服务拆分、缓存策略、数据库分片）在高压下的实际表现。
实践建议：容量压测应作为每次大版本发布前的必选环节，而非仅在故障复盘时才被想起。建议将压测结果纳入CI/CD门禁，形成自动化卡点。
1.4 在系统生命周期中的位置
容量压测并非孤立的活动，它贯穿于系统生命周期的多个关键阶段。下图展示了容量压测在典型软件生命周期中的嵌入位置与触发时机。
1.5 容量压测的典型触发场景
- 新系统上线：验证系统是否满足业务容量需求，建立初始容量基线。
- 大版本发布：评估代码变更对系统容量的影响，防止性能退化。
- 业务高峰前：如电商大促、抢票、秒杀活动前，进行全链路容量摸底。
- 架构改造后：微服务拆分、数据库迁移、缓存引入等架构变更后的容量验证。
- 日常巡检：定期执行轻量级容量压测，监控系统容量趋势变化。
常见误区：容量压测不是“压到系统崩溃为止”。有效的容量压测应在达到性能拐点或SLA边界时停止，并记录此时的负载与资源数据。盲目追求压垮系统可能导致生产环境数据损坏或不可逆的故障。
1.6 容量压测与相关概念的对比
| 测试类型 | 核心关注点 | 典型负载模型 | 持续时间 |
|---|---|---|---|
| 容量压测 | 系统最大承载能力与性能拐点 | 阶梯递增负载 | 短时（10~30分钟） |
| 负载测试 | 在预期负载下的性能表现 | 固定目标负载 | 中时（30~60分钟） |
| 压力测试 | 系统在超负载下的行为与恢复 | 持续超载 | 短时（5~15分钟） |
| 稳定性测试 | 长时间运行下的资源泄漏与性能衰减 | 中等负载持续 | 长时（数小时~数天） |
| 基准测试 | 单次请求的响应速度与资源消耗 | 低并发单次 | 极短（1~5分钟） |
理解容量压测在系统生命周期中的定位，是后续进行脚本设计、场景编排与Runbook联动的基础。只有明确了“为什么压”和“在什么阶段压”，才能设计出真正有效的压测脚本与自动化流程。