CN107872397A - 压测过程中的流量调度方法、调度平台和调度系统 - Google Patents

Abstract

本申请提供了压测过程中的流量调度方法、调度平台和调度系统，其中，流量调度方法包括：在多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，如果是，则将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎。采用本申请实施例的流量调度方案，可以保证压测过程的顺利进行，并通过压测方案的执行真实模拟实际应用中海量用户请求增多的应用场景，从而减少实际中应用服务器可能存在的崩溃风险，也能提升用户体验。

Description

压测过程中的流量调度方法、调度平台和调度系统

技术领域

本申请涉及互联网技术领域，特别涉及一种压测过程中的流量调度方法、调度平台及调度系统。

背景技术

压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。一个业务线的压测需求通常称为一个压测方案，例如，天猫首页为待压测对象，需要对其压测1000每秒查询数(QPS)，就是一个压测方案。压测方案通常由压测引擎执行，压测引擎可以部署在物理机上，压测引擎上安装的多个应用程序APP可以模拟客户端执行压测方案，即模拟客户端向待压测对象发起访问请求。假设一个压测方案是在1秒内1000个APP模拟客户端向天猫首页发起QPS请求，具体的，压测引擎上的各APP模拟客户端访问天猫首页上的功能链接天猫超市，或，点击天猫首页上的图片链接访问店铺，等等，该一次访问或点击等操作即为一次查询。通常，一个压测方案需要多个压测引擎同时发起QPS请求。

发明内容

但是发明人在研究过程中发现，物理机的性能和资源是有限的，在压测引擎上各APP模拟客户端产生的访问流量过大的时候，可能会出现压测引擎无法正常执行压测方案的情况，此时压测引擎按照压测方案发起的QPS请求将无法匹配该压测方案，即实际发起的QPS请求无法达到在压测方案中预先设置的目标QPS请求的情况。这就会使得压测方案无法真实模拟线上用户请求峰值，在实际中如果线上用户请求在同一个时刻海量增加，将会导致实际中应用服务器由于用户请求过多而崩溃，不仅会给应用服务器带来无法弥补的性能和资源损失，还会影响用户体验。

基于此，本申请提供了一种压测过程中的自动流量调度方案，用以在压测过程中自动对满足流量调度条件的压测引擎上各个APP产生的流量进行调度，从而使得压测过程中各个压测引擎能够正常执行压测方案，真实模拟同一个时刻海量增加用户请求的实际场景，例如大促，从而减少用户请求增加过多给应用服务器带来的性能和资源损耗，并且提升用户体验。

本申请还提供了一种调度平台和调度系统，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本申请公开了一种调度方法，该方法应用于与多个压测引擎相连的调度平台上，所述多个压测引擎执行同一个压测方案；该方法包括：

在所述多个压测引擎执行所述压测方案的过程之后，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；

根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，如果是，则将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎上。

其中，所述流量调度参数包括：所述压测引擎的每秒查询率、CPU利用率和/或平均响应时间，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，包括：

判断所述压测引擎的实际每秒查询率是否与预先设置的目标每秒查询率匹配；

判断所述CPU利用率是否表示所述压测引擎的健康状态较差；和/或，

判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢。

其中，所述判断所述压测引擎的实际每秒查询率是否与目标每秒查询率匹配，包括：

判断所述压测引擎的目标每秒查询率与实际每秒查询率的差值是否大于预设查询差值。

其中，所述判断所述CPU利用率是否表示所述压测引擎的健康状态较差，包括：

判断所述压测引擎的CPU利用率是否大于预设利用阈值。

其中，所述判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢，包括：

判断所述压测引擎的平均响应时间是否大于预设响应阈值。

其中，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，还包括：

判断待调出流量的压测引擎的个数是否小于所述多个压测引擎的总个数的一半。

其中，所述获取所述多个压测引擎相关的流量调度参数之前，还包括：

