全链路压测的演进之路——深入浅出全链路压测

全链路压测的演进之路

1.2全链路压测的演进之路

全链路压测的理念最早是由阿里巴巴提出的，它的效果在“双11”大促活动的容量保障工作中得到了充分的验证，自从2013年全面推行全链路压测以来，“双11”大促活动期间，电商系统的稳定性有了明显提升。

不过，“罗马不是一日建成的”，全链路压测也是经历了多次探索和变革才发展到目前阶段的。让我们一起回顾过去，看一看全链路压测的演进之路，这些“历史”有助于我们更好地理解全链路压测。

1.2.1  基线容量测试

全链路压测需要在生产环境中实施，才能避免环境差异造成的压测结果失真。但在生产环境中进行压测也会带来额外风险，因此，在实施全链路压测时，我们需要对系统进行数据隔离，并辅以各种技术改造工作和监控工作。

在不具备这些能力之前，有一种方法可以让我们在测试环境中以较低的成本先“定性”地识别出系统可能存在的容量隐患，这种方法称为基线容量测试。

基线容量测试的具体做法是，按照与生产环境相同的部署方式搭建一套测试环境（以下简称基线环境），其中涵盖必需的中间件和网络设施，资源规模可以按生产环境的规模等比例减少。

之后，将各服务的主干版本部署到基线环境上，通过压测的方式获取系统的容量指标并记录备案，这些指标称为“基线指标”。

首先，我们假定基线指标是符合系统的容量要求的，当系统服务准备发布新版本时，我们就可以在基线环境上部署这个新版本，以相同的标准进行压测。

然后，将结果指标与基线指标进行对比，如果某些关键指标出现大幅异动，如响应时间大幅增加、CPU利用率大幅增加等，就需要技术人员介入以排查系统的风险。

基线容量测试可以在一定程度上提前发现系统潜在的容量隐患，但是由于基线环境与生产环境不完全对等，因此，我们既无法对服务容量进行定量评估，也无法为限流设置、超时设置等容量治理工作提供参考。

1.2.2  集群缩放压测

更有效要更真实地评估系统服务的容量情况，我们还是要在生产环境上做压测。

集群缩放压测是一种在生产环境中进行系统服务容量评估的早期实践，它的做法是逐步缩减集群内的服务器数量或实例数量，使得单台服务器或单个实例所承载的流量不断增加，从而评估出集群可承载的最大流量，并以此推算出单位流量增长所需扩容的服务器数量或实例数量。

集群缩放压测的优势是很明显的，它基于系统的线上真实流量，我们不需要编写任何压测脚本，也不需要准备任何压测数据，压测过程中也不会产生脏数据。

但它的劣势同样明显，首先，系统线上操作的风险比较高，一旦集群规模被缩减至瓶颈点，容易引发系统的线上事故；其次，由于集群缩放压测基于系统的线上真实流量，因此对流量规模有一定要求，如果流量太小，当集群缩减到单服务器或单实例后依然没有达到容量瓶颈点，就无法推测容量情况。

集群缩放压测还存在一个“致命伤”，即无法对底层基础设施（如数据库、消息队列等中间件）的容量进行评估。虽然我们缩减了应用服务的集群规模，但这些基础设施的资源规模是不变的，在外部请求量恒定的情况下，依然无法评估它们的容量情况。

1.2.3  流量回放

集群缩放压测只能作为技术人员简单用来摸底系统服务容量的手段，不能满足人们对系统整体容量评估的要求。于是，人们又提出了另一种手段——流量回放，它的做法是先将用户的真实请求记录下来，再将请求的TPS/QPS放大一定倍数后重新执行请求，达到压测的目的。

与集群缩放压测类似，流量回放同样基于用户的真实请求，不需要准备压测脚本和压测数据。我们可以通过调整TPS/QPS倍数来灵活控制压测量，这是流量回放最大的优势。

不过，与集群缩放压测不同，流量回放重新执行了一遍请求，我们需要确保请求是“无副作用的”，即不会修改或新增数据，否则会导致数据被污染。因此，流量回放通常只适用于系统部分无状态的“读请求”，无法应用在“写请求”上。

尽管如此，流量回放依然是一种进步很大的实践，在某些“读场景”较多的业务链路压测工作中，它的应用比较广泛。

1.2.4  单链路压测

随着微服务架构的日益盛行，系统中的服务调用关系错综复杂，一个服务可能会被多个服务所依赖，因此，需要以链路的视角来看待服务容量。服务之间的调用链路如图1.3所示。

单链路压测的做法是根据业务场景和服务调用情况，划分出局部调用链路后，单独对其进行压测。

单链路压测是全链路压测的雏形，用此方法时，我们也要对系统中的数据进行隔离和实施技术改造工作，但由于单链路压测在系统中实施的范围较小，一般都能够在少量业务域内闭环完成，因此单链路压测更容易实施和落地。

不过单链路压测仍然无法评估系统整体的容量情况，这是因为系统整体的容量不是由多条“单链路”的容量简单相加而得到的。

服务的容量除了受自身影响，还受依赖服务的影响，而依赖服务又可能有其他调用方，甚至是一些外部服务，这些影响经过累积后，最终的影响范围极难判断。

而单链路压测由于缺少外部干扰和资源竞争，容易得出“偏优”的压测结果，不能反映系统的真实承载能力。

因此，我们需要从系统全局视角出发，对整体业务链路和多种业务场景实施全链路压测，这样才能最真实地反映系统的容量情况。

由此可见，全链路压测正是在人们的不断实践和探索的过程中逐渐演进出来的。图1.4对这一过程进行了总结，并展示了与全链路压测演进相关的周边技术。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

 ​​​​软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。