容量规划总靠猜：后端系统压测、基线与扩容阈值完整方法

问题现象：平时资源浪费，高峰仍然扛不住

容量规划不是根据去年机器数量增加百分比，而是把业务预测转换为请求量、并发、数据增长和下游压力。首先区分平均流量、峰值流量和突发流量，识别读写比例、热点键、重任务和关键链路。只压一个接口无法代表真实生产混合负载。

建立单实例稳定基线

逐步增加压力，观察吞吐、P95、P99、错误率、CPU、内存、垃圾回收、线程池和连接池。当吞吐不再线性增长或尾延迟急剧上升时，已经接近饱和。生产容量应低于极限，保留故障切换、发布重启和流量波动的余量。

压测必须覆盖完整依赖

如果数据库、缓存和外部服务使用桩模拟，结果只能证明应用计算能力。全链路压测需要隔离测试数据、限制外部副作用，并监控每个依赖的容量。数据量也要接近生产规模，因为小表查询和热缓存会让结果过于乐观。

扩容阈值不能只看CPU

等待型服务可能 CPU 不高但连接池已经耗尽，消息消费者则应根据积压年龄扩容。选择与瓶颈直接相关且稳定的指标，并设置扩容速度、缩容冷却和最大实例数。扩容前确认数据库、网关和配额能够同步承受流量，否则应用实例越多，下游压力越大。

形成持续容量治理

记录每次压测的版本、配置、数据规模和结果，发布重大功能后重新建立基线。问：资源利用率保持多少合适？答：取决于恢复速度和可靠性目标，不能追求统一数字。问：云环境可以临时扩容是否无需规划？答：仍需考虑启动时间、配额和有状态依赖。可靠容量来自可测量的基线与定期演练，而不是高峰前的临时猜测。