前言

随着业务的快速发展我们日常遇到的系统性能压力问题也逐渐出现,甚至在部分场合会遇到一些突发的营销活动,会导致系统性能突然暴涨,可能导致我们系统的瘫痪。最近几年随着电商的各种促销活动,有一个词也渐渐进入我们眼帘--“全链路压测”。

全链路压测被众多互联网公司的程序员定义为核武器,传统性能测试更多的是以事务为核心,更多的是由单个或者多个事务构成业务场景进行压测。那全链路压测到底是什么?一般指完全引入相关联的系统 真实模拟线上硬件环境,更多的是以请求为核心,完全模拟真实请求流量,通过引流等方式进行场景的模拟进行压测,更多的适用于业务链路较长的交易。

笔者以前只是一直听说全链路压测,但是并没有真正经历过,对全链路压测的理解也不是很全面,前年在互联网电商公司双11的时候参加过一次全链路的压测,当时全公司第一次做大范围的全链路压测,整个架构部也是第一次牵头来完成了整个全链路压测,经过大家1个月的努力,最后在活动期间完全扛住了压力,并且还有性能过剩。当时做完后因为忙的太累,没有进行过总结,最近新的公司正好在压测,借此也总结下全链路压测。

  1. 为什么需要全链路压测

我们在整个业务流程中,最大的困难在于评估从用户登录到完成全部交易的整个链条中,核心页面和交易关键交易的实际承载能力。如果得到了各个系统的实际承载能力,就可以在路由网关进行相关交易限流控制,来防止在大并发来了以后系统出现宕机,我们都知道一旦系统宕机就会导致灾难性的后果,而且就算运维短时间重启了起来恢复了运行,但是可能过了一会儿过程系统承载量又出现宕机,早期阿里在双十一的时候就发生过这样的问题,系统在0点,出现大面积瘫痪,重启后又瘫痪,为什么会出现这个问题,就是因为大家对整个全交易链条上的各个环节的系统承压能力不清楚,所以在出现了全链路压测,一方面能够让各个产品知道自己的承压极限在哪?

有的同学会问了通过单系统压测不是也可以知道各个系统的承压能力吗?但是实际情况不可能那么简单,那么顺利,在活动开始的瞬间,从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力,这个时候系统服务除了受自生的影响,还依赖于其他关联系统的情况,并且影响会一直蔓延,只要有一个节点出现故障,那么故障在上下游系统经过层层累加后会造成的影响谁都说不清楚,所以最好的办法就是模拟完全的真实情况来做到提前心里有数。验证的最好办法就是让事件提前发生,通过全链路压测就可以提早发现问题。

另一方面也可以让各个系统能够有个明确的优化目标并找出性能瓶颈,同时对于一些特殊环节可以通过临时增加公有云的方式来提高整体的性能,一旦通过全链路压测,了解了瓶颈所在就可以坦然的去按照压测指标去申请公有云资源,活动结束后再归还资源,这样做到成本最低化。

  1. 全链路压测常常遇到的问题

如何开展全链路压测?在说这个问题前,我们先考虑下,全链路压测有哪些问题比较难解决。

1)涉及的系统太多,牵扯的开发人员太多;

在压测过程中,做一个全链路的压测一般会涉及到大量的系统,在整个压测过程中,光各个产品的人员协调就是一个比较大的工程,牵扯到太多的产品经理和开发人员,如果公司对全链路压测早期没有足够的重视,那么这个压测工作是非常难开展的。

2)模拟的测试数据和访问流量不真实;

在压测过程中经常会遇到压测后得到的数据不准确的问题,这就使得压测出的数据参考性不强,为什么会产生这样的问题?主要就是因为压测的环境可能和生成环境存在误差、参数存在不一样的地方、测试数据存在不一样的地方这些因素综合起来导致测试结果的不可信。

3)压测生产数据未隔离,影响生产环境;

在全链路压测过程中,压测数据可能会影响到生产环境的真实数据,举个例子,电商系统在生产环境进行全链路压测的时候可能会有很多压测模拟用户去下单,如果不做处理,直接下单的话会导致系统一下子会产生很多废订单,从而影响到库存和生产订单数据,影响到日常的正常运营。

  1. 如何开展全链路压测

