一种流量控制方法和装置与流程

本申请属于计算机网络技术领域，尤其涉及一种流量控制方法和装置。

背景技术：

流量控制是一种利用软件或硬件方式来实现对电脑网络流量的控制的一种控制方式，流量控制可以有效的防止由于网络中瞬间的大量数据对网络带来的冲击，从而可以保证用户网络高效而稳定的运行。

目前，流量控制技术主要有两种：

1)传统的流控方式：通过路由器、交换机的qos(qualityofservice，服务质量)模块实现基于源地址、目的地址、源端口、目的端口以及协议类型的流量控制，可以称为四层流控；

2)智能流控方式：这种流控方式是在应用层进行流控，属于七层流控。

针对上述的七层流控方式可以在应用层感知，目前所采用的方式主要是进行流量阈值的监控和对流量的拦截，对超出流控阈值的流量进行拦截就认为流量控制完成。

然而，系统的结构和情况是极为复杂的，如果仅采用预设一个固定的流控阈值进行流量控制，即，随后所有的流量控制都以该固定的流控阈值作为门限值，对于不超出该流控阈值的流量不进行拦截，对于超出该流控阈值的所有流量都进行拦截。这种控制方式显然比较死板，无法根据系统的实际情况和需要对系统进行较为全面和合理的保护。

针对上述问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请目的在于提供一种流量控制方法和装置，可以实现动态流控的技术效果。

本申请提供一种流量控制方法和装置是这样实现的：

一种流量控制方法，所述方法包括：

在确定需要进行流量控制时，服务器端获取当前业务请求的平均响应时间；

所述服务器端根据所述平均响应时间对流控阈值进行降级处理；

所述服务器端采用降级处理后的流控阈值进行流量控制。

一种流量控制装置，位于服务器端，所述装置包括：

获取模块，用于在确定需要进行流量控制的情况下，获取当前业务请求的平均响应时间；

降级模块，用于根据所述平均响应时间对流控阈值进行降级处理；

流控模块，用于采用降级处理后的流控阈值进行流量控制。

本申请提供的流量控制方法和装置，在确定需要对系统进行流量控制的情况下，服务器端根据当前业务请求的平均响应时间确定是否需要对预设的流控阈值进行降级处理，即，流控阈值是一个动态变化的数值，而不是从始至终都采用一个固定的数值的方式。例如，如果平均响应时间过长那么就表明当前业务的处理速度太慢，用户等待时间太长，这时候就可以降低流控阈值，以便同时更多的业务被处理，以提高业务请求的处理速度，减少卡顿的感觉，这是现有的采用固定流控阈值所达不到的效果，通过上述方式有效解决了现有技术采用固定流控阈值进行流量控制而导致的系统流控效果不好，无法自动适应系统负载状态变化的技术问题，达到了动态流控的技术效果。

附图说明

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

图1是本申请提供的流量控制方法一种实施例的方法流程图；

图2是本申请提供的流量控制方法时序交互示意图；

图3是本申请提供的流量控制系统架构图；

图4是本申请提供的流量控制装置一种实施例的模型结构示意图；

图5是本申请提供的流量控制装置另一种实施例的模型结构示意图。

具体实施方式

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

下面结合附图对本申请所述的流量控制方法和装置进行详细的说明。图1是本申请提出的流量控制方法的一种实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示 的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块结构。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例提供的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

具体的如图1所示，本申请提供的流量控制方法的一种实施例可以包括：

s1：在确定需要进行流量控制时，服务器端获取当前业务请求的平均响应时间对流控阈值进行降级处理；

所有计算机网络中承载有对业务请求进行处理的结构都可以认为是一个系统，一旦有业务请求，那么也就会存在流量控制的问题，因为如果业务集中进行请求，服务器端的承载能力是有一个上限值的，因此，如果希望对所有的业务请求都进行处理，并且在可以接受的响应时间内处理，就必须要对系统入口流量进行限制，要不容易出现超负荷，或者是有些线程排队太久，都会影响系统性能，也会影响用户体验。

因此，在系统对业务进行处理的过程中，就需要进行一个是否进行流量控制的判断，以便在必要的时候触发服务器端进行流量控制，在本例中，该系统可以是查询系统、数据计算系统、数据处理系统、数据转发系统等等，这里的系统是一个广义的概念，相应的，服务器端就是查询系统、数据计算系统、数据处理系统、数据转发系统的服务器。

具体地，在实现的时候，服务器端可以通过获取系统入口的活动线程数确定是否需要进行流量控制，其中，系统入口可以理解为系统的输入端口，例如某个应用输入至该系统的接口，通过这个入口业务请求可以被送至系统中进行处理。

