精华内容
下载资源
问答
  • 全链路压测平台通过应用系统改造使线上环境可以同时处理正常流量和测试流量,以支持线上不影响正常用户访问的集群读写压测,获得最真实的线上实际承载能力数据。要实现全链路压测,涉及的产品很多,包括网络、应用、...

    说明

    全链路压测主要是用在大促前夕的备战。用来模拟大促的全部链路,对整个链路进行压测,以检测平台在各个链路阶段中可能存在的不足。使备战更加精准和高效。

    全链路压测平台通过应用系统改造使线上环境可以同时处理正常流量和测试流量,以支持线上不影响正常用户访问的集群读写压测,获得最真实的线上实际承载能力数据。要实现全链路压测,涉及的产品很多,包括网络、应用、中间件、数据库、安全、数据等都需要改造,涉及的应用范围很广,涵盖核心链路的上百个应用。

    目标

    从全链路压测链路模型的自动计算、全链路数据准备和流量发送的无缝衔接、应用容量的弹性伸缩、自动化的预案执行和验证等多个维度,使得整个大促备战更加高效和精准,将大促稳定性保障能力提升到一个崭新的高度。

    工作内容

    1.基础数据抽取

    全链路压测的目的在于模拟双十一、618之类的大促,模拟的真实性尤为重要。基础数据(买卖、卖家、商品等)的构造是真实性保障的重要一环,为了模拟尽可能真实,全链路压测以线上数据为数据源,进行采样、过滤和脱敏,作为全链路压测的基础数据,数据量与线上数据保持同一个数量级,在数据库的sequence id上进行区间隔离。

    2.链路与模型构造

    全链路压测的链路代表要压测的业务范围,同一条链路需要构造海量的参数集合,代表不同用户的不同行为。链路范围、链路的访问量级、链路的参数集合、基础数据的特性一起构造了压测的业务模型。链路与模型的构造对压测结果的影响同样至关重要。

    3.链路验证

    在全链路压测平台的诞生阶段,链路验证耗费了压测项目组大量的时间和精力,电商业务具备复杂的业务特性,有上百条链路,每一条链路都需要确保能够让全链路压测引擎跑通,好在这是个一次性的工作,跑通以后出问题的概率不大,全链路压测平台也将链路验证功能集成到平台当中,能够自动化完成对压测链路的验证。

    4.业务改造

    全链路压测有不少地方需要在业务系统针对压测流量进行相应改造。比如压测链路的重复执行:全链路压测通常会进行好几个小时,这一特性要求链路能够被重复执行。实际情况当中,我们有不少链路并非是幂等的,需要针对存在这一特性的链路做专门的压测流量改造。再比如下游写流量的拦截、防止污染BI报表和线上推荐算法等场景都需要在业务系统进行相应改造。类似这样的改造点,在全链路压测早期时代非常多。

    5.数据平台

    数据平台是全链路压测的数据基地。由数据的准备、链路的构造、模型的构造等一系列重要模块构成,随着全链路压测的不断演进,数据平台沉淀了一系列自动化和智能化的基础设施,大幅提升全链路压测数据准备的效率和模型精确性。

    6.流量平台

    流量平台是全链路压测的计算中心,主要由两大部件构成:
    ·全链路压测操控中心,进行压测的配置和操控、数据的监控以及对压测引擎集群的管控。
    ·压测引擎,由控制台统一管控,部署在外网CDN集群,进行登录、会话同步,发送各种协议的压测请求、状态统计。

    7.影子表

    数据的隔离是全链路压测诞生阶段的一大难题。全链路压测的链路有读有写,并且在线上进行,为了不污染到线上的正常数据,全链路压测在同一个数据库的实例上对数据库表建同样结构的影子表来进行数据的隔离。

    8.中间件改造

    全链路压测的流量通过在链路上带上特定的压测参数进行区分,如果缺乏相应中间件的支持,在调用到下游系统的时候,压测标志就丢失了。因此需要所有中间件的协议都支持对压测流量的识别,使得压测标识能够随着调用传递下去,使得下游的应用、基础中间件和存储都能够识别压测流量。

    9.安全机制

    全链路压测的安全机制分两层:第一层是安全的监控和保护,建立非法流量的监控机制,正常用户访问不了测试数据,测试账户也访问不了正常数据,防止数据错乱;并且设置压测引擎集群的白名单,防止恶意访问;第二层是对压测流量的安全过滤,针对压测流量放松安全策略,使得压测流量不被判别为攻击流量。

     全链路压测平台的建设比这里说的事项要多的多,这里只是简单介绍了其中一些常见的工作事项。中间可能根据公司业务的不同,中间可能还有一些需要处理的比较复杂的事项。具体的内容要根据具体的事项去进行分析。这只是一个常规性的参考。

    如果您有更好的想法或方案,欢迎您留言大家一起探讨。

     

    展开全文
  • 高德地图:全链路压测平台TestPG的架构与实践 转自https://www.sohu.com/a/341414025_692515 1. 导读 2019年以来,高德DAU一个亿进入常态,不断增长的日活带来喜悦的同时,也给支撑高德业务的技术人带来了挑战...

    高德地图:全链路压测平台TestPG的架构与实践 

    转自  https://www.sohu.com/a/341414025_692515

    1.

    导读

    2019年以来,高德DAU一个亿进入常态,不断增长的日活带来喜悦的同时,也给支撑高德业务的技术人带来了挑战。如何保障系统的稳定性,如何保证系统能持续的为用户提供可靠的服务?是所有高德技术人面临的问题,也是需要大家一起解决的问题。

    2.

    高德业务规模

    支撑一亿DAU的高德服务是什么体量?可能每个人的答案都不相同,这里从基础设施的角度给大家做个简单的介绍,我们有数千个线上应用,分别部署在全国各地多个机房中的数万台机器上。

    这张图是高德业务核心链路的架构,从图中可以看出高德业务具有相当高的复杂性。当然,真实系统远远要比图表示的复杂,如果用这张图来代表高德整体业务形态,无异于管中窥豹,太过于片面。

    对于如此大规模,高复杂度的系统,如何保障系统的稳定性,是高德技术人长期面临和解决的问题。

    3.

    保障稳定性的手段

    如何保障系统稳定性是几乎所有互联网企业都需要面对的问题。通常来讲,有五种手段来从理论上保障系统的稳定性,分别是:

    • 容量规划:根据以往业务的流量,估算出未来(通常是即将来临的大促,节假日)的流量。以整体流量为基础,估算出每个子系统需要满足的容量大小。然后根据子系统的容量来计算出需要的资源数量,对系统进行适当的扩容。计算方式可以简单的表示为如下公式: 机器数量 = 预估容量 / 单机能力 + Buffer (一定数量的冗余)
    • 流量控制:系统需要防止流量超过设计的容量,对超出设计的流量进行限流。各业务也需要对超出子系统服务能力的流量进行限流,对超负荷的服务进行降级。
    • 灾备:一旦系统发生灾难性故障,需要将流量切换到容灾机房,避免对大量用户造成损失。
    • 监控:对服务进行全方面的监控,实时掌控系统的状态,对系统中出现的问题及时预警,做到早发现,早治理。
    • 预案演练:对系统可能面临的问题要进行全面的预演,结合断网,断电等等灾难模拟的手段来检验系统在灾难面前的表现。

    有了稳定性保障的五大法宝,我们是否就可以高枕无忧了呢?答案是令人遗憾的,这里有两个残酷的现实例子,告诫我们不要太乐观。

    多年前的某年春节前夕,我们对高德核心链路进行了压测,压测设计的流量要高于预估的春节流量,系统在当时表现良好,各项指标都满足要求。可是春节期间,服务因某种原因发出告警,而此刻线上流量的水位并没有超过我们的预期。

    还有一次在某年五一期间,该服务再次发出预警,而且和春节的那次预警的原因不一样。

    我们的稳定性保障手段是基于对于系统的认知来实现的,而认知往往是真实世界在头脑中的映射,是一种模型,或是真实系统的快照。系统的真实状态往往和我们观测到的不太一致,基于观测到的模型对系统进行的测量也往往会不够准确,对于系统,我们要保持敬畏。对系统进行不厌其烦的模拟,无限的接近真实系统的状态,是永恒不变的追求。

    上述稳定性保障的工作,只能在理论上保证系统的抗压能力,但是不能确定在真实流量到来的时候,系统的表现如何!

    因此,我们需要演习,需要让真实的流量提前到来!

    4.

    全链路压测

    如何让真实的流量提前到来?我们需要借助全链路压测,那么什么是全链路压测呢?

    我的理解是:把全链路压测拆分为两个部分来看。一是全链路,一是压测,分别来理解:

    • 全链路:分为两层意思;一是自顶向下,一个请求在系统中经过的完整路径。二是一系列动作的集合,比如从用户登录,到浏览商品,到选择商品,到加入购物车,到支付等等这整个环节。对于高德业务而言,我们关注的是第一种全链路。
    • 压测:通过对海量用户行为模拟的方式,对系统逐步施压,用于检验系统的稳定性。

    集团的战友们把全链路压测比作 "终极武器",非常的形象。既然是 "终极武器",那就需要有足够的威慑力,对于高德来说,目标是:提供真实的流量,在真实的环境中来检验系统的稳定性。

    这里面包含三个关键点:

    • 真实的流量:流量的量级和特征贴近真实的世界。
    • 真实的环境:直接在线上环境进行。
    • 提前进行:在流量洪峰到来之前。

    做到这三点,才能称得上是一次真正意义上的演习,才可以叫做全链路压测。

    5.

    高德全链路压测面临的挑战

    高德全链路压测面临众多方面的挑战,除了分布式系统固有的挑战外,高德全链路压测还面临着业务特殊性的挑战。

    5.1 分布式系统的特性

    5.1.1 不确定性

    我们认为的流量有序的,而真实的流量却是随机的,不确定的。

    5.1.2 抖动性

    在理论的世界里面,吞吐量是请求量的函数,可以表示为如下的公式:

    Throughput=f(load)

    如果没有其他因子的干扰,在系统达到饱和之前,吞吐量和请求量的关系应该是线性的。而现实世界里面,这种理论模型几乎是不可能出现的。为什么?因为抖动。为什么会出现抖动?因为网络,磁盘等等的不确定性。

    aecdf75660244268b7f7a31fe9646d9c.pnguploading.4e448015.gif转存失败重新上传取消

    5.1.3 排队系统的特性

    f91b006e8cb94c068d9b2f36526bff95.pnguploading.4e448015.gif转存失败重新上传取消

    我们的业务可以简单的抽象成为一个排队系统,请求从左边随机的进入系统,等待被处理,处理完成之后,从右边离开队列。在系统未达到饱和状态时,系统可以很好的处理用户的请求,而一旦队列接近饱和,那么队列的长度可能会显著的增加,而且请求的平均响应时间也会出现增加,甚至会出现部分请求超时的情况。对于一个理论上能处理1000q/s的系统,在不同流量的情况下,可能的状态如下(特定系统的测量结果):

    2376e4b12d084e2687fdf7612d07d9ff.jpeguploading.4e448015.gif转存失败重新上传取消

    从图中可以看出:

    • 请求达到率增加2倍,队列的长度会增加约60倍。
    • 当系统接近饱和时,请求端极小的变化将会对系统造成很大的影响。请求达到率从0.95 ~ 0.99,队列的长度将增加40%。

    排队系统的特征是:系统会在接近饱和时出现拥堵,拥堵会导致服务的时间变长,而这反过来又会加重拥堵的程度。随着情况的恶化,系统的资源(cpu,mem)最终会被耗尽。拥堵和服务质量下降表现为正相关性,这种特性会随着时间急剧的恶化,最终拖垮系统,出现故障。

    5.2 高德业务特点

    出行业务有其特有的特殊性,会受到诸多因素的影响。具体到高德业务而言,系统的行为会受到区域,地形,路况,路网密度,季节,天气,政府活动等等因素的影响。

    以驾车导航为例,导航系统会受到如下因素的影响:

    • 区域:不同的区域经济发展水平不一致,人们选择出行的交通工具也会不一样,经济发达地区的人们汽车拥有率会更高,使用汽车出行的频率也会更高。
    • 地形:山区,城市繁华地区会因gps信号遮挡导致定位不准确,可能被系统认为偏航,从而引发路径重新规划。
    • 路况:事故,拥堵,施工,限行,管制 这些路况都对导航服务造成影响。
    • 路网密度:导航算法所要求的计算资源和路网的密度有很强的关联,路网越密,路径规划所消耗的cpu资源,内存资源就会越大,同时计算的时间也会越长。
    • 距离:路径规划的距离越长,导航算法对计算资源的要求就越高。
    • 季节&天气:人们的出行行为和季节也会呈现相关性,如 五一,端午 人们可能集中前往景区旅游。十一,春节 人们可能会集中返乡。这样在导航行为上就会出现导航距离分布不同的情况,不同的导航距离对服务的要求会不一样,越长距离的导航对服务资源的要求越高。
    • 政府活动:交通管制,修路,限行等等。

    对于高德而言不能单纯的通过放大流量来对系统进行压测,在流量构造阶段我们需要考虑到流量的特征,考虑到所有影响服务行为的因素。

    6.

    高德全链路压测平台的自建起因

    身在阿里,说起全链路压测,首先想到的肯定是大名鼎鼎的Amazon平台,Amazon 诞生于2013年,自2013年起,Amazon一直作为淘宝、天猫稳定性保障体系中神一般的存在。经过多年的发展和演进,Amazon平台已经日臻稳定和成熟,在施压能力,链路治理,数据构造,用户模拟方面已经做到极致。

    所以,在落地高德全链路压测的时候,首先考虑的就是借助Amazon平台。经过充分的调研和部分项目的试用,我们发现Amazon平台并不能满足我们的要求。

    Amazon平台诞生于淘宝,作为淘宝,天猫稳定性保障体系中重要的成员。Amazon 追求的是超高的施压能力和极强的平台稳定性。另外,淘宝的双11,双12全链路压测是多团队合作的项目,一次全链路压测可能需要数百人的参与,对于这种超大规模的全链路压测项目,成败的关键在于团队的合作。平台需要搞定的是人无法搞定的事情,对于Amazon来讲,要做的就是把事情做到极致。

    高德的全链路压测流量的要求远远不及淘宝的全链路压测,并且通常全链路压测的周期都不会太长(通常在2周左右,这个时间还需要缩减),所以我们比较关注压测成本的问题,例如压测数据的构造成本,压测资源申请的成本,错误排查成本,以及便捷性方面的问题,例如压测过程的可视化,压测报告等。

    另外,高德的日常环境的压测需求比较旺盛,除了全链路压测外,我们还需要借助别的平台(如PAP,PAS)来满足日常的压测需求。

    从成本收益的角度出发,最终我们选择自研压测平台来满足高德的全链路压测需求,以及日常的压测需求。

    7.

    高德压测平台的自建思路

    如何打造一款全新的压测平台?

    回答这个问题,先要回答平台的目的是什么。高德压测平台的目的是什么?一定是为了解决业务的问题!结合上文对全链路压测的描述,对高德业务特点的描述,我们建设压测平台就需要回答这几个问题:

    • 如何保证场景的真实性?
    • 线上压测,如何保证压测流量不影响线上用户,如果保证压测数据不污染线上数据?
    • 如何构建超高流量?
    • 如何降低使用成本?
    • 如何降低资源成本?

    7.1 如何保证场景的真实性

    压测要保证真实,需要在压测场景上做到全覆盖,需要从协议支持和用户行为两个方面来满足场景的真实性。

    协议支持:

    对于高德服务而言,不同的用户场景使用到的通信协议不一样,例如PC端主要是http协议,而移动端则是accs协议。因此全链路压测的场景设计上首先需要满足对全协议的支持。

    用户行为:

    除协议外,场景构造还需要考虑到真实场景的用户行为,目前的做法是使用线上日志作为原材料,对日志进行过滤,整理,最终形成标准化语料文件,这样可以在一定程度上保证压测数据的真实性。这种低成本的做法,只能借助业务同学的经验去保证。人总会出错,因此未来在场景真实性保障方面不能仅仅依靠人的经验,平台需要通过技术的手段,通过模型,依靠机器去保证。

    7.2 线上压测,如何保证压测流量不影响线上用户,如何保证压测数据不污染线上数据?

    为了保证压测流量不影响线上用户,不对污染线上环境,首先要做的是:链路上的各系统,中间件需要做到对压测流量进行识别,具体而言需要如下步骤:

    • 接入鹰眼
    • 使用集团的中间件(集团的中间件都支持压测流量识别)
    • 业务改造(结合鹰眼对压测标进行透传,对于某些业务可能需要在业务层面对压测流量进行过滤,如对三方系统的调用需要替换成mock方式)

    除此之外,还需要有完备的监控手段,在发现服务问题(如系统中发生限流,降级,RT突然增高等等)时,及时的止损。

    7.3 如何构建超高流量

    对线上服务的压测,需要构造出超大规模级别的压力。这需要大量的施压机器共同努力才能达到。要达到验证服务稳定性的目标,全链路压测就需要具备构造超大规模压力的能力。我们目前的策略是自建分布式Jmeter施压集群,依托于Aone的快速部署和便捷的扩容能力来迅速的满足压测流量的需求。

    7.4 如何降低使用成本

    压测引擎:以往高德线下的压测属于工具形式,大家使用Jmeter对被测服务进行压力测试,负责压测的同学都对Jmeter比较熟悉。考虑到平台使用的成本,和工具转平台的便捷性,我们使用Jmeter作为TestPG的压测引擎。快速压测:高德有非常多的单链路压测需求,而且服务的接口数量比较少,也比较简单。对于此类型的压测需求,平台需要提供开速开始的能力,简化语料->场景->任务的标准化流程。压测数据管理:全链路压测使用的压测数据(语料文件)的大小达到数十G,文件的存储和分发对系统的设计而言都是不小的挑战。目前采取的做法是使用OSS来存储压测数据,通过一定的策略和算法在施压机器上对语料进行预加载。

    7.5 如何降低资源成本

    高德每年会进行两次大型的压测(春节和十一),其他时间如:清明,五一,端午视各业务线的情况而定。在大型压测时,需要大量的压测资源(几百台,4C16G),而平时少量的压测资源(几十台)就足以满足日常的压测需求,因此在压测资源的管理上要保证灵活,需要时快速满足,不需要时释放,避免资源浪费。

    目前TesgPG提供两种施压集群扩容的方式:一是使用Aone部署,通过Normandy平台进行快速扩容(pouch);二是支持用户自主提供压测机,技术方案是使用Docker + StarAgent 方式来实现施压机的自动部署。

    压测资源调度:除了支持全链路压测外,还需要支持日常的压测。对于不同的压测,系统在设计上要满足多租户,多任务的需求,在压测资源的管理方面做到按需分配(目前是人工评估)。

    8.

    高德压测平台的自建目标

    短期目标:

    支撑高德全链路压测。

    为高德所有服务提供线下压测的能力。

    中期目标:

    成为高德线上系统稳定性的试金石。

    长期目标:

    产品化,服务于集团的更多业务。

    9.

    高德压测平台架构与特点

    9.1 高德压测平台架构

    • 高德压测平台业务架构

    638441ce2d2f4703b90c18465abc53cc.jpeguploading.4e448015.gif转存失败重新上传取消

    • 高德压测平台技术架构

    9.2 高德压测平台特点

    极速压测:

    对于大部分简单压测需求,TestPG提供极速压测的能力,只需要填写被测服务地址,设定压测必须的url,请求类型,请求字段,QPS,压测时长等信息,就可以开始压测。对于初次使用平台的用户,平均15分钟即能上手压测。

    调试能力:

    TestPG平台提供两种调试手段:挡板调试和服务调试。

    • 挡板调试:请求不会发往真实的服务,施压机作为调试挡板,对语料格式,url格式,请求参数进行校验。
    • 服务调试:平台将压测请求(默认20条请求)发往真实的被测服务,并详细记录请求的上行数据和下行数据,格式化后,通过平台展示给用户。

    调试的目的式帮助用户调整压测的参数,为正式的压测做好准备。

    错误定位辅助:

    TestPG平台会详细记录压测过程中出现异常的请求,对请求的上行数据和下行数据进行格式化保存,用户可以在压测过程中通过平台查看异常日志,定位错误原因。

    详细的压测报告&基线对比:

    TestPG平台在压测完成后自动产出压测报告,压测报告详细包括本次压测的整体、各场景、所有接口的QPS,RT,最大、最小RT,百分统计RT,错误请求数量,错误请求率。并且还包含压测时的实时QPS ,RT图表,以及被测服务的基础监控数据。

    此外,压测报告还支持基线对别,若设定了基线报告,后续产出的压测报告都会和基线进行对比,在报告中就会体现出服务性能的变化。压测报告的详细信息可以查看下文平台展示中压测报告部分。

    10.

    高德压测平台展示

    • 压测看板

    f395fbb3d6cc4d67bb1989ac4905e2d3.jpeguploading.4e448015.gif转存失败重新上传取消

    • 调试

    • 错误排查

    cf77a8151ffa4a8cb9162dea63d7466b.jpeguploading.4e448015.gif转存失败重新上传取消

    • 压测报告

    11.

    高德全链路压测的实践

    2018年十一是我参加了高德全链路压测,当时团队的同学一起聚在稳定性保障会议室里,对高德的核心链路进行了为期两周的全链路压测。

    高德的全链路压测流程是比较传统的方式,下图是历年全链路压测的大致流程:

    12.

    高德压测平台的现状

    高德压测平台从2018年开始启动,经过大半年的发展,已经成功支持了高德2019年春节全链路压测,2019年五一全链路压测,在施压能力方面达到 百万 级别。

    目前高德压测平台包括语料生产,场景构造,压测资源管理,压测任务调度,压测过程监控,压测调试,压测错误排查,压测报告生成,压测报告评估(对比基线,从QPS,rt,cpu,mem这几个维度进行压测结论的评估)等功能。

    平台从2018年底投入使用至今,共执行几千次的压测。通过开放api的方式,平台开放压测能力,现已成功和持续交付平台打通,为持续交付提供可靠的性能指标。

    自春节后,平台主要致力于降低压测门槛,提升压测效率。对于大部分简单的压测需求,从原有的语料->场景->任务逐级构造模式简化为一键压测模式,在初次使用平台成本方面,简单的压测工作预计能从平均3小时,减小为平均30分钟。

    虽然高德压测平台在近一年的时间里,取得了一些成果,我们也支撑了几次全链路压测。但是我们的全链路压测还不能完全满足上文的三个要求,其中最关键的场景真实性还无法得到保证,"全链路压测" 对于高德来说,还是远方,我们还有很多路要走,还有很多困难要克服。

    13.

    高德压测平台的未来

    在可见未来里,我们期望在以下几个方面去探索和实践:

    13.1 全链路监控

    TestPG目前的监控是基于用户自定义链路的监控,在链路真实性上无法得到保障。未来我们将会与运维团队合作,打造基于EagleEye链路自动梳理的全链路监控。除了基本的系统指标监控功能外,TestPG平台还会在下面的几个方面进行探索:

    • 监控大盘,全面的展示系统的状态
    • 短板机器,短板服务的识别
    • 基于时间序列的性能问题挖掘
    • 结合邮件,钉钉等手段,对发现的问题进行及时的报警

    13.2 简化语料生成流程

    目前压测语料的生成采用的是用户自定义脚本的方式。平台定义好语料目录格式,语料文件格式,用户编写语料处理(一般以日志文件为基础)的程序,然后上传到平台。平台会执行用户提供的程序,然后在将程序的输出文件存储在OSS上,以备压测之用。

    这种方式降低了平台的实现成本,也给用户提供了足够灵活度,但是增加了语料的处理门槛。未来我们会将这部分工作全部交由平台来处理,用户只需要提供原材料,配置生成规则即可。

    13.3 丰富压力模型

    TestPG平台目前的压力模型是Jmeter原生的,为了最大限度的接近真实场景,在压力模拟上,我们还需要具备如下几种压力模型:

    • 步进施压
    • 抖动施压
    • 脉冲施压

    13.4 压测置信度评估

    压测场景能否代表真实的用户场景?这是一个TestPG目前还无法回答的问题。场景的真实性现在依托于业务同学的经验,业务同学按照自己抽象出来的业务模型对原材料(通常是线上日志)进行处理,生成平台规定格式的预料文件。语料对平台和用户来讲,都是黑盒子,除了被测系统外,没人知道语料的模型是否接近真实世界的用户场景。

    因此,我们期望通过一些技术手段来对压测场景的真实性进行一个科学的评估,这便是压测置信度评估。置信度评估的目标是评估压测的场景和我们期望的场景相似度,下面是压测置信度评估需要探索的方向:

    • 建设场景特征库(例如五一,十一,春节)
    • 基于特征库的压测场景置信度评估
    • 基于地理位置的压测场景置信度评估
    • 基于链路覆盖度的压测场景置信度评估
    • 基于流量模型的压测场景置信度评估

    结合上述维度的评估数据,我们可以给出一个具有价值的评估报告,作为一个重要的参考,可以帮助用户评估压测的效度。

    13.5 链路改造

    TestPG平台的中期目标是要支撑高德业务的全链路压测,成为高德系统稳定性的试金石。但现在我们离真正的全链路压测的距离还很远,我们的压测场景只覆盖了读请求,还不具备支持写请求压测的能力,原因是系统还不具备全链路流量识别的能力,还不具备隔离压测流量的能力。未来,全链路压测,全场景覆盖是必经之路

    展开全文
  • 本文整理自 GOPS2017·上海站演讲 《从0到1:2天搭建互联网电商全链路压测平台》一、小红书前世今生2013年小红书成立之初,主要是让大家分享自己所购买的商品或者是使用好的商品、好的体验。在很短的时间内迅速成长为...
        

    0?wxfrom=5&wx_lazy=1?wx_fmt=png&wxfrom=5&wx_lazy=1

    本文整理自 GOPS2017·上海站演讲 《从0到1:2天搭建互联网电商全链路压测平台》

    一、小红书前世今生

    ?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

    2013年小红书成立之初,主要是让大家分享自己所购买的商品或者是使用好的商品、好的体验。在很短的时间内迅速成长为全国最大的商品分享社区。
    很多妹子看到这口红不错、那个包包很好看;很多口红是国外的,没有地方买。由此在2014年构建电商平台开始上业务。

    目前小红书已经成为国内最大的社区跨境电商之一。现在我们在上海、郑州、宁波和深圳有多个保税仓,为全国提供各类全球的好商品。

    二、快速成长的痛

    记得在2015年的时候,阿里双十一会场可能做了上千号的人来同时进行全链路压测。小红书因为成长的这三年非常迅速;和阿里、京东大厂曾经遇到的稳定性问题一样需要去面对、解决。主要有三个方面:

    • 其一,随着业务增长,人员、IT资源的扩张赶不上业务的快速发展。比如说,在负责稳定性保障这块,我们测试团队在构建全链路压测过程中也就两三位同学。相对于阿里、京东来说是数量级的差异。

    • 其二,以前基于单体python的系统架构在大促时常常成为瓶颈;

    • 其三,缺乏有效的性能和线上稳定性保障策略和实践。

    三、全链路压测系统架构

    对于全链路压测,阿里有PDS、京东有全链路压测平台。大厂这样的压测系统都是经过较长的时间不断迭代出来的。我们怎么办?我们没有那么的人力和资源;最核心的就是要搞定问题。

    在电商高峰期场景下,它的流量可能是平时的10倍甚至是几十倍。在这种情况下流量不是均匀地打到各个业务线的。例如,90%流量先进到主会场;再由主会场引流到各个分会场,然后是下单等等。整个过程是一个漏斗模型;这个可以用接口的水位对比来表示。为了保证模拟高峰期线上行为,我们需要基于水位对比对整个业务模型进行全链路压测。

    据此,我们的全链路压测系统架构分为四大块:

    ?wx_fmt=jpeg

    • 各个链路压测脚本配置管理;

    • 压测调度;

    • 统一压测数据管理;

    • 被测业务系统状态监控;

    ?wx_fmt=jpeg

    对于压测系统来说,最核心的就是压测脚本;怎么能够快速、方便的开发出来一大批链路的压测脚本。

    四、构建全链路压测:从0到1

    4.1、从0开始

    ?wx_fmt=jpeg

    6月6号大促是我们平常比较重要的三个大促之一。我们在5月接到需要保障今年大促的任务。当时整个测试的同学只有两人可以投入,运维同学只有一位可以支持。而开发的同学一直会致力于业务开发直到6月4号。同时测试系统方面基本上是白纸一张。

    4.2、压测模型

    要进行全链路压测则需要构建压测模型;就是要知道压什么、怎么压、压到什么样的水平。

    ?wx_fmt=jpeg

    • 首先,我们需要做链路的梳理。我们和开发、运维协作通过运维监控系统将线上接口所有列表获取到。

    • 然后,通过调用监控系统获取各个链路之间的配比关系。同时根据去年和日常链路监控的配比得知各个接口平时和去年大促在什么样的水平。

    • 最后,依据前面两个步骤去计算链路调用、压测脚本以及施压机等情况。

    据此,我们任何一个链路压测脚本都一共有四个压测的参数,分别为:

    ?wx_fmt=jpeg

    • 输出压力qps;

    • 当前水位;

    • 施压周期;

    • 压测链路;

    4.3、密切协作

    ?wx_fmt=jpeg

    在这样的情况下,对于我们测试的同学来说就简单了许多;我们可以将这个工具达成一个包方便部署。这样就可以和运维同学一起合作,一次性生成多台施压机器同时去压一个系统。目前,我们大概可以在五分钟之内能够创建出来400台以上的 压测容器也就是说快速输出5G以上的压力。

    ?wx_fmt=jpeg

    为了区分压测流量和真实线上流量,我们和开发同学全力协作对线上的每个测试数据进行打标。这样一来在出业务报告或数据报表的时候,我们有统一的框架将测试数据进行剥离;进而保证了测试数据不污染线上数据。

    全链路压测目标就是模拟真实的大促情况下,我们的各个链路能够承载多大流量以及各个业务系统的瓶颈点所在。

    五、压测之外

    ?wx_fmt=jpeg

    除了前述的全链路压测之外,我们这里还包括容量预估、降级方案、应急预案、大促演练以及值班计划。我们会通过流量历史监控来做容量的预估;同时,为压测基线和限流熔断提供依据。

    ?wx_fmt=jpeg

    ?wx_fmt=jpeg

    当线上业务流量水位超过我们设置的阈值的时候,为了保障线上运行稳定我们会对相关的业务进行功能降级。另外当线上水位超过我们原来预期的时候,我们会有相应的应急预案以降低容量不足带来的影响。

    六、年中66大促全链路实践

    ?wx_fmt=jpeg

    从5月6日开始立项到8号开始第一条链路施压,只用了两天我们实现了从0到1的跨越。其实对于从0到80%的这个过程,大家是可以很快做到的。因为对于运维同学来说这些工具、方法基本上是每天都在做的事情。复制从0到1的构建思路,我们在人员紧缺的情况下实现了预期目标。

    ?wx_fmt=jpeg

    最后,对于有兴趣开展线上全链路压测的同学有以下三点建议:

    1、先不要想大而全的平台化;

    2、关注系统的本身,从监控和限流开始做起;

    3、掌握全链路压测方法,快速构建实现从0到1;

    更多相关文章阅读

    用几行代码管理几十种网络设备

    携程运维自动化平台,上万服务器变更也可以很轻松

    智能运维就是 由 AI 代替运维人员?

    看腾讯运维应对“18岁照片全民怀旧”事件的方案,你一定不后悔!

    运行无间:阿里巴巴运维保障体系的一种最佳实践

    芳华永在!一个老运维的20年奋斗史

    饿了么异地双活数据库实战

    运维版《成都》,听哭了多少人...

    阿里万亿交易量级下的秒级监控

    IT 运维的救赎——顺丰运维的理想践行


    2018年,GOPS 全球运维大会第一站:深圳站

    —— AIOps 风向标

    第九届GOPS全球运维大会将于2018年4月13日-14日在深圳召开。

    ?wx_fmt=jpeg

    长按二维码,进入官网报名,大会早鸟价倒计时1个月

    3人以上团购优惠请联系刘静:130 2108 2989

    ?wx_fmt=png


    商务合作请联系刘欣:158 0111 5386

    了解大会详情、请点击“阅读原文”链接

    展开全文
  • 在上篇文章中,我们曾介绍过饿了么的全链路压测的探索与实践,重点是业务模型的梳理与数据模型的构建,在形成脚本之后需要人工触发执行并分析数据和排查问题,整个过程实践下来主要还存在以下问题: 测试成本较高...

    背景

    在上篇文章中,我们曾介绍过饿了么的全链路压测的探索与实践,重点是业务模型的梳理与数据模型的构建,在形成脚本之后需要人工触发执行并分析数据和排查问题,整个过程实践下来主要还存在以下问题:

    1. 测试成本较高,几乎每个环节都需要人力支撑,费时费力。
    2. 由于测试用例较多,涉及的测试机范围较广,手工执行容易犯错,线上测试尤其危险。
    3. 记录结果和测试报告极不方便,需要二次加工、填写和上传。
    4. 测试过程中靠手工监控,覆盖不全且定位问题困难。

    基于这些因素,我们决定推进全链路压测的自动化进程。这篇我们主要介绍全链路压测平台的实践。

    目标

    为了解决以上核心痛点,平台至少需要保证以下方面的功能:

    • 用例管理:用户建立测试用例,上传资源文件,系统进行分类管理。
    • 压测执行:一键触发已有测试用例,可指定线程数、预热时间、测试周期和测试机等,可以自动切分数据,分布式执行。
    • 实时结果(热数据):响应时间、吞吐量、错误率等数据以图表形式实时显示。
    • 测试结果(冷数据):平均响应时间、平均吞吐量,90/95/99线等数据以图表形式在测试结束后显示。
    • 测试机集群监控:监控测试集群的使用状态,提示用户可用的测试机。
    • 安全保障:平台应该对用户操作进行适当限制,并能自我应对一些异常情况。

    主要功能与实现概要

    压测平台是典型的B/S类型Java Web项目,基于Spring Boot开发,前端使用AngularJS。平台本身不执行测试只做调度,避免成为瓶颈,后台均使用JMeter执行测试;平台自身会维护压测机集群,保证压测机是可供测试的;测试期间产生的冷数据(用例数据、结果数据)持久化至MongoDB,热数据(实时数据)持久化至InfluxDB并定期清理。

     

     

    分布式测试

    在使用JMeter进行性能测试时,如果并发量比较大,单机的配置可能无法支持,这时需要联合多机进行分布式测试。我们并没有采用JMeter自身的分布式功能,而是自己做了实现,主要是考虑到:

    1. JMeter的分布式测试执行和单机执行方式的差异较大,这会导致平台架构不必要的复杂度,实际用户只感知测试机的数量区别。
    2. JMeter分布式执行的方式,master机通常不参与测试,而是收集slave信息,但这会造成一定程度上的资源浪费。

    我们使用饿了么内部的EOC工具对压测机进行调度,并实现了JMeter自身具备的分布式调度功能,相应的对比见下表。基于我们的实现,压测过程中热数据和冷数据是分离传输的,冷数据在测试完成后才会传输(如果不需要压测端数据,甚至可以配置不存储冷数据),因此该方案对于扩容是非常友好的,理论上支持的TPS没有上限。

     

     

    测试状态流转

    测试状态流转是压测平台的核心,每一轮正常的测试工作都会经历一条主线,即:配置 -> 触发 -> 运行 -> 结果收集 -> 清理。测试状态流转的设计围绕着这条主线,辅以外部干预和内部监控功能,保证测试的正常进行。

    此外,我们还需要鉴别出各种可能的异常情况(如测试触发失败)和合理情况(如用户主动停止),并据此输出不同的反馈信息,并且无论测试流程出现何种分支,最后都能形成闭环,这对系统的健壮性非常重要。以下是状态流转图:

     

     

    举两个典型的应用场景:

    1. 用户触发测试后,由于测试压力过大,运维要求立刻停止测试,这时的闭环为:初始 -> BOOTING -> LAUNCHING -> 用户触发停止 -> 直接进入收集流程 -> 状态标记为STOP -> 清理压测机 -> 初始
    2. 用户触发测试后,压测机由于某些原因突然断网,这时的闭环为:初始 -> BOOTING -> LAUNCHING -> 监控发现问题 -> 状态标记为FAILURE -> 清理压测机 -> 初始

    整个状态流转的实现,采用异步Job机制实现了类似状态机的概念,状态属性持久化到数据库中,便于恢复。

    实时数据

    JMeter本身并不提供图形化的实时数据展示功能,以往我们只能通过JMeter Log看到一些粗略的信息,并结合外部监控工具观察指标情况。在压测平台中,我们对该功能进行了实现,主要原理是通过JMeter的Backend Listener (JMeter 3.2+),将测试结果实时发往InfluxDB,同时平台向InfluxDB轮询查询数据,得到实时曲线并展示给用户。

     

     

    在实践过程中,向InfluxDB发送数据的频次是比较高的,可能会对压测机造成压力,因此我们改造了JMeter的InfluxDB sender,替换了HTTP方式,增加了以UDP协议发送数据的实现,解决了这一问题。

    预配置

    在“测试状态流转”一节中,阐明了测试的总体流程,第一步即为配置,配置的具体内容是:将测试需要的脚本、数据文件和插件,推送到每一台测试机上,为测试执行做好准备。

    但如果测试文件比较大,或者需要配置的压测机数量比较多,配置可能会占用较多时间,影响测试进程,这是很多平台遇到的共性问题。对此,我们提出了预配置的概念,即用户可以提前对测试用例,针对某几台压测机进行配置工作,但并不执行。预配置会保留一定的时间,在这段时间内,用户可以直接执行测试,不需要再重复配置。

     

    以下为预配置的状态转换图:

     

    熔断与兜底

    全链路压测一般都在线上真实环境进行,安全是首要考虑的因素,不能因为测试本身而导致服务不可用或事故。我们提供了四个维度的机制进行安全保障。

    1. 权限管理:用户权限分级管理,不能随意触发他人的测试用例,同时高峰期和禁止发布期,不允许执行任何测试。
    2. 停止功能:这是面向用户的手动停止功能,用户可以随时点击运行状态下的测试用例上的停止按钮,后台会直接kill掉所有运行该测试用例的测试机上的JMeter进程。
    3. 熔断功能:系统会根据实时信息中的错误率进行判断,当一定时间内的实时错误率达到或超过某个阈值时,该次测试将被自动熔断,无需用户干预。
    4. 兜底脚本:最极端的情况,当整个系统不可用,而此时需要停止测试时,我们提供了一份外部脚本直接进行停止。

    结果收集

    由于我们自己实现了JMeter分布式的管理,因此我们也需要自己对结果集进行处理,结果的主要来源为测试生成的JTL文件。

    针对JTL,结果数据需要做预聚合再存入,原因是JTL中单条结果数据的大小非常小(大约100多个字节),但总量很大(可能有几万到几百万条),很容易由于重复存储维度字段的KEY值而导致表过大。预聚合主要根据以label作大分类,维度作小分类,以时间作为聚合标准,interval固定,从而保证Document大小不会过大。

    以下是结果集片段的数据结构概要(单label):

     

    前端会根据持久化的数据,形成可视化图表,为用户展现。

    总结与展望

    全链路压测平台自今年7月上线以来,为超过5个部门累计提供了上千次测试服务。按照每一类测试配置和执行的人力成本为15分钟计算,大约节省了1000个小时的工作量。

    目前,全链路压测的自动化只是针对测试执行范畴,我们还有很多工作要做,在未来,我们希望能够将自动化的脚步覆盖到测试前和测试后,真正建设出全链路压测的自动化生态体系。

     

     

    参考:https://www.testwo.com/article/1104

    转载于:https://www.cnblogs.com/unknows/p/8622188.html

    展开全文
  • 原文:连接: https://tech.meituan.com/2018/09/27/quake-introduction.html 开源分布式监控Cat: https://github.com/dianping/cat 转载于:https://www.cnblogs.com/javallh/p/10675939.html...
  • 背景   在美团的价值观中,“以客户为中心”被放在一个非常重要的...在这种背景下,我们必须对服务进行一次方位的“体检”,从而来保障美团多个业务服务的稳定性,提供优质的用户服务体验。真正通过以下技术...
  • 在这种背景下,我们必须对服务进行一次方位的“体检”,从而来保障美团多个业务服务的稳定性,提供优质的用户服务体验。真正通过以下技术手段,来帮助大家吃的更好,生活更好: 验证峰值流量下服务的稳定性和伸缩...
  • 高德全链路压测平台的自建起因 身在阿里,说起全链路压测,首先想到的肯定是大名鼎鼎的Amazon平台,Amazon 诞生于2013年,自2013年起,Amazon一直作为淘宝、天猫稳定性保障体系中神一般的存在。经过多年的发展和...
  • 最近忙于公司的全链路压测平台调研和技术规划文档输出工作,参考了全网能搜到的业内大厂的全链路压测方案,这里做个汇总,以及将个人认为可以落地的方案做一个关键点整理。技术链接滴滴全链路压测解决之道阿里巴巴的...
  • 今天读了美团技术团队新发布的全链路压测平台Quake在美团中的实践,做个笔记。 先说下总的读后感: 压力测试/性能测试有多种方式,从下面的几个发展阶段可以看出越来越追求真实高峰访问的模拟。 现在大公司普遍的...
  • 全链路压测

    2021-02-01 20:04:39
    全链路压测改造的四大核心能力 全链路流量染色,通过压测平台对输出的压力请求打上标识(如图),在订单系统中提取压测标识,确保完整的程序上下文都持有该标识。 全链路日志隔离,当订单系统向磁盘或外设输出日志...
  • 去年双十一,为了应对零点的峰值...双十一之后,在CTO的指导下和支持下,由基架和性能测试团队快速的投入了全链路压测平台的研发当中。并且趁着核心系统重构,快速的接入落地,对后续的系统稳定性保障工作,迈出了坚...
  • 什么是全链路压测? 全链路压测解决什么问题? 什么时机下需要? 如何展开全链路压测? 梳理核心链路和边界 数据模型构建 流量平台搭建 容量规划 为什么需要容量规划 容量规划四步走 获取单台机器的服务能力 生产环境...
  • 全链路压测平台主要有两个核心的也是最顶级的要求: 全业务 全链路 这导致了,必须线上搞压测,必须用线上的真实数据搞压测。那么线上搞就容易搞出事情,所以技术含量还是要有的,还是很高的。 压测核心技术 1、...
  • 因此,在2018年春节前,基于美团基础的压测平台Quake,我们把整个境内度假业务接入了全链路压测,来系统性地评估容量和发现隐患,最终确保了春节期间系统的稳定。在整个过程中,我们意识到,全链路压测在整个系统...

空空如也

空空如也

1 2 3 4 5
收藏数 98
精华内容 39
关键字:

全链路压测平台