其实进行全链路压测对于整个公司技术要求还是很高的,如果没有一定能力的公司最好不要贸然尝试全链路压测,因为如果没做好可能会把生产环境搞宕,所以对于没有一定科技能力的公司还是尽量不要贸然追潮流实施全链路压测。对于科技能力不强的公司如果也想达到全链路压测那该怎么办?

其实办法也很简单,可以在压测环境进行模拟,做一个比例模拟,模拟1%-2%的访问量在测试环境进行压测,得到数据后乘以对应的倍数来得到总的压测指标,这里的比例当然不是简单的倍数相乘,需要各个系统得到系统线性扩展和单机压测指标的一个线性值,因为一般来说的线性扩展都不可能是100%的,一定会有一定扩展后的损失。

1)分析需压测业务场景涉及系统

在压测前我们一定要首先分析清楚需要压测的业务场景,只有分析清楚了业务场景才能梳理出来涉及的相关系统,分析清楚后也可以更快的找到性能瓶颈进行系统优化。这个工作一般是由架构师来梳理并确认涉及的相关系统,梳理清楚后就可以反馈给总压测负责人进行人员和资源的协调了。

2)协调各个压测系统资源

在全链路压测过程中,最难的工作其实不是系统优化、压测环境搭建等技术工作,最难的是压测资源的协调工作。这里的资源不单单指压测硬件、公有云等资源,还包括了人力资源,在整个压测过程中,需要各个相关产品的产品经理和技术开发人人员参与进去,这个工作可能不是架构师或者一个牵头产品的负责人能够协调的动的,必须要有一个自上而下的推力去推动,需要一个有一定级别的领导做背书,我们当时是分管科技的老总召集了所有的产品经理和各个产品技术开发负责人开了一个全链路压测的方案讨论会,这个会一方面说明了这个事情的重要性,让各个产品都当场立下军令状,并且安排出支持的人员,同时也授权给压测负责人。这个搞定以后压测负责人后续就可以光明正大的协调各个产品的配合人员了。

3)压测环境

压测环境也是个比较头疼的问题,很多系统可能压根就没有压测环境,所以全链路压测有个和传统压测比较大的区别就是,全链路压测是在生产环境,这种做法其实是存在一定风险的,一方面是系统风险,一方面是业务数据风险。对于全链路压测系统风险一定是首要考虑的问题,不能因为压测把系统搞宕机影响到日常生产环境的正常运营,我们当时做的电商系统还好,不涉及相关的监管。但是在银行业这样做还是有很大的风险的,一旦生产系统出现关键交易系统的宕机可能导致一些金融事故,会对金融市场造成恐慌,而且会被银监会通报,所以银行的压测还是不要进行全链路压测,不过可以在测试环境尽量仿真的模拟全链路压测。

前年在电商环境上做全链路压测直接在生产上进行压测,用生产环境最大的好处就是环境的真实性,通过生产环境能够最高程度的还原生产环境不用额外准备压测环境。但是使用生产环境进行压测需要考虑将请求和访问、业务数据处理都进行隔离,防止影响到生产环境,具体如何实施,涉及到比较多的细节这里就不详细描述了。总的思路就是在发起请求的时候通过请求报文头中的压测标示来进行区分处理,将压测的流量都分流到指定的应用服务器和指定的存储进行数据保存和处理。

进行全链路压测的时候,为了防止系统崩溃,可以选择在凌晨用户量最小的时候进行,这样就算发生故障也可以将影响降到最低。

4)压测数据

环境准备好了,可能就需要考虑造压测数据了,压测数据准备有两方面数据需要准备,一方面是压测请求数据的准备,需要模拟请求数据,请求数据最好的办法就是采用生产的真实数据,我们当时的做法是直接录制3-5天的生产访问请求流量,只需要对录制的请求进行数据清洗就可以了,将某个用户的请求替换成一个压测虚拟用户的请求,请求的商品也替换成压测虚拟商品,这个数据漂白替换的工作是比较复杂的,对于做数据漂白的的同学对系统的接口非常了解,否则很可能造成业务数据的混乱,造成大量的业务报表和系统数据的脏数据;另一方面是测试数据的准备,我们当时准备了压测虚拟商品的数据、虚拟商品库存数据、虚拟供货商、虚拟用户。