线程是进程中执行运算的最小单位，也是执行处理机调度的基本单位。如果将进程理解为在逻辑上操作系统所完成的任务，那么线程表示完成该任务的许多可能的子任务之一。例如，假设用户启动了一个窗口中的数据库应用程序，操作系统就将对数据库的调用表示为一个进程。假设用户要从数据库中产生一份工资单报表，并传到一个文件中，这是一个子任务；在产生工资单报表的过程中，用户又可以输人数据库查询请求，这又是一个子任务。这样，操作系统则把每一个请求：工资单报表和新输人的数据查询表示为数据库进程中的独立的线程。线程可以在处理器上独立调度执行。所谓活动线程可以理解为还在跑的未被挂起的线程，也就是已启动并且尚未正常终止或中止的线程。

因此入口活动线程数表明的是系统当前的负荷，基于入口活动线程数可以确定是否需要对系统进行流量控制。具体地，在确定是否进行流量控制的情况下，服务器端可以按照以下 方式判断：获取当前预定时长内系统入口线程池的活动线程数和之前所述预定时长内系统入口的活动线程数；在当前预定时长内系统入口的活动线程数大于之前所述预定时长内系统入口的活动线程数预设倍数的情况下，确定需要进行流量控制。

举例而言，如果预设时长为5分钟，预设倍数为1.5倍，检测到当前五分钟内的活动线程数为80，前五分钟内的活动线程数为40(或者是前五分钟的平均线程数为每分钟8个)，那就表明当前时间周期的活动线程数相较于前一个周期的活动线程数达到设定的预设倍数，这个时候服务器端就需要启动动态流量控制了。

在上述实施例中是以当前周期的活动线程总数与上一周期的活动线程总数进行的比较，在实际实现的时候，还可以预设一个活动线程数阈值，如果当前周期的活动线程总数大于该活动线程数阈值，则认为需要启动动态流量控制。在实际执行的时候，具体采用何种方式确定是否进行动态流量控制，本申请不作具体限定，还可以采用当前周期的活动线程数的平均值与前一周期的活动线程数的平均值进行比较，具体的比较方式可以实际需要和实际设定选取。

s2：服务器端根据所述平均响应时间对流控阈值进行降级处理；

考虑到现有的流控方式是在设定流控阈值后，这个流控阈值就不再改变，在流控过程中就一直按照这个流控阈值进行拦截。然而，由于网络处理速度等问题的影响，如果一直按照这个固定的流控阈值进行处理，可能会存在不可避免的拥堵，从而使得业务请求的响应时间变得越来越久。为了避免这种问题的发生，服务器端可以根据当前业务请求的平均响应时间对流控阈值进行降级处理，具体的，可以包括：确定当前业务请求的平均响应时间是否超出预设时间阈值；如果超出，则对流控阈值进行降级处理，从而保证业务的等待时间不至于过长。

即，设定一个可以接受的响应时间，如果检测到当前时间周期的业务请求的平均响应时间高出预设可接受时间(也就是高出预设时间阈值)，那么就认为当前所设定的流控阈值是不合理的，需要对当前的流控阈值进行降级处理，这样才能使得业务请求的响应时间变短。

在降级处理的时候，可以是按照预设的降级比例对所述流控阈值进行降级处理，例如：x％，x％可以是10％、20％等等，具体的取值可以按照实际的系统需求和系统负载能力选择，本申请对此不作限定。

s3：服务器端采用降级处理后的流控阈值进行流量控制。

这种降级操作的处理也不是可以一步到位的操作，也可能在进行第一次降级之后，下一个时间周期平均响应时间仍旧是超出预设可接受时间的，这个时候可以再次进行降级处理，在后续的降级处理中并非需要完全按照和第一次降级处理相同的降级比例，这个比例可以与 第一次相同，也可以比第一次低一些，例如第一次降级比例是10％，这次可以是5％，从而使得整个降级过程较为平稳。即，按照预设的时间周期进行处理，直至响应时间可以满足要求。即，在采用降级处理后的流控阈值进行流量控制之后，服务器端可以获取从采用降级处理后的流控阈值进行流量控制之后的预设时长内的业务请求的平均响应时间；在从采用降级处理后的流控阈值进行流量控制之后的预设时长内的业务请求的平均响应时间超出所述预设时间阈值情况下，再次对流控阈值进行降级处理，直至从采用降级处理后的流控阈值进行流量控制之后的预设时长内的业务请求的平均响应时间小于预设时间阈值。

