容量规划必须通过全链路压测实测动态拐点，即响应时间跳升、错误率陡增而服务尚未崩溃的临界点，再乘以0.8预留20%缓冲作为正式容量水位线，并对齐用户可感知体验阈值。

容量规划不能靠估算，必须用压测实测出系统真实能扛住的上限。关键不是“系统崩没崩”，而是找到那个性能开始断崖式恶化的拐点——此时响应时间跳升、错误率陡增、资源使用率逼近临界，但服务尚未完全不可用。

用压力测试定位动态容量拐点

拐点不是固定数值，它随依赖状态、配置变更实时浮动。比如并发从5000升到6000时，订单创建P99从200ms飙到800ms，错误率从0.01%跃至3%，这个6000就是当前链路的实际容量临界值。压测中要持续阶梯加压（如每次+10%并发），每档稳定运行5–10分钟，同步采集全链路Trace和各层指标，才能准确定位拐点。

聚焦三类高发崩溃前兆

• 级联阻塞：库存服务慢了200ms，导致订单服务线程池打满，进而拖垮网关；需打开全链路Trace，看毛刺是否沿调用链向下传导
• 资源争抢：多个服务共用一个数据库实例，压测中出现慢SQL抢占连接池、主从延迟突增至5秒以上；要交叉比对DB监控（InnoDB锁等待、活跃连接数、QPS/TPS）
• 预案失灵：限流开关已开，但错误码仍分散在500/503/408，下游压力未回落；验证时必须触发真实脉冲流量，观察限流是否精准返回429且下游指标同步下降

把拐点数据转化为可执行的容量水位线

拐点值只是起点。实际容量基线 = 拐点值 × 0.8（预留20%缓冲）。例如拐点QPS为8000，则正式容量水位设为6400 QPS。这个数字要直接输入容量管理平台，驱动自动伸缩策略和发布卡点校验。同时必须对齐业务体验：若6400 QPS下支付成功率已跌破95%或首屏加载超5秒，那该水位就不具备业务意义，需回退优化瓶颈点再测。

避免常见误操作

• 不单独压单个接口，而是跑通“用户点击→网关→服务→DB→消息→回调”整条业务链路
• 不用RPS模式盲目冲峰值，优先采用并发模式模拟真实用户行为路径（如60%浏览+10%下单+5%支付）
• 不只看CPU/内存，重点盯数据库连接池使用率、线程池ActiveCount、Redis缓存命中率等易被忽略的隐性瓶颈指标