5)压测数据隔离

因为是在生产环境做的压测,压测数据需要与正常的业务数据隔离开,我们当时的方案是对于压测的这些脏数据都做了特定标示,对于虚拟用户、虚拟商品、虚拟订单、虚拟库存都是有特殊标示的,这样这类数据在统计的时候都不会进行统计,在压测后也会对这些数据进行清理,防止污染正常业务数据。

6)压测数据实时监控

在压测过程中,为了能发现性能问题,我们需要对压测过程中各个系统的cpu、内存、磁盘io都进行系统层面的监控,同时也需要对各个业务节点的耗时进行监控,一方面从业务层面去监控压测事务性能,另一方面从系统层面监控,这样我们可以先从业务层面找到性能瓶颈,再单独分析各个系统的系统层面的瓶颈,最终找到优化方案。

我们当时公司内部有个实时监控平台,这个平台是基于大众点评开源的cat实现的多平台监控系统,能够实时监控各个系统的实时交易运行情况,这样能够在第一时间发现遇到大流量的情况后,性能瓶颈在哪?然后进行针对性的优化。

文章来源:网络 版权归原作者所有

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系小编,我们将立即处理前言

随着业务的快速发展我们日常遇到的系统性能压力问题也逐渐出现,甚至在部分场合会遇到一些突发的营销活动,会导致系统性能突然暴涨,可能导致我们系统的瘫痪。最近几年随着电商的各种促销活动,有一个词也渐渐进入我们眼帘--“全链路压测”。

全链路压测被众多互联网公司的程序员定义为核武器,传统性能测试更多的是以事务为核心,更多的是由单个或者多个事务构成业务场景进行压测。那全链路压测到底是什么?一般指完全引入相关联的系统 真实模拟线上硬件环境,更多的是以请求为核心,完全模拟真实请求流量,通过引流等方式进行场景的模拟进行压测,更多的适用于业务链路较长的交易。

笔者以前只是一直听说全链路压测,但是并没有真正经历过,对全链路压测的理解也不是很全面,前年在互联网电商公司双11的时候参加过一次全链路的压测,当时全公司第一次做大范围的全链路压测,整个架构部也是第一次牵头来完成了整个全链路压测,经过大家1个月的努力,最后在活动期间完全扛住了压力,并且还有性能过剩。当时做完后因为忙的太累,没有进行过总结,最近新的公司正好在压测,借此也总结下全链路压测。

  1. 为什么需要全链路压测

我们在整个业务流程中,最大的困难在于评估从用户登录到完成全部交易的整个链条中,核心页面和交易关键交易的实际承载能力。如果得到了各个系统的实际承载能力,就可以在路由网关进行相关交易限流控制,来防止在大并发来了以后系统出现宕机,我们都知道一旦系统宕机就会导致灾难性的后果,而且就算运维短时间重启了起来恢复了运行,但是可能过了一会儿过程系统承载量又出现宕机,早期阿里在双十一的时候就发生过这样的问题,系统在0点,出现大面积瘫痪,重启后又瘫痪,为什么会出现这个问题,就是因为大家对整个全交易链条上的各个环节的系统承压能力不清楚,所以在出现了全链路压测,一方面能够让各个产品知道自己的承压极限在哪?

有的同学会问了通过单系统压测不是也可以知道各个系统的承压能力吗?但是实际情况不可能那么简单,那么顺利,在活动开始的瞬间,从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力,这个时候系统服务除了受自生的影响,还依赖于其他关联系统的情况,并且影响会一直蔓延,只要有一个节点出现故障,那么故障在上下游系统经过层层累加后会造成的影响谁都说不清楚,所以最好的办法就是模拟完全的真实情况来做到提前心里有数。验证的最好办法就是让事件提前发生,通过全链路压测就可以提早发现问题。

