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

打印 上一主题 下一主题

主题 900|帖子 900|积分 2700

浅谈行业现状

在开始全链路压测学习前,我们先来简朴介绍一下当前全链路压测行业现状。在互联网行业中,我发现一个很有趣的现象:


  • 熟悉或者了解性能测试的人,大概有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企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

北冰洋以北

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表