判断所述压测方案的连续调度次数是否小于预设次数阈值，如果是，则执行所述获取所述多个压测引擎相关的流量调度参数的步骤。

其中，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度之前，还包括：

判断所述压测引擎的目标每秒查询率是否产生了变化，如果否，则执行所述根据所述压测引擎的性能判断所述多个压测引擎是否需要进行流量调度的步骤。

其中，所述获取所述多个压测引擎相关的流量调度参数，具体为：获取一个预设周期内所述多个压测引擎相关的流量调度参数。

其中，在判断得到所述多个压测引擎需要进行流量调度之后，还包括：

在下一个预设周期内，继续根据实时采集的压测引擎的流量调度参数，判断所述多个压测引擎是否需要进行流量调度，如果是，则执行将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎的步骤。

其中，所述将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎上，包括：

将所述正常压测引擎按照CPU负载从小到大的顺序进行排序；

按照一一对应的方式，依次将待调出流量的异常压测引擎的流量，调整预设流量比例至排序后的正常压测引擎。

本申请还公开了一种调度平台，该调度平台与多个压测引擎相连，所述多个压测引擎执行同一个压测方案；该调度平台包括：

获取单元，用于在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；

第一判断单元，用于根据所述压测引擎的性能判断所述多个压测引擎是否需要进行流量调度；

调度单元，用于在所述判断单元的结果为是的情况下，将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎。

其中，所述流量调度参数包括：所述压测引擎的每秒查询率、CPU利用率和平均响应时间，所述第一判断单元包括：

第一判断子单元，用于判断所述压测引擎的实际每秒查询率是否与预先设置的目标每秒查询率匹配；

第二判断子单元，用于判断所述CPU利用率是否表示所述压测引擎的健康状态较差；

第三判断子单元，用于判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢。

其中，所述判断单元还包括：

第四判断子单元，用于判断待调出流量的异常压测引擎的个数是否小于所述多个压测引擎的总个数的一半。

其中，该调度平台还包括：

第二判断单元，用于判断所述压测方案的连续调度次数是否小于预设次数阈值。

其中，该调度平台还包括：

第三判断单元，用于判断所述压测引擎的目标每秒查询率是否产生了变化；

触发单元，用于在所述第三判断单元的结果为否的情况下，触发所述第一判断单元。

其中，所述获取单元具体用于：在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息。其中，所述调度单元包括：

排序子单元，用于将所述正常压测引擎按照CPU负载从小到大的顺序进行排序；

调整子单元，用于按照一一对应的方式，依次将待调出流量的异常压测引擎的流量调整预设流量比例至排序后的正常压测引擎。

本申请还公开了一种流量调度系统，该系统包括调度平台和与所述调度平台相连的多个压测引擎，所述多个压测引擎执行同一个压测方案；所述调度平台包括：

获取单元，用于在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；判断单元，用于根据所述压测引擎的性能判断所述多个压测引擎是否需要进行流量调度；调度单元，用于在所述判断单元的结果为是的情况下，将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎；

所述压测引擎用于向所述调度平台提供相关的流量调度参数。

与现有技术相比，本申请包括以下优点：

在本申请实施例中，在一个压测方案的压测过程中，通过对执行该压测方案的各个压测引擎上流量调度参数的监控，获得各个压测引擎上的流量调度参数，例如CPU利用率，实际QPS请求，目标QPS请求，CPU负载等，并根据实时监控的流量调度参数判断各个压测引擎是否需要调度，在满足流量调度条件的情况下，再对待调出流量的异常压测引擎和调入流量的正常压测引擎实施预设调度方案，从而在压测过程中自动调度流量，将无法达到压测方案需求的异常压测引擎上的流量分配到其他的正常压测引擎上，以保证压测过程的顺利执行，并通过压测方案的执行真实模拟实际应用中海量用户请求增多的应用场景，从而减少实际中业务服务器可能存在的崩溃风险，也能提升用户体验。

