一、什么是全链路压测？
全链路压测是指在实际的生产业务场景和系统环境下，模拟海量的用户请求和数据，对整个业务链进行压力测试，并在此过程中持续调优。

二、全链路压测解决什么问题？
全链路压测旨在解决业务场景日益复杂化、海量数据冲击下，整个业务系统链的可用性、服务能力瓶颈等问题，目标是让技术更好地服务业务，创造更多价值。
在业务发展到需要进行流量预估和系统容量评估阶段，并完成初步容量评估后，仅靠这一步是否足够？答案是否定的。 真实的业务场景远比初步评估复杂。我们需要进行更精准的容量规划，为服务的限流降级策略提供坚实的数据支撑和参考依据。

三、什么时机下需要进行全链路压测？

业务快速发展期：
在可预期的一段时间内（通常建议提前半年规划，一个季度略显仓促），业务将迎来快速增长，线上服务资源（如服务器）必须进行大幅度扩容。
扩容效果并非总是线性的。例如，从两台扩展到四台，服务能力可能提升两倍；但继续扩容时，服务能力可能无法按比例提升，因为会受到其他关联模块（如数据库 DB、公共组件、中间件等）的限制。
补充说明： 随着业务持续发展，系统依赖的模块不断增多，需要通过全链路压测找出并解决系统短板。
系统链路复杂度显著提升：
通常，伴随业务发展，接口数量增加，系统逐渐向分布式架构演进。
业务线内部的模块抽象化程度提高、数量增多，与其他业务线的交互也日益频繁。
此时，无法单纯依据本系统的处理能力来评估其所提供接口的服务能力。
核心原理： 接口的服务能力取决于整个调用链路中性能最弱的那个环节——即木桶理论。
对单机压测结果信心不足：
单机压测虽是常规指标，但其结果往往无法代表真实的线上复杂场景。
当仅凭单机压测结果评估系统整体能力时，工程师的内心会越来越缺乏自信，此时即应考虑实施全链路压测。

四、如何展开全链路压测？
梳理核心链路与边界
核心链路是业务的核心流程，相对容易梳理清楚。
难点在于清晰界定链路的边界。
核心原则：必须严格防止污染生产环境正常数据。 需认真梳理数据处理的每一个环节，确保压测（Mock）数据及其处理结果完全隔离，不会写入正常业务库。
在核心链路基础上，存在诸多分支业务，其中部分可参与压测，部分则不能（如：向用户发送 Push 消息、短信/支付接口、微信 OAuth 授权等外部敏感操作）。
构建数据模型
数据真实性与可用性： 可从生产环境按比例移植一份数据作为压测基础数据包，并基于历史数据增长趋势分析，预估当前所需的数据量级。
数据脱敏： 在基于生产环境进行全链路压测时，必须考虑避免产生脏数据影响生产环境和用户体验，因此在数据准备阶段需进行严格的数据脱敏处理。
数据隔离： 核心原则：必须严格防止污染生产环境正常数据。通过将压测数据定向落入影子库/表、使用 Mock 对象等技术手段，确保压测数据流与真实业务数据流完全隔离。
搭建流量平台与改造
流量平台工具： 可选用 KylinPET、KylinTOP、JMeter、Ngrinder、Locust 等支持分布式压测的工具（如饿了么的流量平台基于 JMeter 改造）。平台需具备能力：实时收集并展示压测机数据、随时启停压测、在指定时间内实时错误率达到阈值时自动熔断。为应对大流量压测， 可考虑采用异步上传测试结果或事务补偿机制，以减轻 Agent 资源占用。
业务代码改造：
为压测请求打上特殊标记（如 HTTP Header 中添加 X-Shadow: true），该标记需随请求在系统间依赖调 * 链路上持续透传。
所有写操作（存储、缓存、消息、日志等）需根据标记路由至影子区域（影子库/表、影子 Key、影子 Topic 等）。
对于不能参与压测的外部依赖服务（如短信、邮件、Push 等），需进行 Mock 处理。
流量控制策略： 可采用真实流量录制回放（蓄水池），并按需分批释放，进行逐步压测。
容量规划
4.1 目的： 让每个业务系统清晰掌握：何时增/减资源？大促（如双 11）需准备多少资源？在保障系统稳定性的同时节约成本。
4.2 步骤：
业务流量预估： 通过历史数据分析未来特定时间点的业务访问量。
系统容量评估： 初步计算各系统所需资源量。
容量精调： 通过全链路压测模拟大促用户行为，在验证系统能力的同时精细调整各环节容量水位。
流量控制： 配置系统限流阈值等保护措施，当实际流量意外超过预估流量时，防止系统崩溃。
4.3 获取单机服务能力：
为精准获取单机服务能力，压力测试强烈推荐在生产环境进行。原因在于：单机压测必须同时保证环境真实性（生产环境配置）和流量真实性（生产环境流量特征）。
4.4 生产环境单机压测方法：
模拟请求：
工具： KylinPET, KylinTOP, Apache ab, Webbench, httpload, JMeter, LoadRunner 等。
适用场景： 新系统上线或访问量较低的系统。
缺点： 模拟请求与真实业务请求存在差异，影响结果准确性；写请求处理复杂（需接受数据污染或做特殊隔离处理）。
复制请求 (流量录制回放)：
适用场景： 系统调用量相对较小的场景。
优点： 压测请求更接近真实业务流量。
缺点： 同样面临写请求脏数据问题；被压测机器需独占（因需拦截响应，避免影响真实用户，尤其涉及外部触达如短信等）。
请求转发：
适用场景： 系统调用量较大的场景。
优点： 压测结果精准、不产生脏数据、操作便捷（在阿里巴巴广泛应用）。通过逐步增加转发流量比例，直至系统负载达到临界点，即可测得系统最大承压能力。
调整负载均衡权重：
适用场景： 系统调用量较大的场景。
优点： 压测结果精准、不产生脏数据。通过逐步调高目标机器的权重，增加其承接的流量比例，观察其负载直至瓶颈，测得单机最大服务能力。
自动化与参考价值：
可在上述方法基础上构建自动化压测系统，支持定时任务或手动触发。
压测时实时监控系统负载，达到预设阈值即自动停止并输出报告。
通过单机压测获取的单机服务能力 (QPS/TPS 等) 是容量规划的关键输入：
最小机器数 = 预估的业务访问量 / 单机服务能力

5、实施流程示例
流量标识： 业务系统需区分正常流量与压测流量。
实现方式： 在 HTTP Header 中设置标识字段（如 X-Shadow: true 代表压测流量；字段不存在或值不为 true 代表正常流量）。
流量透传：
在接收 HTTP/ gRPC 等请求时，识别压测标识。
在向下游发起请求时，若当前请求为压测流量，则必须将标识字段透传给下游 **，确保标识在整条链路中传递。
若识别到压测流量，则使用对应的压测数据源（影子区）。
依赖组件影子化处理：
MySQL： 使用影子表。压测流量对表 A 的操作自动路由至影子表 A_shadow。所有涉及的业务表均需建立对应的影子表，便于压测后清理。
MongoDB： 使用影子集合 (Collection)。处理逻辑同 MySQL 影子表。
Redis： 使用影子 Key。压测流量的 set key value 操作自动变为 set key_shadow value。处理逻辑同 MySQL 影子表。
Kafka： 使用影子 Topic。通常在 Topic 名后拼接 _shadow。处理逻辑同 MySQL 影子表。
外部依赖 Mock： 对于不参与压测的外部服务（如发送 Push、短信、支付、微信 OAuth 授权等），需进行 Mock 处理。