本文综合盘点各大公司团队的全链路压测技术方案和实践路径，供大家参考。
全链路压测指的是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。常用于复杂业务链路中，基于全链路压力测试发现服务端性能问题。
一般来说，全链路压测：
全链路压测与传统压测的区别：
哪些场景适合全链路压测：
行业内全链路压测方案对比：
方案一：流量混布, 存储隔离, 线上施压
对线上服务压测，压测前根据容量预估和压测目标，对线上服务进行扩容和 cpu、mem 等相关配置的变更。
压测产生的数据与线上真实数据做隔离，采用影子库表的方式，防止污染线上真实存储。
需构造压测数据和压测流量，通过压测标记来区分流量属性。
方案二：对数据本身做标记, 逻辑隔离，线上施压
对线上服务施压，与方案一的区别在于数据隔离上，不是通过影子库表，而是在原表上增加标记，做逻辑隔离。
业务需要做适配工作来识别流量属性。
方案三：镜像环境 OR 线下压测
此方案在线下进行压测，部署线下测试环境或镜像环境。
线下环境稳定性不高，硬件资源和压测数据线上线下差异大，压测结果参考价值有限。
货拉拉技术团队的实现思路：
在构思初始方案时，我们在行业内寻找并比对类似的解决方案，但是发现相关资料较少。由于全链路压测和压测自动化都需要与公司业务和内部平台频繁交互，我们在考虑改造全链路压测自动化时，决定结合公司业务特点和现有全链路压测流程以及内部平台特性进行改造。
为实现全链路压测的自动化，主要目标是把人工操作的重复工作自动化。在确定整体方案后，我们详细梳理了全链路压测前、中、后的常见工作场景，并确认了对应的需求以及平台服务支撑。以下是我们的整体改造思路图。
梳理出改造场景中的重点和难点问题，我们需要着重完成以下功能：
模型建模与模型效果对比： 无论是在压测场景和流量的配比，还是在压测后的效果对比中，都需要我们找到一个适合的模型算法，以确认压测场景的模型以及对比压测效果。
压测任务编排： 在压测任务中，一些任务有固定的时间顺序或因果关系顺序。这就要求我们需要有一个灵活的任务编排系统，方便自由地编排相关压测任务。
压测任务调度： 以货拉拉货运全链路压测为例，每次涉及到超 70 个脚本，300 余台压测机，以及数百万订单的压测目标流量。因此，如何对测试场景、脚本和测试数据以及压测流量进行有效的管理、分发和收集显得尤为重要。
健全的熔断机制： 既要检测出系统瓶颈，又要在出现异常时及时停止压测流量，以避免引发更大的生产问题，因此需要一个健全的熔断机制。
B 站技术团队的实现思路：
bilibili 全链路压测改造之全链自动化测试实践（点击看全文）
B 站的全链路压测方案，简单来说主要为流量混部、线上压测和存储隔离三个部分：
流量混部
线上压测
存储隔离
直播的全链路压测架构图如下，可以看到整体链路，由压测平台施压，被压测的服务接入压测 sdk，获取到由压测规则控制台下发的压测配置信息，根据配置信息对接收到的压测流量做处理，如配置了镜像规则的数据表，压测数据写入影子表，对配置了镜像规则的 redis,压测的缓存数据写入影子 key 等等。
针对此链路上如此多的服务改造点（SQL 改造、redis 改造、databus 改造、job 改造、context 改造、go channel 改造、sync/pipeline 改造...），如何能又快又好又全面的测试覆盖，是我们设计全链自动化测试方案的初衷，我们将其主要分为三个阶段。
第一阶段，我们对各个新增节点分别做了测试保障，如 mirror sdk、压测配置控制台等，保正底层基础能力的正确性。
第二阶段，当基础建设已完成，进入到了业务接入及全流程验证阶段。业务是不停迭代的，其中随着基架的不断演进，业务所涉及的服务也包含了部分历史债，当此套框架真正接入业务后，我们往往在业务实际使用中会发现很多不适配的地方，包括框架设计不够健壮或者业务的使用姿势不规范等原因，需要修复或兼容。这个阶段的测试也是最繁琐、测试量最大、重复性很高的地方，为此全链自动化测试全面应用于此阶段，来提升效率及业务覆盖度。
第三阶段，主要应对于未来的拓展，随着全链路压测覆盖的业务越来越多，当” 常态化 “的全链路压测计划提上日程，重复的工作和人力成本随之增加。此时测试工具更需要平台化及可视化，为压测前、压测中、压测后各个阶段的重复工作提供有效的自动化支持。
主要介绍字节跳动的服务端全链路压测体系，以及字节跳动各种业务的全链路压测实践。
2.美团--全链路压测平台（Quake）在美团中的实践
美团--全链路压测自动化实践
全链路压测是我们准确评估整个系统性能水平的必经之路。目前，美团内所有核心业务线都已接入全链路压测。Quake（雷神之锤）作为公司级的全链路压测平台，它的目标是提供对整条链路进行全方位、安全、真实的压测，来帮助业务做出更精准的容量评估。
从 2020 年开始滴滴网约车压测团队开始重点建设压测仿真度量体系，并实现工程化落地应用，本文将系统化介绍滴滴网约车全链路压测仿真度量体系建设过程。
4.阿里淘宝--全链路压测体系建设方案的思考与实践（点击看全文）
阿里云--PTS 3.0：开启智能化的压测瓶颈分析（点击看全文）
5.得物 -- 压测平台在全链路大促压测中的实践（点击看全文）
得物压测平台一直在持续完善和提升中，希望本文能抛砖引玉，提供压测平台建设方面的一些参考经验。
目前已多次支持公司级各类大型活动的仿真全链路压测，为线上服务的稳定运行提供了强有力的质量保障。经过多年的打磨如今借此机会与大家分享一下心路历程，积极讨论，欢迎提出意见，希望可以帮助我们进一步成长。（文中引用均为测试数据）
为推进常态化压测更高效，更贴近业务进行压测，且分化所有业务流量的焦点集中在大促压测上，转转团队把一些常规压测操作前置到日常业务迭代需求项目上，根据中、大规模的需求项目试行迭代式压测，提供更细致、更小范围的压测方式，尝试解决在压测上的时效和人力问题。
9.中国人寿业务稳定性保障：“1+1+N” 落地生产全链路压测（点击看全文）
将于2024年7月20日在上海举办的 MTSC2024 第十三届中国互联网测试开发大会，7 折优惠购票限期发售中！ 了解详情