另一方面也可以让各个系统能够有个明确的优化目标并找出性能瓶颈,同时对于一些特殊环节可以通过临时增加公有云的方式来提高整体的性能,一旦通过全链路压测,了解了瓶颈所在就可以坦然的去按照压测指标去申请公有云资源,活动结束后再归还资源,这样做到成本最低化。

  1. 全链路压测常常遇到的问题

如何开展全链路压测?在说这个问题前,我们先考虑下,全链路压测有哪些问题比较难解决。

1)涉及的系统太多,牵扯的开发人员太多;

在压测过程中,做一个全链路的压测一般会涉及到大量的系统,在整个压测过程中,光各个产品的人员协调就是一个比较大的工程,牵扯到太多的产品经理和开发人员,如果公司对全链路压测早期没有足够的重视,那么这个压测工作是非常难开展的。

2)模拟的测试数据和访问流量不真实;

在压测过程中经常会遇到压测后得到的数据不准确的问题,这就使得压测出的数据参考性不强,为什么会产生这样的问题?主要就是因为压测的环境可能和生成环境存在误差、参数存在不一样的地方、测试数据存在不一样的地方这些因素综合起来导致测试结果的不可信。

3)压测生产数据未隔离,影响生产环境;

在全链路压测过程中,压测数据可能会影响到生产环境的真实数据,举个例子,电商系统在生产环境进行全链路压测的时候可能会有很多压测模拟用户去下单,如果不做处理,直接下单的话会导致系统一下子会产生很多废订单,从而影响到库存和生产订单数据,影响到日常的正常运营。

  1. 如何开展全链路压测

其实进行全链路压测对于整个公司技术要求还是很高的,如果没有一定能力的公司最好不要贸然尝试全链路压测,因为如果没做好可能会把生产环境搞宕,所以对于没有一定科技能力的公司还是尽量不要贸然追潮流实施全链路压测。对于科技能力不强的公司如果也想达到全链路压测那该怎么办?

其实办法也很简单,可以在压测环境进行模拟,做一个比例模拟,模拟1%-2%的访问量在测试环境进行压测,得到数据后乘以对应的倍数来得到总的压测指标,这里的比例当然不是简单的倍数相乘,需要各个系统得到系统线性扩展和单机压测指标的一个线性值,因为一般来说的线性扩展都不可能是100%的,一定会有一定扩展后的损失。

1)分析需压测业务场景涉及系统

在压测前我们一定要首先分析清楚需要压测的业务场景,只有分析清楚了业务场景才能梳理出来涉及的相关系统,分析清楚后也可以更快的找到性能瓶颈进行系统优化。这个工作一般是由架构师来梳理并确认涉及的相关系统,梳理清楚后就可以反馈给总压测负责人进行人员和资源的协调了。

2)协调各个压测系统资源

在全链路压测过程中,最难的工作其实不是系统优化、压测环境搭建等技术工作,最难的是压测资源的协调工作。这里的资源不单单指压测硬件、公有云等资源,还包括了人力资源,在整个压测过程中,需要各个相关产品的产品经理和技术开发人人员参与进去,这个工作可能不是架构师或者一个牵头产品的负责人能够协调的动的,必须要有一个自上而下的推力去推动,需要一个有一定级别的领导做背书,我们当时是分管科技的老总召集了所有的产品经理和各个产品技术开发负责人开了一个全链路压测的方案讨论会,这个会一方面说明了这个事情的重要性,让各个产品都当场立下军令状,并且安排出支持的人员,同时也授权给压测负责人。这个搞定以后压测负责人后续就可以光明正大的协调各个产品的配合人员了。

3)压测环境

压测环境也是个比较头疼的问题,很多系统可能压根就没有压测环境,所以全链路压测有个和传统压测比较大的区别就是,全链路压测是在生产环境,这种做法其实是存在一定风险的,一方面是系统风险,一方面是业务数据风险。对于全链路压测系统风险一定是首要考虑的问题,不能因为压测把系统搞宕机影响到日常生产环境的正常运营,我们当时做的电商系统还好,不涉及相关的监管。但是在银行业这样做还是有很大的风险的,一旦生产系统出现关键交易系统的宕机可能导致一些金融事故,会对金融市场造成恐慌,而且会被银监会通报,所以银行的压测还是不要进行全链路压测,不过可以在测试环境尽量仿真的模拟全链路压测。

