其他测试框架 阿里巴巴全链路压测的实践

妖怪来了 for 阿里巴巴质量学院 · 2019年06月15日 · 最后由 望山跑马 回复于 2019年06月21日 · 8571 次阅读

前言

在阿里,每年的双十一可以说是聚光灯下的一个项目,可以说是技术人员的殿堂。技术质量同学保障的事情非常多,想讲清楚全部内容需要花比较多的篇幅;今天我只分享一个小点:质量同学如何确保零点高峰系统的丝般顺滑

背景篇

大促,大家肯定不陌生,双 11、双 12,CBU 一年三次的大促大家或亲身经历,或间接参与,大促文化早已深深融入在每一个阿里人的血液中。CBU 大促逐渐常态化,为保证大促系统的稳定,质量团队主导的全链路压测也在跟随着大促的脚步一步步改进,为大促保驾护航。全链路压测是一个系统工程,需要各业务线团队开发,测试合力完成。压测过程中也会用到诸多工具来提效。下面分别就压测的各个环节来介绍大促压测我们现在是怎么做的。

数据构造篇
压测过程中会产生大量的压测数据,这些数据是不能写入到线上的数据库表上的。所以需要构造影子链路,压测过程放到影子链路上就能避免数据混乱。那影子链路是如何构造的,如下图所示,链路的各层完成改造后,在访问的链接上带入压测标 tb_eagleeyex_t=1。


DB 里的影子表和影子数据是通过集团 f11 平台构建,如何上手该工具,参考 ATA 文章。做法是将真实表同步一份有前缀_test表名,然后通过工具将真实的数据做一个偏移得到影子数据。这里要注意几点,有些数据是按照 member_id 取模做分库分表规则的,这时候需要注意分库分表的规则是不是和现实的一致;还有部分数据需要另外的写入缓存,这时候需要借用 hsf 平台打开影子表开关,来完成写入。

模型设计篇

压测模型设计,直接关系着压测准不准确,模型的设计其实是压测方法论最核心的一环。模型的设计可以分为宏观和微观两个方面。宏观看总体的放大因子,场景的流量放大,微观关注具体的应用接口。

宏观把握整体:大促预估的总买家数,会员 UV,部分场景引流,新业务场景(此部分难以评估)。那这里整理了本次 1218 大促的一些数据作为参考例子,下图是 1218 大促的目标。

鉴于 920 大促的时候全站会员 UV 和买家数已经达到 1200W 和 200W,对于这次大促的目标,大促压测在制定压测宏观放大因子是按照 1700W 的会员 UV 和 215W 的买家数来评估,具体的数据如下图:

为什么要预估 1700W 的会员 UV,主要有两点。第一是压测的预估会员 UV 一般都会比目标会员 UV 略高;第二是 920 大促预估的压测会员 UV 已经有 1400W 了,考虑到 C 端用户的历次大促增长,对比往届的数据,预估到 1700W 的会员 UV 比较保险。而最终的数据也和压测预估值非常接近。

通过会员 UV 值来评估大促总体的放大因子,目前使用的是本团队开发的容量评估工具。通过工具可以计算各端的大促的放大因子,工具的使用方法请参考这里。

本次大促的放大因子详情如下:

各端的流量占比:

在微观层面,就需要下沉到应用接口级别了。不同的应用在设计压测模型的时候也会有所不同,具体需要因应用施策。早期的压测模型只关注应用的总 qps 以及个别接口的 qps,这样的模型设计是可以更加准确的,最近一次压测的模型设计除了关注接口的 qps 外新增了关注上游来源是否准确以及接口的 rt 值和以往大促真实值对比。具体如下图所示:

当一个应用有非常多的接口的时候,压测过程中不可能一一查看,选择的原则是部分核心接口(涉及核心链路接口必考虑,其次考虑高 qps 和长 rt 的重要接口)。很多下有应用是通过上游应用来(或者是上游和自身)来压测的,如 mkc、offer_cbu 这些核心应用。上游数据构造得准不准确,直接关系着下游各接口的流量配比(目前人工构造数据的数量和类型丰富度有限),这次大促依然有部分应用的接口配比依然不准确。这一点是下次大促压测亟需覆盖的点,mark 下。

拿下单应用 orderplatform 为例看看。

总体的实际值是爆发值的 80% 左右,在预期之中。看数据 PC 的下单在大促爆发时的占比越来越低,现在是 1.8%,所以在大促压测的时候对 PC 下单的场景已不作为重点考虑。对于无线会场的一些应用需要多场景混合压测,应用的模型设计和评估方法又会有较大的差异,所以具体的应用还需要具体对待。

压测执行篇

全链路压测前需要做很多工作,如模型评估,单机水位评估等。单机水位压测,集团也有很多工具可以使用,这里列举两个目前比较常用的,一个是 csp 单机引流,另一个是 pas 性能评估平台。

csp 单机引流顾名思义,就是将线上的流量引流到一台机器上,进而来评估该机器的水位。在引流的过程中要时刻关注机器的负载和其他表现,因为一旦出现问题,影响的可是线上,容易报故障。下面贴一张图来看下配置的核心点。

pas 性能评估平台,原理和 amazon 平台(后面会介绍)类似,是通过施压机器来压测目标机器,可以只压测影子链路,这样就不用担心影响线上了,随便你怎么玩。平台提供的功能很丰富,但目前这个平台我用的最多的还是针对应用的单个接口来进行压测。这里介绍下如何配置。

创建一个场景

加入测试计划(可以多个),指定压测的 hsf 接口。

压测执行页面

