【压力测试】要不要做全链路压测？

浅谈行业近况

在开始全链路压测学习前，我们先来简单介绍一下当前全链路压测行业近况。在互联网行业中，我发现一个很风趣的征象：

• 认识大概了解性能测试的人，大概有50%；
  
• 而在这50%人群中，夺目性能测试的，仅仅有20%；
  
• 而在这20%的性能测试人中，做过全链路压测不足的5%。
  

这是一个很尴尬的结果。我曾经介绍过，性能测试是一个综合性学科，一个人是做不来的。
而全链路测试呢，我们或多或少在网上搜索关于全链路压测的文章，无非就以下几个特点：

• 目标和方案只有摘要级的说明；
  
• 全链路压测平台没有细节描述，很笼统；
  
• 只有少之又少的大厂一些笼统的资料，也没有投入本钱(例如：职员本钱、资金本钱、时间本钱)的数据；
  
• 没有架构级全链路改造细节；
  
• 没有架构级监控平台范围的细节；
  
• 没有性能分析逻辑的细节。
  

以是，看过这些文章，可能照旧一头雾水。起首，不知道自己的企业是否能支撑全链路压测；其次，不知道应该怎样具体实行；第三，不知道怎样计算投入的本钱。
我说了这么多，可能还有的同砚照旧不理解，我再举个例子：某企业为了跟潮流，要做全链路压测，但是由于本身的限定，并不具备全链路压测的条件，只做了一些小的动作，在线上镌汰覆盖范围并分段进行压测，末了的结果，可想而知，这完全失去了全链路压测的根本代价。
全链路压测的出发点是对线上的真实体系做改造后直接在线上压测！现实上的全链路压测的落地，是需要经过各种综合考量后的结果，从整个全链路项目来看，上到公司BOSS，下到各个工程师都需要全部参与进来。换句话说，全链路涉及到脚色如下：

• 公司BOSS
  
• 产品经理
  
• 架构师
  
• 开发工程师
  
• 测试工程师
  
• 运维工程师
  

不同的岗位，关注点也不同：

• BOSS：全链路压测带来的业务容量提升和企业利润增长；
  
• 产品经理：业务容量的增长和后续功能的计划；
  
• 架构师：全局架构计划对全链路压测的宏观支撑；
  
• 开发工程师：业务细节和技术细节的改造；
  
• 测试工程师：覆盖住这些改造；
  
• 运维工程师：全链路改造和线上的压测过程对体系整体状态的影响。
  

以是，怎样掌握全链路压测的重要性，就不问可知。在当今全链路压测趋势下，我们要做的，不但仅是怎样进行全链路压测，还需掌握，怎样统筹搭建运行全链路压测。接下来，我们就来认识下，什么是全链路压测，全链路压测的难点及目标。
初识全链路压测

全链路压测的难点

很多人以为全链路压测的难点，是不是怎样搭建情况，怎样进行压测？不然，其实全链路压测的难点是管理协调。
为什么这么说呢？上面也提到了，全链路压测涉及到脚色多、体系多、链路长，以是一定导致相比力而言，技术的实现就是细节的落地过程，斲丧的只是职员和时间本钱。
全链路压测的目标

在性能领域中，全链路压测一直都是大厂的利器，也是让小厂趋之如骛。以是，我们就要来看下，全链路到底有什么神奇的功效，在互联网的公司有这么高的热度。
要理解这一点，我们得先看看全链路压测的目标：

• 全链路压测被称为体系整体容量保障的核武器；
  
• 全链路压测可以实现生产情况的压测服务，模拟真实的生产峰值场景，以发现真实的线上瓶颈并实现监控分析；
  
• 全链路压测可以实现精准的容量规划，确保线上体系的正常运行；
  
• 全链路压测可以实现海量的并发哀求，以模拟真实的用户峰值场景；
  
• 全链路压测可以实现压测流量和生产流量的隔离，避免对生产流量产生影响；
  
• 全链路压测可以主动化压测，镌汰人工本钱，并提高压测频率，快速发现标题。
  

看完这些，你应该就能知道，为什么全链路压测会有这么神奇的功效了。
其实这些还没完，如果你是在性能领域多年，那么多多少少会看过一些全链路压测的文章，而这些文章中，通常都会涉及到一些阿里、字节、美团、滴滴、京东等大厂的信息。而这些文章末了给人的感觉就是：为了增长体系运行安全性，全链路压测是企业必须要做的一件事情。
既然全链路压测这么好，我们要不要跟风呢？想要了解一件事情，就是去拆解这件事，以是，我们接下来就来拆解全链路压测。
拆解全链路压测

我们先来拆解一下全链路压测，啥是“链路”？简单点说就是几个点连成的线。这个词在IT行业中非经常用，但是在性能行业中，却是近几年才被广泛利用的“新词”。要讲链路，就得说到微服务分布式架构的发展。
一开始，在微服务分布式架构还没有流行起来的时间，人们大多利用SOA架构，它大概的技术架构是这样的：

体系之间的调用，都会通过ESB，因为调用的链路比力短。进入到微服务分布式架构之后，由于微服务被拆得越来越细，大概的技术架构就变成了下图所示的样子：

这里的流程图只是举个例子。从图上可以看到，链路变长了，这是大流量带来的体系拆分导致的。在这种情况下，识别标题也就更加困难了。
我们来总结一下这两个架构图：

• 原来一个体系的功能点多，现在一个体系功能点少；
  
• 原来测试一个体系就有一堆的业务逻辑，现在测试一个体系只有很简单的业务逻辑；
  
• 原来一个体系就可以完成的业务操纵，现在得跳好几个体系才气实现。
  