进一步的，为了保证判断的准确性和系统的稳定性，还可以先设置一个扫描周期，在第一个扫描周期如果判断得到需要进行流量调度的结果，则再采集一个周期内的流量调度参数来进行判断，如果仍然得到需要进行流量调度的结果再进行调度。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的在实际应用中的场景架构图；

图2是本申请的流量调度方法实施例的流程图；

图3是本申请的流量调度方法的具体例子的流程图；

图4是本申请的调度平台实施例的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参考图1所示，为本申请实施例在实际应用中的场景架构图。在实际应用中，压测引擎103一般部署在物理机上，用来接收调度平台102发起的命令并执行，例如，调度平台102向压测引擎103发起压测请求或者调度请求等。调度平台102用来采集各个压测引擎的流量调度参数，并根据流量调度参数决策是否需要调度；调度平台102还可以控制压测流程，例如，是否压测，是否停止，或者，压测过程中流量如何调整等。调度平台102和多个压测引擎103构成了调度系统101。一个压测方案通过需要多个压测引擎103上的各APP模拟客户端同时发起每秒查询数(QPS)请求。其中，一个压测方案指的是一个业务线的压测需求。

参考图2，示出了本申请一种流量调度方法实施例的流程图，该方法可以应用于图1所示的调度平台102上，该调度平台102与多个压测引擎103相连，这多个压测引擎103共同执行同一个压测方案，本实施例可以包括以下步骤：

步骤200：在所述多个压测引擎执行压测方案的过程中，判断所述压测方案的连续调度次数是否小于预设次数阈值，如果是，则进入步骤201。

在本实施例中，调度平台确定了压测方案之后，会将压测方案发送至多个压测引擎执行，例如将10000qps的压测方案平均分配至10个压测引擎执行，则平均每个压测引擎需要执行1000qps的压测方案，即每个压测引擎需要模拟1000qps的用户请求。

可选的，在本实施例中，为了保证一个压测方案的连续调度次数不会太多，因为调度次数太多会影响执行该压测方案的多个压测引擎的稳定性和性能，所以本实施例在执行步骤201之前，在该多个压测引擎执行同一个压测方案的过程中，还可以判断该压测方案的连续调度次数是否小于预设次数阈值，该连续调度次数用来表示一个压测方案的压测过程中压测引擎已经进行调度的次数。可以预先设置一个预设次数阈值，例如4次，当连续调度次数小于4次时，可以执行步骤201对该压测方案涉及的压测引擎执行调度流程，而如果连续调度次数等于或者大于4次，则为了保证压测引擎的稳定性，可以不再执行步骤201对这些压测引擎执行调度流程，或者，等待一段时间后继续执行本步骤进行判断，例如10ms或20ms等。

步骤201：在多个压测引擎执行压测方案的过程中，调度平台获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息。

在本申请实施例中，在多个压测引擎执行压测方案的过程中，调度平台可以通过扫描压测引擎来实时监控各个压测引擎的流量调度参数，其中，该流量调度参数可以表示出压测引擎的性能和流量信息。例如，流量信息可以包括：各个压测引擎的目标QPS以及实际QPS，多个压测引擎的总目标QPS以及总实际QPS；在一个压测方案中目标QPS是预先设置的。压测引擎的性能可以包括：各个压测引擎的CPU利用率、CPU负载和平均响应时间。其中，平均响应时间指的是该压测引擎在一个压测方案中对于所有QPS请求的平均响应时间。

还可以理解的是，调度平台在扫描压测引擎以获得流量调度参数的时候，可以预先设置扫描周期，例如可以设置为5秒钟扫描一次压测引擎。则在一个5秒周期内，调度平台通过扫描可以获得一个预设周期内多个压测引擎相关的流量调度参数。

步骤202：判断所述压测引擎的目标每秒查询率是否产生了变化，如果否，则进入步骤203。