降级处理的目的是为了使得业务请求的响应时间可以恢复到预设可接受时间，等到业务请求的响应时间可以满足要求之后，就可以对流控阈值进行自动升级，直至恢复为流控预设值。当然，具体地自动升级过程也是需要保证响应时间是满足要求的，是一个在满足响应时间满足要求的前提下的流控阈值的升级过程。升级时候的升级比例可是很低的，即一步步慢慢升级，以防止需要回调。升级过程是在根据当前业务请求的平均响应时间对流控阈值进行降级处理之后进行的，可以包括：确定当前业务请求的平均响应时间是否小于或等于所述预设时间阈值；如果小于或等于，对流控阈值进行升级处理，直至流控阈值恢复至流控预设值。

当系统进入流控模式后，可以主动通知业务应用当前有流量控制，也可以是业务应用在获取到应用访问人员发起的业务请求后查询是否被流控，具体采用主动广播的方式还是被动查询的方式可以根据需要选择，本申请对此不作限定。如果是被动查询的方式，那么业务应用在响应于访问人员的业务请求进行查询后，根据流控查询结果对业务请求进行处理，如果未被流控，那么就对业务进行处理，并向访问人员返回请求处理结果，如果被流控，那么就向访问人员返回被流控。具体地，可以是在在根据当前业务请求的平均响应时间对流控阈值进行降级处理之后：检测是否有业务请求接入，在检测到有业务请求接入的情况下，服务器端向业务请求的业务应用返回当前有流量控制的通知消息，并控制业务应用的流量进行降级处理。

即，在通知业务应用当前有流控的时候，还可以为被流控的业务应用设置自动降级比例，这个自动降级比例可以和系统自身的降级比例是相同的，也可以是略大于自身降级比例的，可以按照实际需要选择。进一步的，如果被控对象在下一个周期仍旧是被流控的，那么就继续自动降级，直至不再被流控后，再自动升级，直至恢复为流控预设值。

下面结合一个具体实施例对上述流量控制方法进行说明，然而值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

在本申请实施例中主要是为了解决现有技术中的流量控制仅限于对超出阀值的流量拦截即认为流控完成，在本例中会结合系统的一些度量数据提供流控阈值的自动升降级，以实 现对系统更好的保护。

为了实现上述目的，本申请的流控系统可以如图2所示，包括：数据采集、度量数据管理、动态流控策略管理和动态流控管理这几个模块，其中，数据采集模块可以负责系统的度量数据采集，采集后在度量数据管理模块进行数据聚合，数据聚合后结合动态流控策略模块提供的策略在动态流控管理模块完成流控阀值的动态升降级功能。

(1)动态流控策略

可由管理员通过动态流控策略管理模块完成动态流控策略的配置，其中，动态流控策略可以包括以下几个部分：

1)基于活动线程个数的策略：

当前n分钟活动线程数超出之前n分钟平均值m倍的时候启动动态流控模式，即，通过活动线程数确定是否启动动态流控。

2)基于每个业务请求的处理响应时间的策略：

对于特定的api(applicationprogramminginterface，应用程序编程接口)当前n分钟的平均响应时间超出策略预设值时，可以对该特定的api的流控阀值进行自动降级，降级比例可以设置为x％，如果下一n分钟持续超出上述策略预设值，那么就在当前流控阀值的基础上持续自动降级x％，当响应时间恢复时，流控阀值将自动升级，直到恢复为流控预设值。

3)基于历史流控数据的策略：

当系统通知业务应用有流控产生时，可以对被流控的对象设置进行自动降级，自动降级比例也可以是x％，如果被流控对象下一周期持续被流控，那么就持续自动降级，等到被流控对象不被流控时，自动升级，直到恢复为流控预设值。

(2)数据采集

负责系统负载状况的数据采集，在本申请实施例中，采集的数据可以有：

1)系统入口线程池活动线程个数；

2)系统每个api对请求处理的响应时间。

3)对被流控的历史数据。

(3)度量数据推送到度量数据管理模块

度量数据管理模块负责对采集的数据进行聚合处理。

(4)聚合的度量数据推送到动态流控管理模块

动态流控管理模块根据聚合的度量数据进行分析，并结合动态流控策略和当前的动态流控实际情况生成附加流控策略应用到当前系统的流控配置中。

(5)应用访问人员发起请求

业务应用调用动态流控管理模块检查是否被流控，如果被流控，则动态流控管理模块将记录流控数据，并向业务应用返回请求被流控的通知消息，如果未被流控，则业务应用将进行业务处理并向应用访问人员返回请求处理结果。

在上述实施例中，通过对系统负载状态进行动态感知，并自动进行流控升降级处理，可以解决现有的流控技术不能自动的适应系统负载状态变化的问题，在系统出现问题时，可以自动地对流控进行自动升级或降级，达到了动态流控的技术效果。