在互联网的初期，压测重要关注单体系接口，而这完全不能说明体系处理业务的容量本事。随着业务的大规模发展，性能也必须做到覆盖“全部”体系，“全链路”这个概念就显得格外重要了，它指的是体系的全链路。说到这，“全链路”的内涵就解释得差不多了，那说到压测，就得有工具、有平台。
为了加深理解，我们再通过全链蹊径上压测与传统线下压测做对比：

从表中，我们可以大抵看出来，全链蹊径上压测与传统线下压测的区别点。当然，线下也可以利用脱敏的生产数据，这没有固定的要求。
其实最关键的一点区别，就是线上照旧线下。其他的区别也可以不算是区别，因为那些区别点都是可以平衡掉的，比如说压力场景、铺底数据、监控手段等，关键在于投入多少。
投入的内容包罗了：体系的改造投入、职员的投入、情况的投入、时间的投入。
到底要不要全链路压测

现实上，要不要利用全链路压测，需要充分思量企业的现实条件，我们可以通过以下几个标题来入手。
1、企业有没有那么大的流量需求？

如果不到几十万、上百万、上万万/每秒的交易量，其实完全不用思量全链路压测平台的实现逻辑。如果你只是以为这逻辑听起来更高大上而去实现它，那投入的本钱等于说是打了水漂。
2、你的体系要不要做全链蹊径上压测？

如果不是在线上做全链路压测，那很多业务流量的改造工作就可以完全忽略。甚至，我们都不用思量改造什么压力工具，这就是给自己找麻烦。
3、体系能不能做全链蹊径上压测？

在网上可以看到，全链路压测90%都是互联网大厂。为什么呢？起首是因为哀求量大；其次，做全链蹊径上压测的体系，纵然出了标题，也不会对企业利润产生太大的影响，这一点至关重要。
4、组织支持不支持你做真正的全链蹊径上压测？

在全链蹊径上压测这件事情上，一定不是底层干活的人（部门经理及以下）可以决定的。全链蹊径上压测是需要企业上下层协调同等才可以做得到的。
如果向导只是给你安排了一个做全链蹊径上压测的任务，但没有给你具体的权限支撑，是不可能做得下去的。而恰好有很多上层向导就是这种光安排任务，不给具体支持的风格。
这时，你得跟向导具体沟通一下，把本钱利弊都分析清晰。如果从企业角度思索后，你们同等认为全链路压测是必须要做的，那就需要向导更具体的支持才行，不然可能很难推进。
通过以上4点，我相信，你会放弃当初的想法，以为自己的公司，并不适合做全链路。但是，针对别的一些企业，全链路压测是不可或缺的，因为它能办理以下三个标题：

• 直接利用生产情况，避免了情况的差异性；
  
• 实现高并发广域网压测平台，模拟了真实的用户场景；
  
• 不用进行线下线上容量的推算。
  

传统的线下压测显然做不到这三点。如果以上三个标题对企业的影响较大，那么全链路压测就很有必要了。
全链路压测涉及改造点

上面说到，全链路压测对某些企业必不可少的，但是，凡事都有利与弊，做全链路压测，就涉及到改造，具体有哪些，我们一起来看。
压力工具改造

这就涉及到流量标题。如果你的压力场景只需要万级每秒以下的哀求量级，其实不需要做工具改造，传统工具就能做得到。但是如果需要更大流量，就得对压力工具进行改造了。压力工具改造的内容有哪些呢？

• 压力发起部门：重要是多节点分布式的改造；
  
• 参数化部门：重要是数据量大引起的改造需求。
  

在传统的压测工具中，根本上都是利用Master-Slave的方式，master负责拆分参数化数据，但当数据量过大的时间，显然这是个标题点。
改造的部门只有这两点，在其他的功能点上传统的压力工具是可以覆盖大流量的压测需求的。
业务流量改造与隔离

在业务流量的改造与隔离，一般有两种方法：

• 实现全链路的压测流量识别，从而实现隔离；
  
• 只在入口做压测流量的识别，直接旁路到另一套独立的链路中去。
  

1、全链路压测流量识别

• 业务标识改造的目标：实现业务流量的隔离；
  
• 业务流量隔离的目标：不让压测流量影响真实的线上用户。
  

贯穿业务改造的关键是整个业务流的识别跟踪，末了还可以方便地进行数据的清算。
具体业务改造需要包含的内容：

• 脚本改造：也就是加上流量标识，以实现后续的流量隔离。这一点任何一个压力工具都只需要加个参数即可，没有复杂度。
  
• 应用服务改造：这是改造工作量最大的部门。改造要实现的是对流量标识的识别，再把哀求旁路到相应的存储组件中去。
  应用的改造重要是对现有的业务代码进行入侵式的改造，增长业务开发的工作量。实现的手段就是跨线程透传，将压测流量写入ThreadLocal对象中。
  
• 中间件的改造：对于一些跨服务调用利用的中间件，由于需要对压测流量进行标识，以是也是需要改造的。
  
• 存储逻辑的改造：不管是缓存照旧数据库、队列，都要对压测流量进行识别，以便隔离。
  目标就是不影响生产数据。对缓存（比如Redis)，我们可以实现不同的key值；对数据库，我们可以实现影子表或影子库。
  
• 日志改造：压测流量的日志最好不要和生产日志在一起。
  

2、入口压测流量识别

针对入口做压测流量识别，改造方法，就相对简单：只要在网关做压测流量的识别即可，后面就全都是摆设的活了。
总结

面对全链路压测的优点，我们也要理性的分析有利用，不能盲目标跟风，不然只能拔苗助长。一切都要从现实地位出发，做符合现实的事情，才气得到正的代价。

末了感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，投桃报李总是要有的，固然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 

软件测试面试文档

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。