在执行步骤201之后且执行步骤203之前，可选的，可以先判断各个压测引擎的目标QPS是否发生了变化。因为如果某个压测引擎的目标QPS发生了变化，则表示该压测引擎是用户自主调整目标QPS的，因此，此时不需要对该压测引擎执行图2所示的流量调度方法。即，如果本步骤的判断结果为是，则不执行后续调度流程，可以继续执行本步骤进行判断，或者等待一段时间后执行本步骤进行判断，例如5ms或3ms等。而如果压测引擎的目标QPS没有发生变化，则表示压测引擎已经开始执行压测方案，在这种情况下进入步骤203。

步骤203：根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，如果是，则进入步骤203。

在本步骤中，可以根据步骤201中获取到的流量调度参数来判断多个压测引擎是否需要进行流量调度。其中，流量调度参数可以至少包括：所述压测引擎的实际QPS和目标QPS、CPU利用率和平均响应时间，则本步骤需要分别判断压测引擎的实际QPS是否与预先设置的目标QPS匹配，或者，判断压测引擎的CPU利用率是否表示该压测引擎的运行程序较多，或者，判断该压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢。

其中，在判断压测引擎的实际每秒查询率是否与目标每秒查询率匹配时，可以预先设置一个预设查询差值，例如，4％，那么，当某个压测因实际QPS小于目标QPS的数值大于该预设查询差值的时候，就认为该压测引擎的实际QPS与目标QPS不匹配。在这种情况下该压测引擎需要进行流量调度。当然，4％仅仅是一个数值示例，本领域技术人员在实际应用中可以根据各个压测引擎的性能或者调度需求进行自主调整。

其中，在判断压测引擎的CPU利用率是否表示压测引擎的健康状态较差时，也可以预先设置一个预设利用阈值，例如，80％，那么，当监控到的压测引擎的CPU利用率大于80％的时候，就表示该压测引擎上健康状态不够好，即该压测引擎需要进行流量调度。其中，CPU利用率是压测引擎上的各APP模拟客户端向待压测对象发起访问请求时所耗费的压测引擎的CPU利用率。当然，80％仅仅是一个数值示例，本领域技术人员在实际应用中可以根据各个压测引擎的性能或者调度需求进行自主调整。

其中，在判断压测引擎的平均响应时间是否表示压测引擎的响应速度较慢时，也可以预先设置一个预设响应阈值，例如800ms，那么当一个压测引擎上所有的链路(即QPS请求)的平均响应时间大于800ms时，则认为该压测引擎的平均响应时间表示其响应速度较慢，在这种情况下，该压测引擎认为是需要调出流量的压测引擎。当然，800ms仅仅是一个数值示例，本领域技术人员在实际应用中可以根据各个压测引擎的性能或者调度需求进行自主调整。

可选的，在步骤203进行QPS请求、CPU利用率和平均响应时间的判断之后，还可以对满足这三个条件的压测引擎的个数是否满足调度需求进行判断。即判断待调出流量的压测引擎的个数是否小于所述多个压测引擎的总个数的一半，如果是，则进入步骤204，如果否，则可以继续执行本步骤进行判断，或者等待预设时间后执行本步骤进行判断，例如，等待5ms。当然，5ms只是举例示意，不应将其理解为本申请的限定。

具体的，可以统计待调出流量的压测引擎的个数，看该个数是否小于或者等于多个压测引擎的总个数的一半，即，判断待调出流量的压测引擎是否不大于多个压测引擎总数的二分之一。因为，在本实施例中，是将待调出流量的压测引擎按照一一对应的方式来将流量调整至正常压测引擎上，当待调出流量的压测引擎的个数超过总数的二分之一的时候就无法实施流量调度，因此，当待调出流量的压测引擎的个数大于多个压测引擎的总个数的一半时，就停止执行流量调度流程。例如，压测引擎一共有10个，当待调出流量的压测引擎的个数小于或者等于5的情况下，执行后续的流量调度流程，而如果待调出流量的压测引擎的个数大于5，则不执行后续的流量调度流程，结束流程。

