容量规划从哪里入手？
更新时间：2026-09-19。短答页。容量规划不是拍脑袋说「再买两台」，而是回答「在给定增长下，系统什么时候、在哪个组件先到瓶颈，需要提前准备多少余量」。
一句话回答
按五步走：先测准现状基线 → 量化单请求资源成本 → 用增长趋势做预测 → 用压测找出真正的拐点 → 设定水位线/扩容触发并预留冗余，并始终按峰值（而非平均）规划、给故障转移留余量。
五步起步
- 建立基线：用 Prometheus/vmstat 等采集各组件当前 QPS、CPU、内存、连接数、P99；知道「一台/一个实例能扛多少」（单机容量）。
- 算单请求成本：每 1k QPS 大约耗多少核、多少 MB 堆、多少 DB 连接。有了单位成本，流量翻倍就能线性外推资源。
- 增长预测：结合历史增速和大促倍数（如日常 ×5），预测未来 1~3 个季度峰值，而不是只看现在。
- 压测找拐点：用 wrk、ghz、JMeter、fio 逐步加压，找到 P99 开始陡增/错误率上升的拐点，拐点容量才是真实容量，标称配置不是。
- 定水位线与余量：平时利用率上限要保证「坏一台后剩余实例仍扛得住峰值」（如 N+1 下约 70%~75%），配置自动扩容触发线和限流兜底。
关键原则
- 按峰值规划，不按均值：均值 30% 不代表大促/批处理叠加时不爆。
- 留故障余量：冗余集群要按「坏一台后剩余容量 ≥ 峰值」算，见 N+1 容量怎么算。
- 瓶颈往往不在你以为的地方：应用没满但 DB 连接池、网卡、run queue 先到顶，逐层用 USE 方法查（指标体系）。
- 容量与 SLO 联动：接近容量前靠限流/降级保核心链路，见优雅降级。
最小可行动作（本周就能做）
bash
□ 拉一份最近 30 天各服务峰值 QPS / CPU / 内存 / P99
□ 对 1 个核心接口压测，记录拐点 QPS 和当时资源水位
□ 算出该接口每实例安全容量 → 推出峰值需要的实例数（向上取整+1 冗余）
□ 配置一条「利用率 > 70% 持续 10m」的扩容/预警坑
- 只看平均利用率，被峰值和突发打爆。
- 用厂商标称/压测理想值当生产容量，忽略 GC、抖动、共享租户。
- 扩容了应用却没扩 DB/连接池，瓶颈转移后照样雪崩。
- 没有压测验证，规划全靠线性乘法，遇到非线性拐点严重失准。
总结
容量规划从测准基线和单请求资源成本出发，用增长趋势预测峰值、用真实压测找到 P99 和错误率的拐点容量，再按「坏掉一台后剩余实例仍扛得住峰值」设定 70% 左右水位线与自动扩容触发、用限流降级兜底；务必按峰值而非均值规划、沿调用链逐层用 USE 排查瓶颈，并从核心接口的一次压测和一条扩容预警开始落地。