前年在电商环境上做全链路压测直接在生产上进行压测,用生产环境最大的好处就是环境的真实性,通过生产环境能够最高程度的还原生产环境不用额外准备压测环境。但是使用生产环境进行压测需要考虑将请求和访问、业务数据处理都进行隔离,防止影响到生产环境,具体如何实施,涉及到比较多的细节这里就不详细描述了。总的思路就是在发起请求的时候通过请求报文头中的压测标示来进行区分处理,将压测的流量都分流到指定的应用服务器和指定的存储进行数据保存和处理。

进行全链路压测的时候,为了防止系统崩溃,可以选择在凌晨用户量最小的时候进行,这样就算发生故障也可以将影响降到最低。

4)压测数据

环境准备好了,可能就需要考虑造压测数据了,压测数据准备有两方面数据需要准备,一方面是压测请求数据的准备,需要模拟请求数据,请求数据最好的办法就是采用生产的真实数据,我们当时的做法是直接录制3-5天的生产访问请求流量,只需要对录制的请求进行数据清洗就可以了,将某个用户的请求替换成一个压测虚拟用户的请求,请求的商品也替换成压测虚拟商品,这个数据漂白替换的工作是比较复杂的,对于做数据漂白的的同学对系统的接口非常了解,否则很可能造成业务数据的混乱,造成大量的业务报表和系统数据的脏数据;另一方面是测试数据的准备,我们当时准备了压测虚拟商品的数据、虚拟商品库存数据、虚拟供货商、虚拟用户。

5)压测数据隔离

因为是在生产环境做的压测,压测数据需要与正常的业务数据隔离开,我们当时的方案是对于压测的这些脏数据都做了特定标示,对于虚拟用户、虚拟商品、虚拟订单、虚拟库存都是有特殊标示的,这样这类数据在统计的时候都不会进行统计,在压测后也会对这些数据进行清理,防止污染正常业务数据。

6)压测数据实时监控

在压测过程中,为了能发现性能问题,我们需要对压测过程中各个系统的cpu、内存、磁盘io都进行系统层面的监控,同时也需要对各个业务节点的耗时进行监控,一方面从业务层面去监控压测事务性能,另一方面从系统层面监控,这样我们可以先从业务层面找到性能瓶颈,再单独分析各个系统的系统层面的瓶颈,最终找到优化方案。

我们当时公司内部有个实时监控平台,这个平台是基于大众点评开源的cat实现的多平台监控系统,能够实时监控各个系统的实时交易运行情况,这样能够在第一时间发现遇到大流量的情况后,性能瓶颈在哪?然后进行针对性的优化。

文章来源:网络 版权归原作者所有

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系小编,我们将立即处理