步骤204：将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎。

可以理解的是，在执行步骤204之前，为了保证流量调度的准确性，可以不仅对一个周期内的流量调度参数进行监控，例如，在第一个预设周期内如果判断得到需要进行流量调度，则还可以再采集一个周期内的流量调度参数，并执行步骤202～步骤203的判断过程，如果仍然判断得到需要进行流量调度的结果，再执行本步骤。

在本步骤中，将待调出流量的异常压测引擎上的流量按照预设调度方案，例如，调整30％的流量，调整至正常压测引擎上。具体的，可以将正常压测引擎按照CPU负载从小到大的顺序进行排序，然后按照一一对应的方式，依次将待调出流量的异常压测引擎的流量调整预设流量比例(即30％)至排序后的正常压测引擎。例如，针对前述的10个压测引擎，记为压测引擎1、压测引擎2……压测引擎10，待调出流量的压测引擎为压测引擎1、3和4，其他七个压测引擎按照CPU负载从小到大的顺序排列为：压测引擎2、7、8、10、9、6和5。可以理解的是，待调出流量的压测引擎1、3和4可以对应分别调整至压测引擎2、7和8(CPU负载最小的三个压测引擎)上。

在本步骤中假设预设流量比例为30％，则调度平台可以向压测引擎1重新发起1000*(1-30％)qps的压测方案，即向压测引擎1发起模拟700qps的请求的压测方案，对压测引擎1来说，其模拟的qps请求的数量就减少了30％，相应的，压测引擎1上产生的流量也会减少30％，从而实现对压测引擎1的流量调度。而压测引擎1上减少的那30％的流量可以分配至压测引擎2上，即，调度平台可以重新向压测引擎2发起1000*(1+30％)qps的压测方案，从而实现将压测引擎1的30％的流量调整至压测引擎2的目的。接着，调度平台分别对压测引擎3和4执行如压测引擎1的调度方案，以及分别对压测引擎7和8执行如压测引擎2的调度方案。。

可见，在压测过程中，通过对各个压测引擎上流量调度参数的监控，获得各个正在执行压测方案的压测引擎上的流量调度参数，例如CPU利用率，实际QPS请求，目标QPS请求，CPU负载等，并根据实时监控的流量调度参数判断各个压测引擎是否需要调度，在满足流量调度条件的情况下，再对待调出流量的异常压测引擎及调入流量的正常压测引擎实施预设调度方案，从而在压测过程中自动调度流量，将无法达到压测方案需求的压测引擎上的流量分配到其他的压测引擎上，以保证压测过程的顺利执行，并通过压测方案的执行真实模拟实际应用中海量用户请求增多的应用场景，从而减少实际中应用服务器可能存在的崩溃风险，也能提升用户体验。

参考图3，示出了本申请流量调度方法实施例的流程图，本实施例可以应用于调度平台上，该调度平台与执行同一个压测方案的多个压测引擎相连，本实施例是在实际应用中的一个具体例子，本例子可以包括以下步骤：

步骤301：在多个压测引擎执行压测方案的过程中，判断该压测方案的连续调度次数是否小于4次，如果是，则进入步骤302。

在本步骤中，调度平台首先判断当前正在执行的压测方案的连续调度次数是否小于预设的次数阈值4次，如果小于，再进入步骤302，如果不小于则终止流程。

步骤302：在多个压测引擎执行该压测方案的过程中，在两个预设5s周期内，调度平台获取相连的多个压测引擎的实际每秒查询率、目标每秒查询率、CPU利用率和平均响应时间。

在本例子中，周期设置为5秒，为了保证对压测引擎准确判断是否需要进行调度，在本步骤中可以采集两个5秒周期内各个压测引擎的流量调度参数，包括实际QPS、目标QPS、CPU利用率和平均响应时间。此外，还可以包括一个周期内的调度次数，等等。

