# 生产系统容量规划：从业务指标、压测模型到扩容阈值
容量规划不是简单地看 CPU 是否超过 80%，而是把业务增长、流量形态、依赖瓶颈和扩容提前量转化为可执行的资源计划。
## 一、明确业务容量指标
先收集日活、订单量、峰值 QPS、并发连接、请求/响应大小、读写比例、数据日增量、保留周期和增长率。对周期性业务至少覆盖工作日、月底、促销和突发热点。
峰值容量不能用日均值直接推算。建议使用：
设计峰值 = 历史峰值 × 增长系数 × 活动系数 × 安全系数
安全系数通常根据扩容速度和业务等级设置，自动扩容分钟级生效可适当降低，采购型资源则必须留出更大余量。
## 二、建立调用链容量模型
把入口 QPS 沿调用链拆分：网关、应用、缓存、消息队列、数据库、第三方接口。记录每个环节的放大系数，例如一次请求产生 5 次 Redis 查询和 2 次数据库访问。
使用 Little 定律估算并发：
并发数 ≈ 吞吐量 × 平均响应时间
但最终要以 P95/P99 延迟、排队长度和错误率作为饱和信号。
## 三、设计压测
压测数据分布、热点比例、读写比例、缓存命中率和对象大小必须接近生产。按基线、阶梯、峰值、突刺、稳定性五种场景执行：
1. 基线：验证脚本和监控。
2. 阶梯：逐级增加压力，找到拐点。
3. 峰值：验证目标容量。
4. 突刺：验证自动扩容与限流。
5. 稳定性：持续数小时观察泄漏、队列和磁盘增长。
压测期间同时观察应用线程池、连接池、GC、CPU throttling、网络带宽、磁盘延迟、缓存淘汰、数据库锁等待和副本延迟。
## 四、识别真正瓶颈
资源利用率高不一定是瓶颈，利用率不高也不代表安全。数据库单核饱和、连接池排队、磁盘 await、下游限流都可能先于总 CPU 告警。以吞吐停止增长且延迟陡升的点作为系统拐点。
## 五、制定扩容阈值
阈值要同时包含领先指标和结果指标。例如：预测 7 天后磁盘超过 75%、队列积压预计 20 分钟无法消化、P99 延迟连续 10 分钟超标、数据库连接池使用率持续超过 70%。
每个阈值都要绑定动作：自动扩容、人工审批、限流、降级或数据归档，并明确生效时间。
## 六、形成容量账本
按月记录当前容量、设计容量、最大实测容量、增长率、主要瓶颈、扩容提前量、负责人和下一次复测时间。重大版本、架构变更和营销活动前必须重新评估。
容量规划的最终交付物不是一张资源表，而是一套可验证的预测、压测、告警、扩容和复盘闭环。