1. 容量压测概述
1.1 容量压测的定义
容量压测（Capacity Testing）是一种在预定义的生产级硬件、网络和软件环境下，通过逐步增加并发用户数或请求吞吐量，测定系统能够稳定承载的最大业务容量，并验证其在极限负载下是否仍能满足性能指标（SLA）的测试活动。其核心输出是系统的容量拐点——即从正常响应到性能急剧下降的临界负载值。
关键公式： 系统容量 = min(硬件资源瓶颈点，软件资源瓶颈点，SLA 达标上限)
1.2 容量压测的目标与价值
| 维度 | 具体目标 | 业务价值 |
|---|---|---|
| 容量摸底 | 获取系统在典型混合场景下的最大 TPS（每秒事务数）和最大并发用户数 | 为容量规划提供数据基准，避免过度采购或资源不足 |
| 瓶颈定位 | 识别 CPU、内存、IO、数据库连接池、线程池等资源的首个瓶颈点 | 精准指导代码优化、配置调优或架构升级 |
| 弹性验证 | 验证自动伸缩策略（如 K8s HPA）是否能在容量拐点前及时扩容 | 保障大促、秒杀等流量洪峰下的系统稳定性 |
| SLA 校验 | 确认在容量上限内，响应时间（RT）、错误率、吞吐量均满足业务承诺 | 避免因性能劣化导致用户流失或资损 |
1.3 容量压测与负载/压力测试的区别
许多团队容易混淆这三类测试，但它们的目的、负载模型和通过标准有本质差异：
| 对比维度 | 容量压测 | 负载测试 | 压力测试 |
|---|---|---|---|
| 核心目的 | 找到系统能稳定承载的最大容量 | 验证系统在预期正常负载下的表现 | 观察系统在超载后的恢复能力和崩溃行为 |
| 负载模型 | 阶梯式递增，直到出现拐点或资源饱和 | 固定或小幅波动的典型业务负载 | 持续超过容量上限，甚至达到 2~3 倍 |
| 通过标准 | 所有指标在容量点内必须满足 SLA | 全部指标在测试期间持续达标 | 关注系统是否优雅降级、不崩溃、可恢复 |
| 典型输出 | 容量拐点图、最大 TPS、资源利用率曲线 | 平均 RT、P99 RT、错误率是否在阈值内 | 恢复时间、数据一致性、熔断/限流触发记录 |
| 执行频率 | 大版本发布前、架构变更后、定期容量规划 | 每次发布前的回归验证 | 稳定性专项、混沌工程演练 |
实践建议： 容量压测通常作为负载测试的前置步骤——先通过容量压测摸清上限，再基于上限的 60%~80% 设计日常负载测试的并发目标。
1.4 容量压测的典型应用场景
- 电商大促容量规划： 双11、618 前，对核心交易链路（浏览、加购、下单、支付）进行容量压测，确定需要扩容的服务器台数和数据库规格。
- 微服务架构容量评估： 针对网关、用户服务、订单服务等独立模块分别压测，找出整个调用链中的短板服务，避免因单个服务容量不足导致全链路雪崩。
- 云原生环境弹性策略验证： 在 K8s 集群中执行容量压测，验证 HPA 是否能在 CPU/内存达到阈值时及时弹出 Pod，以及缩容策略是否过于激进导致抖动。
- 数据库连接池与线程池调优： 通过容量压测确定连接池大小、线程池队列深度的最佳配置，避免因池化参数不合理导致资源浪费或请求排队超时。
- 第三方依赖容量评估： 对依赖的 Redis、MQ、外部 API 等中间件进行容量压测，确保上游系统不会因下游容量不足而被拖垮。
1.5 容量压测核心流程
1.6 容量压测的典型输出产物
| 产物名称 | 内容说明 | 使用方 |
|---|---|---|
| 容量拐点图 | 横轴为并发用户数或 TPS，纵轴为响应时间/错误率/资源利用率，标注拐点位置 | 开发、架构、运维 |
| 最大容量矩阵 | 按业务场景（登录、查询、下单）列出各自的最大 TPS、最大并发数、对应资源消耗 | 产品、运维、SRE |
| 瓶颈清单 | 按优先级排列的瓶颈项，包含瓶颈描述、影响范围、建议优化方案 | 开发、DBA、架构 |
| 容量规划建议 | 基于压测结果给出未来 3~6 个月的服务器、数据库、带宽等资源扩容建议 | 运维、财务、技术负责人 |
常见误区： 容量压测不是一次性的活动，而是持续迭代的过程。每次代码重构、中间件升级、硬件变更后，系统的容量特性都可能发生变化，需要重新执行容量压测以更新基线。