步骤303：调度平台判断所述压测引擎的目标每秒查询率是否产生了变化，如果否，则进入步骤304。

在确定了所有待调出流量的异常压测引擎之后，调度平台判断压测引擎的目标QPS是否由用户正在手动修改，由于用户手动修改目标QPS到开始压测之间，有一个流量平稳的过程，在此期间是不需要调度压测引擎的，如果用户不再修改目标QPS，则可以执行步骤304，如果正在修改目标QPS，则可以等待20s再进行判断。其中，该20s是经验值，本领域技术人员也可以自主设置。

步骤304：调度平台判断压测引擎的实际每秒查询率是否与预先设置的目标每秒查询率匹配，压测引擎的CPU利用率是否表示该压测引擎的运行程序较多，和/或，该压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢，如果是，则进入步骤305。

调度平台判断压测引擎的实际QPS是否达不到目标QPS的97％(即实际QPS小于目标QPS的数值大于预设查询差值3％)，或者，调度平台判断CPU利用率是否大于预设利用阈值80％，或者，调度平台判断压测引擎的平均响应时间是否大于预设响应阈值800ms。可以理解的是，这三个条件只要有一个条件满足，就认为该压测引擎是待调出流量的压测引擎，当然，也可以任意两个条件满足才进行流量调度。在实际应用中本领域技术人员可以自主设置。调度平台在对多个压测引擎进行判断之后，可以确定出所有待调出流量的压测引擎，从而得到待调出流量的总个数。当然，如果三个条件都不满足，则可以继续执行本步骤，或者等待一段时间之后在执行本步骤。等待时间长短可以由本领域技术人员自主设置。

步骤305：调度平台判断待调出流量的异常压测引擎的个数是否小于所述多个压测引擎的总个数的一半，如果是，则进入步骤306。

假设调度平台发起的一个压测方案中涉及的所有压测引擎有6个，分别为压测引擎A、压测引擎B、压测引擎C、压测引擎D、压测引擎E和压测引擎F。那么，本步骤就是判断步骤302中得到的压测引擎的个数是不是小于或者等于3个。如果待调出流量的有压测引擎A和C，一共两个，小于或者等于3个，则进入步骤306。如果不小于，则结束流程。

步骤306：调度平台将正常压测引擎按照CPU负载从小到大的顺序进行排序。

如果小于预先设置的调度次数，则调度平台先将正常压测引擎B、正常压测引擎D、正常压测引擎E和正常压测引擎F分别按照CPU负载进行排序得到：正常压测引擎F、正常压测引擎D、正常压测引擎E和正常压测引擎B。则可以得到CPU负载最小的两个正常压测引擎为压测引擎F和压测引擎D。

步骤307：调度平台将待调出流量的异常压测引擎的流量调整预设流量比例(即30％)至排序后的正常压测引擎。

则调度平台分别将压测引擎A的流量调整30％至压测引擎F，并将压测引擎C的流量调整30％至压测引擎D；或者，调度平台分别将压测引擎A的流量调整30％至压测引擎D，并将压测引擎C的流量调整30％至压测引擎F。

步骤308：调度平台等待预设调度时间判断是否调度成功，如果不成功，则进入步骤309，如果成功，则结束流程。

在实际应用中，可以预先设置一个预设调度时间5m，则调度平台可以等待5s，并监控压测引擎A和C的流量是否成功调整至压测引擎F和D，如果成功则结束本次流量调度流程。

步骤309：向调度不成功的压测引擎发送失败命令。

如果在步骤309中判断得到压测引擎A和F不成功，或者压测引擎A和C不成功，或者，压测引擎A不成功，或者压测引擎D不成功，等等，则可以向调整不成功的压测引擎发送kill命令，不再让调度不成功的压测引擎继续执行压测方案。

