- 1、浅谈当前行业现状
- 2、初识全链路压测
- 2.1 全链路压测的难点
- 2.2 全链路压测的目标
- 2.3 拆解全链路压测
- 2.4 到底要不要全链路压测
- 3、全链路压测涉及改造点
- 3.1 压力工具改造
- 3.2 业务流量改造与隔离
- 3.2.1 全链路压测流量识别
- 3.2.2 入口压测流量识别
- 4、总结
首先,很开心,能跟大家分享关于全链路压测的知识,
小鱼也是根据自己在大厂的亲身经历及经验,通过长时间的总结整理出《全链路压测》这一系列的专栏。
如果没有做过性能测试,而第一次阅读《 全链路压测》专栏的文章,或多或少有些难理解。
而小鱼的性能专栏《 性能测试基础到实战(Jmeter/Locust)》,或许可以让彻底读懂,什么是性能测试。
读懂了性能测试,那么进阶的全链路压测,就不再那么高大上。 1、浅谈当前行业现状
在开始全链路压测学习前,我们先来简单介绍一下当前全链路压测行业现状。
在互联网行业中,小鱼发现一个很有趣的现象:
- 熟悉或者了解性能测试的人,大概有50%;
- 而在这50%人群中,精通性能测试的,仅仅有20%;
- 而在这20%的性能测试人中,做过全链路压测不足的 5%;
这是一个很尴尬的结果。
小鱼在《深聊性能测试,从入门到放弃之:初识性能测试》这篇就介绍过,性能测试是一个综合性学科,一个人是做不来的。
而全链路测试呢,我们或多或少在网上搜索或者公众号的关于全链路压测的文章,无非就以下几个特点:
- 目标和方案只有摘要级的说明;
- 全链路压测平台没有细节描述,很笼统;
- 只有少之又少的大厂一些笼统的资料,也没有投入成本(例如:人员成本、资金成本、时间成本)的数据;
- 没有架构级全链路改造细节;
- 没有架构级监控平台范围的细节;
- 没有性能分析逻辑的细节;
所以,看过这些文章,可能还是一头雾水:
- 首先:不知道自己的企业是否能支撑全链路压测;
- 其次:不知道应该如何具体实施;
- 第三:不知道如何计算投入的成本。
我说了这么多,可能还有的同学还是不理解,我在举个例子:
某企业为了跟潮流,要做全链路压测,但是由于本身的限制,并不具备全链路压测的条件,只做了一些小的动作,在线上减少覆盖范围并分段进行压测,最后的结果,可想而知,这完全失去了全链路压测的根本价值。
实际上的全链路压测的落地,是需要经过各种综合考量后的结果,
从整个全链路项目来看,上到公司BOSS,下到各个工程师都需要全部参与进来。
换句话说,全链路涉及到角色如下:
- 公司BOSS
- 产品经理
- 架构师
- 开发工程师
- 测试工程师
- 运维工程师
不同的岗位,关注点也不同:
- BOSS:全链路压测带来的业务容量提升和企业利润增长;
- 产品经理:业务容量的增长和后续功能的设计;
- 架构师:全局架构设计对全链路压测的宏观支撑;
- 开发工程师:业务细节和技术细节的改造;
- 测试工程师:覆盖住这些改造;
- 运维工程师:全链路改造和线上的压测过程对系统整体状态的影响。
所以,如何掌握全链路压测的重要性,就不言而喻。
在当今全链路压测趋势下,我们要做的,不仅仅是如何进行全链路压测,
还需掌握,如何统筹搭建运行全链路压测。
接下来,我们就来认识下,什么是全链路压测,全链路压测的难点及目标。
很多人觉得全链路压测的难点,是不是如何搭建环境,如何进行压测?
不然,
其实全链路压测的难点,是管理协调;
为什么这么说呢,
上面小鱼也提到了,全链路压测涉及到角色多,系统多,链路长,所以必然导致管理成本增加。
相比较而言,技术的实现就是细节的落地过程,消耗的只是人员和时间成本。
2.2 全链路压测的目标但是,其实也算是很遗憾的事情,我们的专栏,并不会过多的章节来介绍管理协调的技巧,毕竟,更多的同学,是针对全链路压测的技术来的。
在性能领域中,全链路压测一直都是大厂的利器,也是让小厂趋之如骛;
所以,我们就要来看下,全链路到底有什么神奇的功效,在互联网的公司有这么高的热度。
要理解这一点,我们得先看看全链路压测的目标:
- 全链路压测被称为系统整体容量保障的核武器;
- 全链路压测可以实现生产环境的压测服务,模拟真实的生产峰值场景,以发现真实的线上瓶颈并实现监控分析;
- 全链路压测可以实现精准的容量规划,确保线上系统的正常运行;
- 全链路压测可以实现海量的并发请求,以模拟真实的用户峰值场景;
- 全链路压测可以实现压测流量和生产流量的隔离,避免对生产流量产生影响;
- 全链路压测可以自动化压测,减少人工成本,并提高压测频率,快速发现问题;
看完这些,你应该就能知道,为什么全链路压测会有这么神奇的功效了。
其实这些还没完,如果你是在性能领域多年,那么多多少少会看过一些全链路压测的文章,而这些文章中,通常都会涉及到一些阿里,字节,美团,滴滴,京东等大厂的信息。
而这些文章最后给人的感觉就是:为了增加系统运行安全性,全链路压测是企业必须要做的一件事情。
既然全链路压测这么好,我们要不要跟风呢?
想要了解一件事情,就是去拆解这件事,
所以,我们接下来就来拆解全链路压测。
我们先来拆解一下全链路压测,啥是“链路”?简单点说就是几个点连成的线。这个词在 IT 行业中非常常用,但是在性能行业中,却是近几年才被广泛使用的“新词”。要讲链路,就得说到微服务分布式架构的发展。
一开始,在微服务分布式架构还没有流行起来的时候,人们大多使用 SOA 架构,它大概的技术架构是这样的:
系统之间的调用,都会通过ESB,因为调用的链路比较短。
进入到微服务分布式架构之后,由于微服务被拆得越来越细,大概的技术架构就变成了下图所示的样子:
这里的流程图只是举个例子。
从图上可以看到,链路变长了,这是大流量带来的系统拆分导致的。在这种情况下,识别问题也就更加困难了。
我们来总结一下这两个架构图:
- 原来一个系统的功能点多,现在一个系统功能点少;
- 原来测试一个系统就有一堆的业务逻辑,现在测试一个系统只有很简单的业务逻辑;
- 原来一个系统就可以完成的业务 *** 作,现在得跳好几个系统才能实现;
在互联网的初期,压测主要关注单系统接口,而这完全不能说明系统处理业务的容量能力。
随着业务的大规模发展,性能也必须做到覆盖“全部”系统,“全链路”这个概念就显得格外重要了,它指的是系统的全链路。
说到这,“全链路”的内涵就解释得差不多了,那说到压测,就得有工具、有平台。
由于系统架构的改变是容量改变引起的,因而容量出现大爆发的时候,要想实现压测,工具就必须支持这么大的容量。而之前常用的压力工具像 LoadRunner、JMeter 等,它们本身在分布执行能力、参数化拆分管理能力等方面都有着天生的弊端,所以我们必须另外打造具有大容量并发能力的工具。
这也是现在各企业想尽办法来实现自己的大并发压测平台的原因。
为了加深理解,我们再通过全链路线上压测与传统线下压测做对比:
从表中,我们可以大致的看出来,全链路线上压测与传统线下压测的区别点。
当然,线下也可以使用 脱敏的生产数据,这没有固定的要求。
其实最关键的一点区别,就是:线上 还是线下
其他的区别也可以不算是区别,因为那些区别点都是可以平衡掉的,比如说压力场景、铺底数据、监控手段等,关键在于投入多少。
投入的内容包括了:系统的改造投入、人员的投入、环境的投入、时间的投入。
实际上,要不要使用全链路压,测需要充分考虑企业的实际条件,我们可以通过以下几个问题来入手。
- 1、企业有没有那么大的流量需求?
如果不到几十万、上百万、上千万 / 每秒的交易量,其实完全不用考虑全链路压测平台的实现逻辑。如果你只是觉得这逻辑听起来更高大上而去实现它,那投入的成本等于说是打了水漂。 - 2、你的系统要不要做全链路线上压测?
如果不是在线上做全链路压测,那很多业务流量的改造工作就可以完全忽略。甚至,我们都不用考虑改造什么压力工具,这就是给自己找麻烦(有这时间撸串不香吗)。 - 3、系统能不能做全链路线上压测?
在网上可以看到,全链路压测90%都是互联网大厂。为什么呢?首先是因为请求量大;其次,做全链路线上压测的系统,即使出了问题,也不会对企业利润产生太大的影响,这一点至关重要。 - 4、组织支持不支持你做真正的全链路线上压测?
在全链路线上压测这件事情上,必然不是底层干活的人(部门经理及以下)可以决定的。全链路线上压测是需要企业上下层协调一致才可以做得到的。如果领导只是给你安排了一个做全链路线上压测的任务,但没有给你具体的权限支撑,是不可能做得下去的。而恰好有很多上层领导就是这种光安排任务,不给具体支持的风格。
这时,你得跟领导详细沟通一下,把成本利弊都分析清楚。如果从企业角度思考后,你们一致认为全链路压测是必须要做的,那就需要领导更具体的支持才行,不然可能很难推进。
通过以上4点,我相信,你会放弃当初的想法,觉得自己的公司,并不适合做全链路。
但是,针对另外一些企业,全链路压测是不可或缺的,因为它能解决以下三个问题:
- 直接使用生产环境,避免了环境的差异性;
- 实现高并发广域网压测平台,模拟了真实的用户场景;
- 不用进行线下线上容量的推算;
传统的线下压测显然做不到这三点。如果以上三个问题对企业的影响较大,那么全链路压测就很有必要了。
3、全链路压测涉及改造点上面说到,全链路压测对某些企业必不可少的,但是,凡事都有利与弊,
做全链路压测,就涉及到改造,具体有哪些,我们一起来看。
这就涉及到流量问题。
如果你的压力场景只需要万级每秒以下的请求量级,其实不需要做工具改造,传统工具就能做得到。
但是如果需要更大流量,就得对压力工具进行改造了。压力工具改造的内容有哪些呢?
- 压力发起部分:主要是多节点分布式的改造;
- 参数化部分:主要是数据量大引起的改造需求。在传统的压测工具中,基本上都是使用 Master-Slave 的方式,master 负责拆分参数化数据,但当数据量过大的时候,显然这是个问题点。
改造的部分只有这两点,在其他的功能点上传统的压力工具是可以覆盖大流量的压测需求的。
3.2 业务流量改造与隔离在业务流量的改造与隔离,一般有两种方法:
- 1、实现全链路的压测流量识别,从而实现隔离;
- 2、只在入口做压测流量的识别,直接旁路到另一套独立的链路中去。
业务标识改造的目的:实现业务流量的隔离,
业务流量隔离的目的:不让压测流量影响真实的线上用户。
贯穿业务改造的关键是整个业务流的识别跟踪,最后还可以方便地进行数据的清理。
具体业务改造需要包含的内容:
- 脚本改造
也就是加上流量标识,以实现后续的流量隔离。这一点任何一个压力工具都只需要加个参数即可,没有复杂度。 - 应用服务改造
这是改造工作量最大的部分。改造要实现的是对流量标识的识别,再把请求旁路到相应的存储组件中去。
应用的改造主要是对现有的业务代码进行入侵式的改造,增加业务开发的工作量。 实现的手段就是跨线程透传,将压测流量写入 ThreadLocal 对象中。 - 中间件的改造
对于一些跨服务调用使用的中间件,由于需要对压测流量进行标识,所以也是需要改造的。 - 存储逻辑的改造
不管是缓存还是数据库、队列,都要对压测流量进行识别,以便隔离。目的就是不影响生产数据。
对缓存(比如 Redis),我们可以实现不同的 key 值;对数据库,我们可以实现影子表或影子库。 - 日志改造
压测流量的日志最好不要和生产日志在一起。
针对入口做压测流量识别,改造方法,就相对简单:
只要在网关做压测流量的识别即可,后面就全都是部署的活了。
到这里,今天的内容就讲完了。
我们在回顾一下,今天主要分享的内容:
- 全链路压测的行业现状
- 什么是全链路压测
- 全链路压测的难点及目标
- 到底要不要做全链路压测
- 全链路压测的改造
面对全链路压测的优点,我们也要理性的分析有利用,
不能盲目的跟风,不然只能适得其反。
一切都要从实际地位出发,做符合实际的事情,才能得到真正的价值。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)