举例而言，流控系统可以如图3所示，包括：服务器端和请求业务的用户端，服务器端响应于用户端的业务请求对请求进行处理。如图3所示，服务器端是连接有多个用户端的，用户端的种类和类型也是不同的，这些用户端都可能向服务器发起业务请求，当多个用户端同时发起业务请求时，难免会导致服务器端负荷过大，为此，服务器端在对业务请求进行处理的时候，就可以按照上述流控方式对业务请求进行动态流控。

上服务器端中的流量控制装置可以如图4所示，包括：获取模块401、降级模块402和流控模块403，即，服务器端通过该流量控制装置对来自用户端的业务请求进行处理和动态流控，下面对该结构进行说明。

获取模块401，可以用于在确定需要进行流量控制的情况下，获取当前业务请求的平均响应时间；

降级模块402，可以用于根据所述平均响应时间对流控阈值进行降级处理；

流控模块403，可以用于采用降级处理后的流控阈值进行流量控制。

在一个实施方式中，如图5所示，上述流量控制装置还可以包括：确定模块501，具体可以用于根据系统入口的活动线程数确定是否需要进行流量控制。

在一个实施方式中，如图5所示，确定模块501可以包括：获取单元5011，用于具体用于获取当前预定时长内系统入口的活动线程数和之前所述预定时长内系统入口的活动线程数；第一确定单元5012，用于在当前预定时长内系统入口线程池的活动线程数大于之前所述预定时长内系统入口的活动线程数预设倍数的情况下，确定需要进行流量控制。

在一个实施方式中，如图5所示，降级模块402可以包括：第二确定单元4021，用于确定当前业务请求的平均响应时间是否超出预设时间阈值；处理单元4022，用于在确定出当前业务请求的平均响应时间超出预设时间阈值的情况下，对流控阈值进行降级处理。

在一个实施方式中，处理单元具体可以用于按照预设的降级比例对所述流控阈值进行降级处理。

在一个实施方式中，上述流量控制装置还可以包括：获取模块，用于获取从采用降级处理后的流控阈值进行流量控制之后的预设时长内的业务请求的平均响应时间；调整模块，用 于在从采用降级处理后的流控阈值进行流量控制之后的预设时长内的业务请求的平均响应时间超出所述预设时间阈值情况下，再次对流控阈值进行降级处理，直至从采用降级处理后的流控阈值进行流量控制之后的预设时长内的业务请求的平均响应时间小于所述预设时间阈值。

在一个实施方式中，上述流量控制装置还可以包括：确认模块，用于在采用降级处理后的流控阈值进行流量控制之后，确定当前业务请求的平均响应时间是否小于或等于所述预设时间阈值；升级模块，用于在确定当前业务请求的平均响应时间小于或等于所述预设时间阈值的情况下，对流控阈值进行升级处理，直至流控阈值恢复至流控预设值。

在一个实施方式中，上述流量控制装置还可以包括：检测模块，用于在采用降级处理后的流控阈值进行流量控制之后，检测是否有业务请求接入；返回模块，用于在检测到有业务请求接入的情况下，向所述业务请求的业务应用返回当前有流量控制的通知消息；控制模块，用于控制所述业务应用的流量进行降级处理。

由于流量控制装置解决问题的原理与流量控制方法相似，因此流量控制装置的实施可以参见流量控制方法的实施，重复之处不再赘述。以上所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本申请提供的流量控制方法及装置，在确定需要对系统进行流量控制的情况下，服务器端根据当前业务请求的平均响应时间确定是否需要对预设的流控阈值进行降级处理，即，流控阈值是一个动态变化的数值，而不是从始至终都采用一个固定的数值的方式。例如，如果平均响应时间过长那么就表明当前业务的处理速度太慢，用户等待时间太长，这时候就可以降低流控阈值，以便同时更多的业务被处理，以提高业务请求的处理速度，减少卡顿的感觉，这是现有的采用固定流控阈值所达不到的效果，通过上述方式有效解决了现有技术采用固定流控阈值进行流量控制而导致的系统流控效果不好，无法自动适应系统负载状态变化的技术问题，达到了动态流控的技术效果。

本申请中各个实施例所涉及的上述描述仅是本申请中的一些实施例中的应用，在某些标准、模型、方法的基础上略加修改后的实施方式也可以实行上述本申请各实施例的方案。当然，在符合本申请上述各实施例的中所述的处理方法步骤的其他无创造性的变形，仍然可以实现相同的申请，在此不再赘述。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实 施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然，也可以将实现某功能的模块由多个子模块或子单元组合实现。

本申请中所述的方法、装置或模块可以以计算机可读程序代码方式实现控制器按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请所述装置中的部分模块可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的硬件的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，也可以通过数据迁移的实施过程中体现出来。该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持 设备或便携式设备、平板型设备、移动通信终端、多处理器系统、基于微处理器的系统、可编程的电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。