全链路压测以真实业务事务为单元，在生产环境安全摸清系统极限；需染色标识贯穿链路、校验事务完整性、构建隔离环境、对齐监控时间戳、分层定位P99拐点与根因，并闭环验证优化效果。
高可用架构做全链路压测，不是把所有服务一起加压看谁先挂，而是以真实用户行为为单位，端到端跑通整条业务路径，在生产环境安全可控地摸清系统真正的极限点。
用业务事务定义压测单元
别再盯着单个接口的QPS。下单、支付、查订单这些完整动作才是压测的基本单元。一个TPS代表一次真实用户操作，背后可能触发网关路由、3个微服务调用、Redis缓存读写、MySQL事务提交、Kafka消息发出等多个环节。只压单个接口，会漏掉线程池争抢、连接池耗尽、跨服务延迟叠加等典型瓶颈。
- 建模按“每秒100单”设计，而不是“每秒500次HTTP请求”
- 在请求头注入染色标识（如 X-Pressure-Test: true），确保链路追踪贯穿网关、服务、中间件、数据库
- 校验事务完整性：下单成功必须同步完成库存扣减+日志落库+消息发出，任一环节失败即判定该TPS失败
构建真实且隔离的压测环境
环境失真，结果就无效。影子库、隔离队列、旁路日志是底线配置，但更重要的是让监控数据能统一归因。
- 数据库用影子表或逻辑隔离，敏感字段（手机号、身份证）必须脱敏，且脱敏逻辑与生产完全一致
- 消息队列启用独立Topic或Tag标记，避免压测消息误触真实下游
- APM（如SkyWalking）与基础设施监控（CPU/内存/磁盘IO）时间戳对齐，误差控制在±50ms内
- 所有服务开启慢调用采样（如RT > 200ms自动抓取堆栈+SQL）
分层定位P99 RT拐点与根因
平均响应时间掩盖问题，P99飙升才暴露真实瓶颈。当TPS从2000升到2500时，P99 RT从400ms跳到2.1s，说明某个环节已触达容量阈值。
- 先看P99 RT拐点：识别TPS与延迟突变的临界点
- 再查火焰图热点：对比基线与压测中的调用链，定位耗时突增的服务节点和内部方法
- 最后做资源关联：若某服务P99上升同时JVM Full GC频率翻倍，或数据库连接池活跃数达上限且慢SQL数量激增，即可锁定根因
闭环验证优化是否真正生效
改完不验证，等于没改。每次优化都需设计对照实验，用相同TPS梯度重跑，观察关键指标是否收敛。
- 例如扩容数据库连接池后，需验证：连接池活跃数回落、慢SQL减少、P99 RT回归基线、TPS稳定达标
- 限流策略上线后，要验证：流量被精准截断在预定水位，下游服务压力未超阈值，错误率未异常升高
- 破坏性测试阶段，保持峰值压力，执行预案（如降级开关、熔断触发），确认系统行为符合预期