还有一个最重要工具是全链路压测平台 amazon,目前集团大部分的全链路压测都是通过这个平台来执行的,因为涉及的 BU 众多,压测前要关注平台是不是被禁用了(如双 11,双 12),被禁用会比较麻烦需要找相关人审批。第一次上手 amazon 平台,会有一些使用上多不习惯。因为有很多地方有默认的规则,不看规则就使用,基本上一踩一个坑。所以还是要先看文档(ata,官方都有很多),熟悉之后就可以使用这个平台执行全链路压测了。

有哪些地方要特别注意呢?

1)创建链路的时候,链路名称最好要填写。

2)数据来源,一定要检查是否含有空格(如果压测数据里有登陆的操作,一定要让文件名含有 1688!!!)

3)某些应用如果出现机房调用不均等,需要设置 dns 绑定

4)压测执行时,速率控制使用百分比来控制会让你更加游刃有余。

除了压测工具的一些 Tips,1218 压测执行策略新增了摸高(触发限流)和模拟秒级脉冲两个内容。

下图为第二次压测的压测计划

监控工具篇

集团查看应用接口 qps 的工具 eagle-eye 功能很强大,也是压测过程中查看接口 qps 主要工具。但目前 eagle-eye 统计的 qps 数据是分钟级被平均的 qps,因为是被平均了,所以在大促爆发的时候通过 eagle-eye 看到的接口 qps,都是不准确的。具体也要看业务场景,类似下单的秒级爆发场景,经验是真实 qps 是 eagle-eye 统计的 qps 的 1.5~2 倍左右。通过 sunfire 配置业务的秒级监控可以获取到真实的秒级值,但目前依然有很多业务线团队没有完成这一基础设施建设。配置 sunfire 秒级监控对大促压测意义非常,配置好 sunfire 监控,压测过程看数据相当给力。如何配置请查看文章 1 & 文章 2。

下图为压测流量下单的 sunfire 监控。

资源协调篇
大促压测是 CBU 一个较大型的技术协作,涉及到的业务线较多,而且有时会和集团的资源有冲突,过程中有一些资源协调工作也必不可少。

发送 GOC 公告通知。每次大促压测前需要发布 GOC 公告告知集团,以免和集团资源冲突

尽早确定流量配比。流量配比直接关系单元数据构造和机器数量,越早确定越好

压测平台 amazon 封网冲突。amazon 平台遇到集团的双 11、双 12 就会有段时间封网,提前预见封网风险

提前预定压测会议室。需要提前准备插线板

压测执行夜,准备夜宵。重要程度不言而喻

思考篇
在压测的过程中和自己的 leader、压测测试同学交流了很多压测的经验和思考,获益颇丰。其中有一些问题我觉得可以有答案,更多的问题是没有答案的,欢迎大家将各自的思考贴到评论区,作为后续压测的食粮。

1、为什么要做大促压测(大促压测的意义)?CBU 大促的总 qps 量级目前和双 11、双 12 相比,还是有很大差距,而每年大促压测要投入很多的人力成本,这些人力成本如何和机器成本相比更加高的话,我们是不是可以堆足够的机器,或者未来的机器运维能做到灵活的动态扩缩容就能保证系统的绝对稳定。

大促压测肯定是需要的。原因在于系统的稳定性和多方面有关,机器计算资源只是其中一小部分。在压测的过程中,会发现 90% 以上的问题都不是机器资源不够的问题。大部分都是譬如 tair 超时,代码多线程处理不合理这类问题。我更觉得大促压测更像是一次技术的大阅兵,在阅兵过程中会暴露问题,保证这些问题不在大促发生。

2、怎样让我们的模型评估更加准确?

这个问题没有答案,应该是每次大促压测追求的目标。从评估到设计再到执行都有很大的空间来做。如上文介绍,这次压测中,加入了关注接口上下游配比,评估应用核心接口,模拟秒级脉冲,摸高模拟限流这些都在模型上做的一些探索。

3、如何提高机器资源的利用率?

当时有讨论过一个限流的方案(参考淘系)。

4、大促有新业务或者有新投放点,预估会带来的新流量需要如何评估?

在第二次压测结束后,了解到支付宝端的货源市场页面上了新页面后,日常流量有大量增加,而且当时支付宝投放的策略也不定,大促可能会有爆发性的增长。当时评估流量基本靠经验,但谁也无法保证这个值就 OK。这个评估的方法和依据需要业务方也一起参与建设。

还有很多问题,如大促会场搭建完成比较晚的问题、无线各端应用混压问题等等,这些都是大促压测待解决的问题,道阻且艰,需要我们一同迎难而上。

最后,感谢一起为大促奋斗的兄弟姐妹!感谢为大促压测更完美而一起献谋献策的同学(@ 重虎、@ 长臂、@ 定果、@ 悟极、@ 婉佩、@ 剑飞、@ 昌琪、@ 辰东、@ 芯壹...太多同学不一一列举)。也欢迎大家将对本次大促压测的建议加入到评论区,为后续大促压测做得更好献锦囊妙计。

附上主要内容的 xmind 图:

其他:

此专项是阿里技术质量的 “爱迪生” 参赛作品。什么是爱迪生?顾名思义,爱迪生是伟大的发明家,那此活动主要是鼓励测试工程师能够通过发明创新,用技术的手段提升测试效率,保障线上稳定;

此活动后续的系列分享都会放到微信公共账号;

有什么想了解的可以直接留言。

共收到 2 条回复 时间 点赞

顶!d=====( ̄▽ ̄*) b

这个真心厉害,

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册