要回答的问题

  • 当前系统能承受多少负载？
  • 什么时候会不够用？
  • 需要提前多久采购/扩容？
  • 需要多少资源才能支撑预期的增长？

为什么重要

容量不足：服务降级、超时、不可用——直接影响用户和业务。

容量过剩：浪费成本。在云环境中，这意味着每月多付钱。

容量规划的目标，是在两者之间找到平衡——用合理的成本，支撑业务的增长。

基本流程

一、建立当前基线

先测量现在的状态：

  • 峰值 QPS / 并发数；
  • 资源使用率（CPU、内存、磁盘 I/O、网络带宽、连接数）；
  • 关键业务指标（日活、订单量、数据量）。

关键：看的是峰值和趋势，不只是平均值。

二、确定单实例的容量上限

通过压力测试（Load Testing / 基准测试）获得：

  • 逐步增加负载，观察响应时间；
  • 找到拐点（性能开始急剧下降的位置）；
  • 确定单实例能支撑的 QPS（在满足延迟目标的前提下）。

注意：

  • 压力测试要贴近真实场景（真实的请求分布、数据规模、读写比例）——否则结果失真；
  • 在压测中发现瓶颈后，优化并重新测试。

三、预测增长

基于业务数据做预测：

  • 历史增长率；
  • 业务计划（如即将到来的营销活动、新市场拓展）；
  • 季节性波动（如电商的大促）。

关键：与业务团队沟通——技术指标（QPS）需要翻译成业务指标（用户数、订单量），反之亦然。

四、计算需求

需要的实例数 = 预期峰值 QPS / 单实例容量
                    × (1 + 冗余系数)

冗余系数考虑：

  • 故障冗余：N+1 或 N+2（一台机器故障时仍能服务）；
  • 增长缓冲；
  • 突发流量余量。

五、确定扩容时间点

考虑采购和安装周期（物理服务器可能数周，云资源几分钟）。

云环境大大简化了这个过程——但依然需要规划（如预留实例需要提前购买以获得折扣）。

关键概念：余量（Headroom）

永远不要让系统跑在 100% 利用率上。

原因：

  • 排队论告诉我们：当资源利用率接近 100% 时，延迟会急剧上升（因为排队时间爆炸式增长）；
  • 没有应对突发流量的空间；
  • 没有应对故障的空间。

经验做法：目标利用率通常在 60%–80%，具体取决于业务的波动性和故障容忍度。

云环境下的变化

弹性伸缩（前文提到过）改变了容量规划的方式：

  • 不再需要为峰值长期预留资源；
  • 可以根据负载自动扩缩容。

但规划依然必要：

  • 扩容需要时间：启动新实例、应用初始化、预热（JIT 编译、缓存加载）可能需要几分钟。对于突发流量，这几分钟可能就是事故；
  • 配额限制：云账号有资源配额，需要提前申请；
  • 成本优化：预留实例、节省计划（Savings Plans）需要提前承诺；
  • 数据库等有状态服务：扩缩容困难得多，仍需规划。

瓶颈分析

容量规划的关键是找到真正的瓶颈——往往是某个特定的资源：

  • CPU 密集型：计算、加密、压缩、视频转码；
  • 内存密集型：缓存、大数据集；
  • I/O 密集型：数据库、文件服务；
  • 连接数：数据库的最大连接数常常是瓶颈；
  • 带宽：CDN、视频分发。

不要盲目扩容——如果瓶颈是数据库的连接数，增加应用服务器只会让情况更糟（更多连接）。

压测的类型

负载测试（Load Testing）：在预期负载下验证系统表现。

压力测试（Stress Testing）：超出预期负载，找到系统的极限和失效方式。

容量测试：确定系统在满足性能目标下的最大负载。

浸泡测试（Soak / Endurance Testing）：长时间运行，发现内存泄漏、资源耗尽等问题。

尖峰测试（Spike Testing）：突然的大流量冲击，验证弹性。

一句话

容量规划的本质，是把"我们不知道能撑多久"，变成"我们知道在什么时候、需要什么、以及为什么"。

说明：本文为运维实践的知识整理。