2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开。以“AI+未来”为主题，汇聚国内外测试领域知名专家学者、领先企业决策者、高级技术管理者、媒体从业者等，共同探讨高端云测试技术并帮助测试从业者了解最前沿的行业趋势，以及最新的行业实践。会上，VIPKID性能测试方向负责人宁浩然做了主题演讲《千万级约课系统自动化压测实践》。宁浩然分析了VIPKID在链路压测过程中遇到的问题和挑战，介绍了自动化压测平台如何解决代码级定位链路的性能问题，以及公司如何在无人值守的情况下完成自动化压测。测量。他指出，“对于测试开发工程师来说，最重要的不是为了开发而开发，而是发现工作过程中遇到的痛点，通过技术手段将那些可以重复或由机器替代的任务替换掉。”是我们的主要工作方向。”以下为宁浩然演讲实录：大家好，我是VIPKID的宁浩然，很高兴为大家带来这次分享。我的分享主题是《千万级约课系统自动化压测实践》，我会根据VIPKID的特点，分析我们在链路压测过程中遇到的问题和挑战，简单介绍一下开发的自动化压测平台是如何解决代码级定位链路的性能问题，以及我们是如何敢于无人值守完成自动化压测的.首先简单介绍一下我们的业务，VIPKID目前的业务是在线教育，简单来说就是用户可以使用我们的软件进行课程预约，在约定的时间内通过视频的方式完成在线一对一的在线课程.每周一中午，我们会开启下周课程的预约，届时，数十万用户将在短短一分钟内预订下周的所有课程，压力很大。每周一我对我们来说是一个很大的考验。现公司成立了专门的供需团队，专门解决用户需求方面的问题。目前的高峰流量已得到一定程度的缓解。因此，在本次分享中，我们将以业务和系统压力增长最快的2017-2018年为例，介绍我们如何度过每周的班级预约高峰期。从图中可以看出，我们系统的负载压力在一年内增加了13倍左右，每秒的排班数达到了上千节课。每个星期一的“大考”，对我们来说都是一次大考。越来越严峻，留给我们产研组的时间总是只有一周。挑战是什么？首先，您可以看看我们的班级预约链接。为了让我们的系统能够承受更高的压力，满足业务增长的预期，我们对链路上的每一个环节都进行了调整或优化。这些调整让我们的系统承载能力有了很大的提升，但是调整的过程无疑是非常痛苦的。当我们上到ELB、SLB，再到DB，每一次改动都或多或少存在着隐患。把这些隐患放到网上就是一场灾难。我们通过链路压测的方式对这些问题进行了召回，以确保在过去的两年里，我们保持了班级预约高峰期的稳定性。在过去的两年里，我们已经招募了近百个在线绩效风险案例。总结起来，我们面临的主要挑战有：1.上网非常频繁。你可能会说经常上网的特点是什么。作为一家互联网公司，哪个互联网公司不经常上网？这里上线很大一部分是服务重构、拆库和表优化项目。这些变化会影响到我们的核心课程预约环节，所以每次上线，我们都需要进行链接机压测试，那时候平均每周需要2-3次压力测试，是链接级别的.同时，由于我们链接的复杂性，也很难定位性能问题。对于我们来说，时间就是生命，我们需要在一周内完成系统整体性能提升30%的目标。这个数据是怎么来的？也就是说，在我们业务增长最快的时期，每周的业务增长大约是30%。虽然我们做了一些整体的大规模优化来提升我们系统的质量，但是我们每周还是需要针对具体的服务或者接口做一些具体的优化。从设计到开发，再到功能测试，再到性能测试，我们只有一周的时间，这就对我们的测试提出了很高的速度要求。我们当时给自己提出了一些指标。我们需要在一天内完成数百个接口的准备工作。比如我们当天提出压力测试需求，当天晚上就必须完成压力测试的实施。同时，如果当天压测发现问题，我们要在当晚对问题进行初步定位，因为我们通常在周四或周五进行压测，紧随其后的是高峰期。我们怎样才能快速准备？这个我以后再说。从2016年开始，我们就对系统进行了例行的链路压测。首先我们会统计周一高峰期的数据，然后确定下周的性能指标和我们的优化方向，并进行压测实施，包括一些问题的修复和回归。这是我们每周都会做的事情。从最初的人工准备阶段，到现在我们已经可以通过平台进行自动化压测，包括每周一自动拉取数据，生成脚本，有问题自动停止，没有问题自动生成报告等。发现任何问题。这两天开发测试的同学过来直接分析了，后面会详细介绍。对于我们平台来说，主要的目的无非就是提高我们压测数据和脚本的编写效率，以及压测结果分析的效率。因此，我们主要将其分为三个部分。一、压测准备主要是压测脚本和数据的准备。对于脚本，我们希望压测的比例能够和在线高峰期的实际接口请求比例保持一致。同样，我们可以通过简单的配置按比例增加或减少系统压力。对于一些不想做压测的接口，可以过滤掉。在数据方面，我们希望压测数据有足够高的复杂度和样本量，同时希望压测过程中不影响真实在线用户。目前我们通过拉取在线NG日志，高峰时间段，接口请求状态，响应时间，请求量等来计算我们分配给各个接口的新增数量，生成我们的压测脚本中，数据为也用于在高峰期向实际用户请求数据，并标记这些流量。在保证我们尽可能模拟线上真实情况的同时，不影响真实线上用户的使用。结果分析部分也是压测过程中长期存在的问题。比如压测出现问题，研发可能先查看NG日志或者服务器日志。各种监控平台，CPU，数据库等等，这些数据我们明明都有，但是到了排查的时候，对于一线的开发或者测试，我们往往不知如何下手。我们的压测平台会将本次压测相关的所有数据汇总，通过平台进行分析，然后给出定位结论。我们收集的数据不仅仅包括这次压测，还包括之前的，在线高峰期的数据，一是看这次有没有异常，二是可以更准确的定位问题在系统链路上比较。比如整个系统需要承载的压力是100000qps，其中一条接口线要求达到1000。其实到了500可能就不行了，这种问题在我们的链路压测过程中经常会遇到。暴露出来是非常困难的，因为它对我们整个系统的影响很小，我们根本看不出来，但是我们可以通过平台快速分析，这个数据的接口响应时间或者期望的QPS和实际QPS这部分的结果定位，这只是其中的一个，还包括主机上的问题等。我们的报告不仅仅反映压测结果，更重要的是可以提取或者压测出现的问题这次。帮助我们快速定位。还有一个很重要的一点就是监控。目前运维的监控平台是基于grafana的。优点是具有很强的扩展性和兼容性。可以增加各种类型的监控，但缺点是其入门成本或增加成本比较高。高，往往需要增加一个链路级的监控，时间会比较长。如果改了，肯定是运维提供的，需要他们去操作，因为一线人员有操作这个东西的能力。对于我们的压力测试来说，我们其实不需要一个扩展性这么好的监控平台。我们期望的是可以通过简单的配置快速生成我们的数据盘，方便我们定位。是的，我们每次关注的点是不会变的，比如host，只看cpu，load等的值所以我们现在的做法是通过填写你的来快速生成一个行情服务名称及其类型根据当前监控类型。还有一点就是，我们平时加的监控在压测过程中不一定能完全适用。比如主机和CPU平时设置为70%，就需要告警，因为我觉得这可能说明流量情况不正常，但是压力测试过程中可能很容易就把这个值给打破了。那么每一次链路压测都会收到大量无用的告警。其实报警太多和没有报警没有区别。没有人会阅读所有的警报内容。这么严重的问题往往被掩盖了，所以在我们的监控平台中，这部分监控会单独分离出来，也就是说这部分监控只会在每次开启压测的时候才开始。这部分监控也分为告警监控和停止监控，这也是我们进行自动化压测的基础。例如，当我们达到某个阈值时，我们认为需要报警通知，需要检查问题。然后当服务器承受不了的时候，就会自动停止。如图，这是我们的平台设计图，主要分为四个部分。一个任务调度处理模块，主要负责模块间的任务调度，包括压测启停、监控开关等。压测主要是接口和数据方向的准备。监控报表服务是启用监控、止损减损等服务，也是生成报表的服务。数据来源主要有两个，一个是运维监控平台，主要负责获取主机，DB等各种信息，还有一些信息，elk是一个日志平台，通过它可以根据线上拉取流量交通状况数据分析。以下是我们平台使用的接口。首先，我们会先配置压哪个域名，哪个时间段，总Qps期望，然后添加一个监控，包括每个监控阈值。添加完这些之后，我们一键启动，剩下的工作就是让平台代替我们生成脚本，运行，监控，上报分析。我们还有很多的报表维度，包括域名，主机，接口，还有一些下游的接口报表，可以看到这个接口的下游响应等。如图，这是我们监控的快照，包括四个部分:主机和数据库。这是我们的结果分析的报告页面。首先，我们会拿出一些错误率高，响应时间长的接口。你可以看到他们的问题。单击它可以看到它的单个接口、下游或本层。响应情况。右边是Qps和RT的曲线。现在压测工具生成的报告大多只有最高Qps、平均Qps、平均RT等数据。但是中间的服务抖动是看不见的，往往代表服务出现了一些问题。例如，将监控值作为压力测试结果。我们在用网上的数量来评价的时候，往往会带来一些误区。在我们的报告中可以看到本次压测的实际每秒响应时间和Qps，分为服务级别、域名级别、接口级别。这是我们其中一个下游API的调用情况。比如压测的时候，某个接口出现了问题，我们可以看到下游的情况是怎样的，我们可以提取下游的异常接口，定位到代码层面。调用了哪一行上游服务，相比前期，响应时间增加了，错误率增加了等等，我们通过重新封装组件来实现这个功能。分享一个压测过程中的实际案例。对于一个导致我们性能下降30%的性能问题，我们在10分钟内完成了链路问题的定位，并修复上线。当时的情况是这样的。压测发现我们系统的总Qps下降了30%左右，当时并没有大规模的代码改动。顶多是一些业务需求上线了。我们的自动化平台会立即定位我们的网络服务。入口IO异常，入口IO基本满。同时在接口报告中发现下游某个接口的响应时间比过去有很大的增加。我们可以看到，在这个接口的下游报表中，下游调用某个接口的响应时间也急剧增加。我们也定位到了接口的调用位置。当时我们直接去那一行代码，发现这确实是我们这周上线的。当时的情况是多取了一个无用的数据，可能是列表类型。接口直接取出明细数据，因为数据量比较大，直接把服务器的IO占满了，我们当时删除了这个无用的字段，然后重新验证，符合预期。其实这种问题如果人工去排查的话，周期可能会比较长，因为网络入口IO爆满等问题会导致所有接口的响应时间变长。在NG层的负载检查方面，各个接口的响应时间比较慢。生长并且很难区分或定位。我们使用该平台在数据准备和结果定位方面大大减少了人力和时间。可能有人会问，什么时候合适或者做平台？我觉得可能我们每个业务都不一样，不是每个公司都需要这样的平台。比如你的压测场景是单接口压测或者单项服务。定位问题比较简单，或者用jmeter做这个不一定比在平台上做差。我感觉效果可能是一样的，但是比如我们频繁重复的压测需求可能是更适用的场景。对于测试开发工程师来说，最重要的不是为了开发而开发，而是发现工作过程中遇到的痛点，把那些可以重复或者机器可以代替的工作，用技术手段代替。这是我们的主要工作方向。希望这次分享能给大家带来一些帮助。
