全链路压测是容量规划的唯一实测依据，需在真实生产环境下验证整条链路在峰值流量下的数据一致性、时延可控性与系统稳定性，并以动态拐点为基线预留15%~20%缓冲空间，最终对齐用户可感知体验阈值。
容量规划不能只靠单点估算或理论相加，必须用全链路压测在接近真实生产环境的条件下“实测见真章”。它不是验证某个接口能不能扛住1万QPS，而是看从用户点击下单、网关路由、服务调用、数据库写入、消息落库、风控校验到最终支付成功这一整条链路，在峰值流量下是否不丢数据、不超时、不雪崩、不误限流。
用压测结果反推容量水位线
压测过程中要持续观察系统拐点：当并发量从5000升到6000时，订单创建平均耗时从200ms跳到800ms，错误率从0.01%飙升至3%，这就是实际容量临界点。这个拐点不是静态数字，而是动态水位线——它会随依赖服务状态、中间件配置、数据库连接池大小等实时变化。压测后需把该水位线作为容量基线，再预留15%~20%缓冲空间用于突发流量，才可纳入正式容量规划。
重点验证三类稳定性风险
• 级联失败风险：比如库存服务响应变慢，导致订单服务线程池打满，进而拖垮上游网关；压测中要打开全链路Trace，定位第一个出现毛刺的服务，并检查其下游是否同步阻塞等待。
• 资源争抢风险：多个核心服务共用同一数据库实例时，压测中可能出现慢SQL抢占连接池、锁表、主从延迟突增等问题；需结合DB监控（如InnoDB Row Lock Time、QPS/TPS、复制延迟）交叉分析。
• 预案有效性风险：提前配置的降级开关、熔断阈值、限流规则是否真能生效？例如在脉冲压测中触发限流后，应看到错误码集中为429且下游服务压力明显回落，而非错误分散、限流形同虚设。
把压测数据沉淀为容量决策依据
压测不是一次性动作，每次结果都要结构化归档：
• 明确记录各环节的SLO达成情况（如“支付回调链路P99≤1.2s，达标”）
• 标注未达标的瓶颈点及根因（如“风控服务CPU持续>95%，因规则引擎未做缓存”）
• 输出扩容建议颗粒度到具体组件（如“Redis集群需从3主3从扩至5主5从，支撑缓存命中率≥99.2%”）
这些数据直接输入容量管理平台，驱动自动化的资源申请、弹性伸缩策略和发布前的容量卡点校验。
不复杂但容易忽略的是：压测得出的极限值，必须和业务可接受的体验阈值对齐。比如系统能扛住8000并发，但此时首屏加载已超5秒、支付成功率降到92%，那这个“极限”就不具备业务意义。容量规划的终点，永远是用户可感知的稳定，而不是机器指标的漂亮数字。