软件测试技术之全链路压测经验(上)相关推荐

  1. 滴滴全链路压测解决之道 | 技术头条

    戳蓝字"CSDN云计算"关注我们哦! 技术头条:干货.简洁.多维全面.更多云计算精华知识尽在眼前,get要点.solve难题,统统不在话下! 作者:张晓庆 转自:Java架构沉思录 ...

  2. 阿里技术解密:全链路压测体系建设方案的思考与实践

    在阿里淘宝 双11 的过程中,长期以来都是在生产环节做全链路压测的,通过实践我们发现在生产环境中做压测,实际上会和一个 IT 组织的结构.成熟度.流程等紧密相关,所以我们把全链路压测从简单的制作范围内 ...

  3. 阿里10年分布式技术沉淀:阿里高可用体系核心缔造者、全链路压测创始人告诉你!...

    原文链接 7月27日,云栖社区.阿里中间件将举办首届阿里巴巴中间件技术峰会,揭秘阿里10年分布式技术干货.目前活动官网已上线:https://yq.aliyun.com/promotion/262,  ...

  4. 阿里10年分布式技术沉淀:阿里高可用体系核心缔造者、全链路压测创始人告诉你!

    原文链接 7月27日,云栖社区.阿里中间件将举办首届阿里巴巴中间件技术峰会,揭秘阿里10年分布式技术干货.目前活动官网已上线:https://yq.aliyun.com/promotion/262,  ...

  5. 技术干货 | 应用性能提升 70%,探究 mPaaS 全链路压测的实现原理和实施路径

    简介: 全链路压测方案下,非加密场景下至少有 70% 的性能提升,加密场景下 10%的性能提升,并在 MGS 扩容完成后可实现大幅的性能提升,调优的结果远超预期. 业务背景 随着移动开发行业的步入存量 ...

  6. 全链路压测:构建三大模型

    压测前言 上篇文章主要介绍了在全链路压测准备阶段,最核心的一点:核心链路相关的知识. 梳理核心链路的一个重要目的是获得流量模型.但在全链路压测中,除了流量模型,业务模型和数据模型一样重要.这篇文章,为 ...

  7. 全链路压测体系建设方案的思考与实践

    在阿里淘宝 双11 的过程中,长期以来都是在生产环节做全链路压测的,通过实践我们发现在生产环境中做压测,实际上会和一个 IT 组织的结构.成熟度.流程等紧密相关,所以我们把全链路压测从简单的制作范围内 ...

  8. 全链路压测自动化实践

    背景 境内度假是一个低频.与节假日典型相关的业务,流量在节假日较平日会上涨五到十几倍,会给生产系统带来非常大的风险.因此,在2018年春节前,我们把整个境内度假业务接入了全链路压测,来系统性地评估容量 ...

  9. 罗辑思维在全链路压测方面的实践和工作笔记

    业务的知名度越高,其背后技术团队承受的压力就越大.一旦出现技术问题,就有可能被放大,尤其是当服务的是对知识获取体验要求颇高的用户群体. 提供知识服务的罗辑思维主张"省时间的获取知识" ...

最新文章

  1. 浮动元素的display属性
  2. 查看php 相关信息
  3. jzoj3360-[NOI2013模拟]苹果树【树上莫队,LCA】
  4. oracle删除多条从js到java_一次oracle大量数据删除经历
  5. 多机器人路径规划的代码_知荐 | 地平线机器人算法工程师总结六大路径规划算法...
  6. 苹果CMS10|粉色视频站模版|YMYS007|魅力社
  7. c语言字符串替换问题,C语言中的字符串替换
  8. MySQL - 查询今天的数据(以及昨天、本月、上个月、今年...)
  9. 如何下载B站高清视频
  10. 不仅仅是一种爱好:了解中国的电竞市场
  11. REINFORCEMENT LEARNING USING QUANTUM BOLTZMANN MACHINES利用量子波兹曼机进行强化学习
  12. 如何快速调整Excel中图表标签位置
  13. 怎样将多个韵达快运单号物流中含有问题件的单号归类
  14. R语言 第三方软件包的下载及安装
  15. Windows 纤程/协程
  16. 【BZOJ4889】[Tjoi2017]不勤劳的图书管理员 分块+树状数组
  17. 2020年第三方铁塔数据大汇总,全年新增超4900座
  18. java计算机毕业设计快递配送平台MyBatis+系统+LW文档+源码+调试部署
  19. 适用于WordPress的10个最佳白标签品牌插件
  20. [宋史学习] 谁制造了“天子为点检”的木牌?

热门文章

  1. 如何使用 OpenCV 为照片添加卡通效果!
  2. 值得关注的5个在线HTML5工具
  3. SAP Portal实施分享_自定义LoginModule模块
  4. 【安全知识分享】消防安全知识讲座(附下载)
  5. WIN2K 实用软件
  6. 炫酷的canvas粒子文字js特效
  7. echarts点击图表事件和鼠标悬浮事件
  8. 如何修改mysql数据库的字符集_如何修改mysql字符集
  9. React-36:withRouter的使用
  10. 大型企业信息化中的BPM 和SOA 实战