全链路压测是将完整业务路径作为有机整体进行端到端验证，核心在于还原真实流量、隔离影响、多维指标关联及聚焦事务级表现，而非接口级qps；需以tps为单元建模用户行为，注入染色标识贯穿链路，通过影子库、隔离队列、统一监控时间戳保障环境真实性，并依p99 rt拐点、火焰图与资源指标联动精准定位瓶颈，最后闭环验证优化效果是否达成tps与p99 rt组合目标。
全路径压测分析不是简单加压，而是把整个业务链路当作一个有机整体来验证和诊断。关键在于还原真实流量路径、隔离压测影响、关联多维指标，并聚焦事务级而非接口级的表现。
明确压测对象：从TPS出发定义“一条完整路径”
下单、支付、查询订单等用户动作才是压测的基本单元。一个TPS对应一次端到端事务，可能触发网关路由、多个微服务调用、缓存读写、数据库事务、第三方回调等多个环节。不能只看单个接口QPS，否则会漏掉跨服务延迟叠加、线程池争抢、连接池耗尽等典型瓶颈。
- 用业务语义建模流量：比如“每秒100单”，而不是“每秒500次HTTP请求”
- 在请求头注入染色标识（如X-Pressure-Test: true），确保链路追踪能贯穿所有中间件与存储
- 校验事务完整性：下单成功后必须完成库存扣减+日志落库+消息发出，任一环节失败即视为该TPS失败
构建可观察的压测环境
环境失真，结果就失效。影子库、隔离队列、旁路日志是基础配置，但更重要的是监控数据的统一归因能力。
- 数据库使用影子表或逻辑隔离，敏感字段（手机号、身份证）必须脱敏，且脱敏逻辑需与生产一致
- 消息队列启用独立Topic或Tag标记，避免压测消息误触真实下游
- APM（如SkyWalking）与基础设施监控（CPU/内存/磁盘IO）时间戳对齐，误差控制在±50ms内
- 所有服务开启详细慢调用采样（如RT > 200ms自动抓取堆栈+SQL）
分层定位瓶颈：按响应时间分布切片分析
不要只盯着平均RT。P99响应时间飙升时，往往意味着某个节点在长尾场景下彻底失能——比如数据库锁等待、GC停顿、网络抖动或缓存穿透。
- 先看P99 RT拐点：当TPS从2000升至2500时，P99 RT从400ms跳至2.1s，说明此时已触达某环节容量阈值
- 再查火焰图热点：对比基线与压测中的调用链，识别耗时突增的服务节点与内部方法
- 最后做资源关联：若某服务P99 RT上升同时JVM Full GC频率翻倍，或数据库连接池活跃数达上限且慢SQL数量同步激增，即可锁定根因
闭环验证优化效果
改完不验证，等于没改。每次优化都应设计对照实验，用相同TPS梯度重跑，观察关键指标是否收敛。
- 例如针对数据库连接池耗尽问题，扩容后需验证：连接池活跃数回落、慢SQL减少、对应服务P99 RT下降幅度是否匹配预期
- 缓存优化后，重点看缓存命中率是否提升、后端DB QPS是否同步下降、以及缓存击穿类错误日志是否归零
- 所有优化必须回归到TPS与P99 RT的组合目标：比如“支撑3000TPS下P99 RT ≤ 800ms”
