深色模式
容量规划方法论
容量规划回答三个问题：业务要多少、单实例能扛多少、要留多少余量。本文给出一套可落地的三段式流程：需求 → 模型 → 冗余，最终产出一份能直接下单的资源清单。
适用环境
- 已有基础监控（Prometheus + node_exporter 或云监控）
- 服务为无状态 HTTP 接口，或有明确的主从/分片结构
- 能拿到业务侧的日活、峰值 QPS 等粗略数字
bash
# 确认监控数据可用，取最近 1 小时 CPU 均值
curl -s 'http://localhost:9090/api/v1/query' \
--data-urlencode 'query=avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))' | head -c 4001
2
3
2
3
操作步骤
1. 收集需求（Demand）
先问业务拿四个数字，不要一上来就看资源：
| 指标 | 说明 | 示例 |
|---|---|---|
| 峰值 QPS | 一天中最高的每秒请求数 | 2000 |
| 峰值持续时长 | 高峰持续多久 | 30 分钟 |
| 增长率 | 按月/季度环比 | 每月 +15% |
| 目标延迟 | P99 延迟上限 | 300 ms |
没有监控历史时，用「日活 × 人均请求数 / 86400 × 峰值系数（一般取 5~10）」粗估峰值 QPS。
2. 建立模型（Model）
用压测得出单机能力，再换算成实例数：
bash
# 单机能力：逐步加压直到 P99 超标，记录拐点 QPS
wrk -t4 -c100 -d60s --latency http://10.0.0.11:8080/api/order1
2
2
text
单机上限 QPS = 拐点 QPS # 例：600
实例数 = ceil(峰值 QPS / 单机上限 QPS)
= ceil(2000 / 600) = 41
2
3
2
3
3. 叠加冗余（Redundancy）
冗余不是随便加，要分清楚加在哪一层：
text
最终实例数 = 业务实例数 × (1 + 性能余量) + 容灾余量
性能余量：留 30%，即水位不超过 70%
容灾余量：N+1，或跨可用区时 × 2
示例：4 × 1.3 ≈ 5.2 → 6 台（含 N+1）1
2
3
4
5
6
2
3
4
5
6
4. 输出资源清单
text
服务：order-api
峰值 QPS：2000（P99 < 300ms）
单机能力：600 QPS（4C8G）
需求实例：4 → 含 30% 余量 6 台
容灾：跨 2 可用区，各 3 台
下次复审：2026-12-011
2
3
4
5
6
2
3
4
5
6
验证
bash
# 1) 水位验证：实际峰值 / 容量 应 ≤ 70%
# 2) 冗余验证：任意宕一台，剩余水位仍 ≤ 85%
echo "单机能力 600，峰值 2000，4 台理论水位 = $(echo 'scale=1; 2000/4/600*100' | bc)%"1
2
3
2
3
常见坑
拿均值当峰值
平均 QPS 会严重低估容量需求。所有计算必须用峰值（P99 或日最高点），均值只用于算成本。
单机能力用开发环境压测
开发机规格、数据量、缓存命中率和生产完全不同。压测必须在与生产同规格的环境做，否则模型整体偏乐观。
冗余层层加码
性能余量、容灾余量、突发余量各自加 30%，最后翻一倍。冗余要一次性算清并写进文档，避免"每个人都加点保险"导致成本失控。