容量规划实战：从 QPS 预估到资源水位管理

容量规划实战：从 QPS 预估到资源水位管理

容量规划的核心矛盾：资源冗余是钱，冗余不足是事故。多数团队的实际状态是拍脑袋——大促前拍脑袋扩容，出事后拍脑袋再扩，平时用不到的机器挂着空转烧钱。容量规划不是一门预测未来的玄学，而是一套「测量现状 → 推算需求 → 按水位管理」的工程流程。本文给出一套可以直接落地的四步法。

一、先测量：单机容量的标定

一切规划从「单机能扛多少」开始。标定单机容量的正确姿势：

压测而非估算。对每个核心服务在预发环境做阶梯压测：从当前日常流量的 1 倍开始，每档加 20%，每档持续 10 分钟，直到出现拐点（错误率 > 0.1% 或 RT P99 超过 SLO）。拐点前最后稳定的一档就是该服务的单机容量。

压测数据的真实性决定标定的有效性。三个常见失真点：压测流量模型与真实不符（读写比 5:5 vs 真实 8:2，数据库行为完全不同）；缓存命中率不同（预发数据量小全在缓存里，真实数据集缓存穿透后容量砍半）；依赖服务挡板化（下游挡板响应飞快，真实下游拖慢主服务）。标定时要用生产回放流量，且必须把被测服务的下游依赖接到影子环境而非挡板。

标定结果写成容量卡片：服务名、单机容量 QPS、当前实例数、总容量、日常峰值、峰值利用率。这张卡片是后续所有规划的事实基础，每次压测后更新。

二、再推算：流量到资源的换算

有了单机容量，从业务流量推算资源需求：

入口 → 服务的传导系数。首页 QPS 增长 2 倍，商品详情服务增长多少？用历史监控数据算传导比：详情页 QPS / 首页 QPS 的比值（点击率决定），以此类推到每层服务。这个传导系数表是容量规划的核心资产——大促流量从入口进来，沿传导系数逐层换算到每个服务的增量需求。

三层资源分开算。无状态服务（实例数 = 预估 QPS ÷ 单机容量 × 安全系数 1.3）只是最简单的一层；有状态资源要单独建模：数据库连接数（每实例 × 池大小，扩容应用别忘了 DB 连接上限）、缓存带宽与容量（大促预热数据集是日常几倍）、消息队列堆积余量。容量事故的最常见形态不是应用没扩够，是应用扩完把数据库连接打爆了。

别漏带宽。静态资源（图片、视频）在大促当晚上涨最凶的是 CDN 带宽，费用按 95 峰值计费，提前规划预热资源的价格远低于临时扩容。

三、水位管理：日常的红黄线

容量规划不是大促前的一次性动作，而是日常的水位管理：

水位定义：资源利用率 = 峰值用量 / 总容量。红线（>70%）触发扩容评估，黄线（50%~70%）关注趋势，绿线（<50%）健康。水位按每类资源分别维护：应用 CPU 水位、DB 连接水位、缓存容量水位、磁盘水位。

自动化水位报表：每周自动生成各服务的水位周报——上周峰值、水位百分比、趋势（连续三周上涨的服务标红）。周会的 10 分钟固定议程过这张表：红色水位的当场定扩容排期，趋势异常的查原因（是流量真涨了还是单机容量标定过期了）。

缩容与扩容同等重要。临时扩容的机器用完就缩回来——挂着的闲置机器是纯成本。缩容决策同样有依据：水位连续四周 < 30% 的服务，缩容 1~2 个实例观察一周。容量管理的成本意识就在这里：扩容要快（自动化），缩容要准（水位驱动），不能只扩不缩。

四、弹性与冗余：两种策略的适用边界

弹性伸缩（Auto Scaling）：适合无状态、扩容时间 < 5 分钟、镜像预热好的服务。配置基于指标（CPU 或自定义 QPS）触发，大促前验证过扩容动作的全链路（新实例注册、负载均衡生效、预热完成）。

容量预留：适合有状态或扩容慢的资源。数据库、大缓存集群不能秒级扩，必须按预估峰值的 120% 预留。预留的量要写清楚归还时间——「大促后 11-20 降配回日常规格」，避免预留变成永久成本。

实际方案是组合：核心链路预留保底 + 无状态层弹性扛波动。全弹性的风险是云资源池的抢兑（大促当天大家都扩，区域资源不足），所以关键资源的大促扩容要提前一周预购，而不是当天弹性。

五、一个季度一轮回

容量规划是滚动循环：每季度重标定一次单机容量（代码变更会改变容量——一次重构可能让单机 QPS 提升 30%，旧卡片就失真了），每月过一次水位报表，每次大促后复盘预估与实际的偏差（预估 QPS vs 实际 QPS 的误差率，连续两届校准你的预估模型）。容量预估的准确度是练出来的：第一年可能误差 50%，坚持校准两年后误差能收窄到 20% 以内——这时容量规划才真正从「拍脑袋」变成「工程」。