多线程压测_CBU20181218大促压测大图回顾

同学&＃xff0c;你想了解的CBU大促全链路压测吗&＃xff1f;

背景篇

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

数据构造篇

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

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

模型设计篇

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

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

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

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

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

本次大促的放大因子详情如下&＃xff1a;

各端的流量占比&＃xff1a;

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

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

拿下单应用orderplatform为例看看。

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

压测执行篇

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

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

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

创建一个场景

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

压测执行页面

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

有哪些地方要特别注意呢&＃xff1f;

1)创建链路的时候&＃xff0c;链路名称最好要填写。

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

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

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

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

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

监控工具篇

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

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

资源协调篇

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

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

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

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

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

• 压测执行夜&＃xff0c;准备夜宵。重要程度不言而喻

思考篇

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

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

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

2、怎样让我们的模型评估更加准确&＃xff1f;

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

3、如何提高机器资源的利用率&＃xff1f;

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

4、大促有新业务或者有新投放点&＃xff0c;预估会带来的新流量需要如何评估&＃xff1f;

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

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

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

附上主要内容的xmind图&＃xff1a;