进一步的，因为调度不成功的压测引擎可能出现了异常情况，例如断电断网等，所以调度平台可以统计调度成功的压测引擎有哪些，并对各个调度成功的压测引擎的流量进行重新分配，即重新确定压测方案。其中，确定压测方案并进行流量分配的过程在图2和图3中已经详细介绍，在此不再赘述。

可以理解的是，本例子中，为了绘图方便，判断步骤均按照顺序描述，而本领域技术人员可以确定，其中各个判断步骤均不需要限定先后顺序，各个判断步骤的顺序任意调整也可以实现本申请实施例。

对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

与上述本申请一种流量调度方法实施例所提供的方法相对应，参见图4，本申请还提供了一种流量调度平台实施例，在本实施例中，该调度平台与多个压测引擎相连，该调度平台可以包括：

获取单元401，用于在所述压测引擎执行该压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息。

第一判断单元402，用于根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度。

调度单元403，用于在所述判断单元的结果为是的情况下，将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎。

其中，所述流量调度参数可以包括：所述压测引擎的每秒查询率、CPU利用率和/或平均响应时间，所述第一判断单元402可以包括：

第一判断子单元，用于判断所述压测引擎的实际每秒查询率是否与预先设置的目标每秒查询率匹配；第二判断子单元，用于判断所述CPU利用率是否表示所述压测引擎的健康状态较差；和/或，第三判断子单元，用于判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢。

其中，所述第一判断子单元具体用于：判断所述压测引擎的目标每秒查询率与实际每秒查询率的差值是否大于预设查询差值。所述第二判断子单元具体用于：判断所述压测引擎的CPU利用率是否大于预设利用阈值。所述第三判断子单元具体用于：判断所述压测引擎的平均响应时间是否大于预设响应阈值。

其中，所述第一判断单元402还可以包括：

第四判断子单元，用于判断待调出流量的异常压测引擎的个数是否小于所述多个压测引擎的总个数的一半。

其中，该调度平台还可以包括：

第二判断单元400，用于判断所述压测方案的连续调度次数是否小于预设次数阈值，如果是，则触发所述获取单元401。其中，该调度平台还可以包括：

第三判断单元404，用于判断所述压测引擎的目标每秒查询率是否产生了变化；和，触发单元，用于在所述第三判断单元404的结果为否的情况下，触发所述第一判断单元401。

所述获取单元具体用于：在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息。

其中，所述调度单元403可以包括：

排序子单元，用于将所述正常压测引擎按照CPU负载从小到大的顺序进行排序；和，调整子单元，用于按照一一对应的方式，依次将待调出流量的异常压测引擎的流量调整预设流量比例至排序后的正常压测引擎。

可见，在一个压测方案的压测过程中，通过对执行该压测方案的各个压测引擎上流量调度参数的监控，获得各个压测引擎上的流量调度参数，例如CPU利用率，实际QPS请求，目标QPS请求，CPU负载等，并根据实时监控的流量调度参数判断各个压测引擎是否需要调度，在满足流量调度条件的情况下，再对待调出流量的异常压测引擎和调入流量的正常压测引擎实施预设调度方案，从而在压测过程中自动调度流量，将无法达到压测方案需求的异常压测引擎上的流量分配到其他的正常压测引擎上，以保证压测过程的顺利执行，并通过压测方案的执行真实模拟实际应用中海量用户请求增多的应用场景，从而减少实际中业务服务器可能存在的崩溃风险，也能提升用户体验。

本申请还提供了一种调度系统，该调度系统包括调度平台和与所述调度平台相连的多个压测引擎，所述多个压测引擎执行同一个压测方案，所述调度平台可以参考图4所示，调度平台可以包括：

获取单元，用于在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；判断单元，用于根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度；调度单元，用于在所述判断单元的结果为是的情况下，将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎。

该压测引擎，用于向所述调度平台提供相关的流量调度参数。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的压测过程中的流量调度方法、调度平台和调度系统进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (13)

1.一种压测过程中的流量调度方法，其特征在于，该方法应用于与多个压测引擎相连的调度平台上，所述多个压测引擎执行同一个压测方案；该方法包括：

