深色模式
负载模型建立
负载模型是一组公式：业务量 → 请求量 → 资源消耗 → 实例数。建好之后每次业务给新目标，套公式就能算出要多少台机器。
适用环境
- 能取到监控中的请求量与资源使用率
- 有至少 2 周的历史数据
- 已知道业务的增长计划
bash
# 导出最近 7 天每分钟请求数（Prometheus HTTP API 区间查询）
curl -s 'http://localhost:9090/api/v1/query_range' \
--data-urlencode 'query=sum(rate(http_requests_total[1m]))' \
--data-urlencode 'start=2026-10-02T00:00:00Z' \
--data-urlencode 'end=2026-10-09T00:00:00Z' \
--data-urlencode 'step=1m' -o qps.json1
2
3
4
5
6
2
3
4
5
6
操作步骤
1. 定义业务量指标（Business Driver）
选一个业务方能理解、且和流量强相关的指标，常见有：日订单数、日活用户、日播放时长、设备数。
text
示例：日订单 500 万笔1
2. 计算单业务量对应的请求数（Conversion）
bash
# 从网关日志统计：一笔订单对应多少次后端请求
awk '{print $7}' access.log | grep -c '/api/' # 请求总数
# 换算：请求数 / 订单数 = 每笔订单的请求放大倍数
echo "scale=2; 42000000 / 5000000" | bc # → 8.4 次/笔1
2
3
4
2
3
4
3. 计算峰值 QPS
text
日均 QPS = 日订单数 × 放大倍数 / 86400
= 5000000 × 8.4 / 86400 ≈ 486
峰值 QPS = 日均 QPS × 峰值系数
= 486 × 6 ≈ 2900 # 峰值系数取历史 P99/均值1
2
3
4
5
2
3
4
5
峰值系数不要猜，从监控里算：
bash
# 取 7 天内的最大值与平均值之比
jq -r '.data.result[0].values[][1]' qps.json | awk '
{s+=$1; n++; if($1>m||NR==1) m=$1} END{printf "avg=%.1f max=%.1f ratio=%.2f\n", s/n, m, m/(s/n)}'1
2
3
2
3
4. 计算单请求资源消耗
bash
# 在压测环境中取稳定的 QPS 与 CPU 使用，算单请求 CPU 成本
# 单位：CPU 秒 / 请求
echo "scale=6; 2.4 / 600" | bc # 2.4 核 CPU 支撑 600 QPS → 0.004 core·s/req1
2
3
2
3
同理算内存（GB/实例）、存储（GB/订单）、带宽（KB/请求）。
5. 汇总成模型表
| 项 | 公式 | 值 |
|---|---|---|
| 日订单 | 业务给定 | 5,000,000 |
| 放大倍数 | 日志统计 | 8.4 |
| 日均 QPS | 订单×倍数/86400 | 486 |
| 峰值系数 | 历史 max/avg | 6 |
| 峰值 QPS | 日均×系数 | 2900 |
| 单请求 CPU | 压测得 | 0.004 core·s |
| CPU 需求 | 峰值QPS×单请求 | 11.6 核 |
| 实例数 | 需求/(4核×70%水位) | ≈ 5 台 |
6. 用增长计划外推
text
3 个月后订单 +45% → 峰值 QPS ≈ 4200 → 需求 16.8 核 → 7 台1
验证
bash
# 回测：用上个月的订单数套模型，对比实际机器数是否吻合
echo "模型误差 = |预测实例数 - 实际实例数| / 实际实例数"1
2
2
误差应 < 20%。超过说明放大倍数或峰值系数需要重新采集。
常见坑
用平均值建模型
日均 QPS 建出来的模型在峰值时会直接崩。模型必须建立在峰值上，平均值只用来算成本。
放大倍数一成不变
新增功能、加缓存、加重试都会改变放大倍数。每次大的架构变更后要重新统计一次。
忽略写放大
一次用户请求可能触发多次 DB 写、MQ 投递、下游调用。只统计入口 QPS 会严重低估 DB 和 MQ 的容量需求，必须分层建模。