在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；

根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，如果是，则将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎上。

2.根据权利要求1所述的方法，其特征在于，所述流量调度参数包括：所述压测引擎的每秒查询率、CPU利用率和/或平均响应时间，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，包括：

判断所述压测引擎的实际每秒查询率是否与预先设置的目标每秒查询率匹配；

判断所述CPU利用率是否表示所述压测引擎的健康状态较差；和/或，

判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢。

3.根据权利要求2所述的方法，其特征在于，所述判断所述压测引擎的实际每秒查询率是否与目标每秒查询率匹配，包括：

判断所述压测引擎的目标每秒查询率与实际每秒查询率的差值是否大于预设查询差值。

4.根据权利要求2所述的方法，其特征在于，所述判断所述CPU利用率是否表示所述压测引擎的健康状态较差，包括：

判断所述压测引擎的CPU利用率是否大于预设利用阈值。

5.根据权利要求2所述的方法，其特征在于，所述判断所述压测引擎的平均响应时间是否表示所述压测引擎的响应速度较慢，包括：

判断所述压测引擎的平均响应时间是否大于预设响应阈值。

6.根据权利要求2所述的方法，其特征在于，所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度，还包括：

判断待调出流量的压测引擎的个数是否小于所述多个压测引擎的总个数的一半。

7.根据权利要求1所述的方法，其特征在于，所述获取所述多个压测引擎相关的流量调度参数之前，还包括：

判断所述压测方案的连续调度次数是否小于预设次数阈值，如果是，则执行所述获取所述多个压测引擎相关的流量调度参数的步骤。

8.根据权利要求1所述的方法，其特征在于，所述根据所述压测引擎的性能判断所述多个压测引擎是否需要进行流量调度之前，还包括：

判断所述压测引擎的目标每秒查询率是否产生了变化，如果否，则执行所述根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进流量调度的步骤。

9.根据权利要求1所述的方法，其特征在于，所述获取所述多个压测引擎相关的流量调度参数，具体为：获取一个预设周期内所述多个压测引擎相关的流量调度参数。

10.根据权利要求9所述的方法，其特征在于，在判断得到所述多个压测引擎需要进行流量调度之后，还包括：

在下一个预设周期内，继续根据实时采集的压测引擎的流量调度参数，判断所述多个压测引擎是否需要进行流量调度，如果是，则执行将待调出流量的异常压测引擎上的流量，按照预设调度方案调整至正常压测引擎的步骤。

11.根据权利要求1所述的方法，其特征在于，所述将待调出流量的压测引擎上的流量按照预设调度方案调整至正常压测引擎上，包括：

将正常压测引擎按照CPU负载从小到大的顺序进行排序；

按照一一对应的方式，依次将待调出流量的异常压测引擎的流量，调整预设流量比例至排序后的正常压测引擎。

12.一种调度平台，其特征在于，该调度平台与多个压测引擎相连，所述多个压测引擎执行同一个压测方案；该调度平台包括：

获取单元，用于在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；

第一判断单元，用于根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度；

调度单元，用于在所述判断单元的结果为是的情况下，将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎。

13.一种流量调度系统，其特征在于，该系统包括：调度平台和与所述调度平台相连的多个压测引擎，所述多个压测引擎执行同一个压测方案；所述调度平台包括：

获取单元，用于在所述多个压测引擎执行所述压测方案的过程中，获取所述多个压测引擎相关的流量调度参数；所述流量调度参数用于表示所述压测引擎的性能和流量信息；判断单元，用于根据所述压测引擎的流量调度参数判断所述多个压测引擎是否需要进行流量调度；调度单元，用于在所述判断单元的结果为是的情况下，将待调出流量的异常压测引擎上的流量按照预设调度方案调整至正常压测引擎；

所述压测引擎，用于向所述调度平台提供相关的流量调度参数。