具体实施方式

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

首先，对本申请涉及的部分技术术语进行解释说明：

k8s，即容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩容或缩容、维护等功能。

应用(pod)实例，简称为pod，即k8s创建或部署的最小或最简单的基本单位，一个pod代表k8s集群上正在运行的一个进程，每个进程包含网际互连协议(InternetProtocol，IP)地址信息。

负载均衡器(Haproxy)，即一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于传输控制协议(Transmission Control Protocol，TCP)和超文本传输协议(Hyper Text Transfer Protocol，HTTP)的应用程序代理。

流量大小(flow_size)，用于表示pod的总流量大小。

流量比例(flow_ratio)，用于表示进入pod的流量比例，默认取值为100％，若0<flow_ratio<100％，则表示限速流量，若flow_ratio为0，则表示关闭流量状态，即不接收流量。

慢启动时间(slow_start_time)，用于表示慢启动倒计时(单位为秒)。

流量恢复策略(flow_recovery_policy)，用于表示慢启动倒计时恢复到0时(0表示慢启动时间已经结束，确定是否需要恢复控制pod的流量到100％，即为正常的流量节点)，flow_ratio的参数调整方式，flow_recovery_policy取值为0表示手动调整flow_ratio，flow_recovery_policy取值为1表示自动调整flow_ratio(即将flow_ratio自动恢复到100％)。

慢启动状态(slow_start_status)，用于表示是否开启慢启动，0表示开启，1表示关闭(默认关闭)；在慢启动关闭状态下，参数slow_start_time和参数flow_recovery_policy不生效。

在多实例和多应用的业务服务环境中，负载均衡器作为统一业务服务的入口，在物理架构环境或者容器架构环境中都是必不可少的组件之一。使用比较广泛的负载均衡器比如有Haproxy、Nginx。

目前，在k8s环境中，通常根据业务服务器的权重值分配转发的次数比例，从而实现负载均衡。但是，上述实现负载均衡的方式中业务服务器的权重值是预先配置好的，即分配给每个业务服务器的请求次数比例是固定的，不能够根据业务请求对应的流量大小进行自动调整，因此，不能够实现负载均衡。示例性地，Nginx中配置了业务服务器1和业务服务器2的权重值均为5，Nginx会以轮询地方式将业务请求转发给业务服务器1和业务服务器2，但是每个业务请求的流量是不相同的，导致业务服务器1和业务服务器2处理的业务请求的流量不相同，而负载均衡的核心目的是实现流量的负载均衡，因此，上述方式不能够准确地实现业务服务器的负载均衡。且，在k8s环境中，在应用慢启动的流量预热时，不能够在不同时间段控制不同的流量比例到指定的业务服务器。示例性地，在Nginx轮询算法中，提供了慢启动(slow_start)参数用于应用慢启动的流量预热，slow_start参数对应的Nginx实现模块用ngx_http_upstream_module表示，slow_start参数对应的具体Nginx配置方法为：

其中，slow_start＝30s表示权重(weight)在30s内从0恢复到5。

上述slow_start参数对应的具体Nginx配置方法，是基于权重(weight)进行应用慢启动的流量预热，因此，不能够在不同时间段控制不同的流量比例到指定的业务服务器。

基于上述问题，本申请提供一种流量控制方法、装置、设备及存储介质，根据多个业务服务器对应的已发送业务请求流量实现业务服务器的负载均衡，因此，能够更加准确地实现业务服务器的负载均衡。

以下，首先对本申请提供的方案的应用场景进行示例说明。

图1为本申请一实施例提供的应用场景示意图。如图1所示，本应用场景中，客户端110发送一个业务请求到负载均衡设备120，负载均衡设备120从多个业务服务器130中确定目标业务服务器，将该业务请求发送给目标业务服务器。负载均衡设备120从多个业务服务器130中确定目标业务服务器的具体实现过程可以参见下述各实施例的方案。

需要说明的是，图1仅是本申请实施例提供的一种应用场景的示意图，本申请实施例不对图1中包括的设备进行限定，也不对图1中设备之间的位置关系进行限定。

接下来，通过具体实施例介绍流量控制方法。下面各申请实施例中，以业务服务器为pod为例进行说明。

图2为本申请一实施例提供的流量控制方法的流程图，应用于业务系统，该业务系统包含负载均衡设备和多个业务服务器。如图2所示，本申请实施例的方法包括：

S201、负载均衡设备在接收到业务请求后，确定业务请求对应的目标流量。

本申请实施例中，示例性地，负载均衡设备可以为负载均衡器，该负载均衡器可以在独立的服务器中运行。业务请求可以是用户向执行本方法实施例的负载均衡设备输入的，或者，是其它设备向执行本方法实施例的负载均衡设备发送的。示例性地，业务请求为HTTP请求，则负载均衡设备在接收到HTTP请求后，可以根据HTTP协议对应的主体(body)数据大小确定业务请求对应的目标流量，目标流量比如为1M。

S202、负载均衡设备根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

其中，已发送业务请求流量为在预设时段内向业务服务器发送的业务请求对应的总流量。多个服务器为业务系统中所有的服务器；每个服务器有对应的已发送流量。

示例性地，业务服务器为pod，预设时段比如为pod开始运行至当前时间这一时段。负载均衡设备根据多个pod中，每个pod对应的已发送业务请求流量，可以确定对应的已发送业务请求流量最小的pod为目标pod。对于负载均衡设备如何确定对应的已发送业务请求流量最小的pod为目标pod，可参考后续实施例。示例性地，比如有三个pod，分别为pod1、pod2和pod3，负载均衡设备确定了pod1对应的已发送业务请求流量为10M、pod2对应的已发送业务请求流量为8M以及pod3对应的已发送业务请求流量为9M，则负载均衡设备可以确定pod2为目标pod。

S203、负载均衡设备向目标业务服务器发送业务请求。

该步骤中，负载均衡设备在确定目标业务服务器后，向目标业务服务器发送业务请求。可选的，负载均衡设备可以根据目标流量，更新目标业务服务器对应的已发送业务请求流量。示例性地，目标业务服务器为pod2，业务请求对应的目标流量为1M，则负载均衡设备向pod2发送业务请求，并根据目标流量1M，更新目标业务服务器对应的已发送业务请求流量。

负载均衡设备在执行完步骤S203之后，对于接收到的新的业务请求，重复执行S201至S203的步骤，从而实现基于流量的负载均衡。

本申请实施例提供的流量控制方法，通过负载均衡设备在接收到业务请求后，确定业务请求对应的目标流量，负载均衡设备在多个业务服务器中，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，负载均衡设备向目标业务服务器发送业务请求。由于本申请实施例的负载均衡设备根据每个业务服务器对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，向目标业务服务器发送业务请求，因此，能够准确地对业务服务器进行流量控制，进而更加准确地实现业务服务器的负载均衡。

在上述实施例的基础上，可选的，若业务服务器配置了流量控制规则，则负载均衡设备根据流量控制规则，确定对应的业务服务器的已发送业务请求流量。

示例性地，业务服务器为pod，每个pod分别对应一个配置文件，配置文件中配置的参数可以包括：flow_ratio、slow_start_time、flow_recovery_policy、slow_start_status。各pod分别对应的配置文件中的参数设置可以相同或者不同，即可以按需配置参数。可以理解，配置文件中的参数设置可以对应不同的流量控制规则。若pod中配置了流量控制规则，则负载均衡设备根据该流量控制规则，确定对应的pod的已发送业务请求流量。

进一步地，流量控制规则为慢启动业务服务器流量控制规则，若业务服务器配置了流量控制规则，则负载均衡设备根据流量控制规则，确定对应的业务服务器的已发送业务请求流量，可以包括：若业务服务器配置了慢启动业务服务器流量控制规则，则负载均衡设备根据慢启动业务服务器流量控制规则，控制业务服务器实现慢启动，并确定对应的业务服务器的已发送业务请求流量。

可选的，若业务服务器配置了慢启动业务服务器流量控制规则，且业务服务器的当前流量的大小表示限速流量，则确定业务服务器的已发送业务请求流量为当前流量；或者，若业务服务器配置了慢启动业务服务器流量控制规则，且流量比例的值表示限速流量，则确定业务服务器的已发送业务请求流量为未进行限速流量的业务服务器对应的已发送业务请求流量的总和，或确定业务服务器的已发送业务请求流量为所有业务服务器对应的已发送业务请求流量的总和。具体地，在流量比例的值为百分之一百的情况下，业务服务器的已发送业务请求流量为所有其他未进行限速流量的业务服务器对应的已发送业务请求流量的总和；在流量比例的值大于零且小于百分之一百时，业务服务器的已发送业务请求流量为所有业务服务器对应的已发送业务请求流量的总和。

示例性地，若pod对应的配置文件中配置了slow_start_status为0，则表示开启了应用慢启动的流量预热控制(即流量控制规则为慢启动业务服务器流量控制规则，表示限速流量)，可以根据该pod对应的配置文件中的参数设置，控制该pod实现慢启动，并确定该pod的已发送业务请求流量(即flow_size)。具体地，用flow_size_{0＜flow_ratio＜100}表示限速流量情况下，pod对应的flow_size的大小；用Sum_{flow_ratio＝100}表示限速流量情况下，其他未进行限速流量的pod对应的已发送业务请求流量的总和；用tmp_Sum_{0＜flow_ratio＜100}表示限速流量情况下，所有pod对应的已发送业务请求流量的总和。若pod对应的配置文件中的参数设置为：slow_start_status＝0，slow_start_time>0，flow_recovery_policy＝1，0<flow_ratio<100％，则可以通过以下三种方式确定pod的已发送业务请求流量flow_size_{0＜flow_ratio＜100}：

(1)若tmp_Sum_{0＜flow_ratio＜100}与flow_size_{0＜flow_ratio＜100}相等，则确定flow_size_{0＜flow_ratio＜100}的取值为pod当前的已发送业务请求流量，即保持不变；

(2)若则flow_size_{0＜flow_ratio＜100}和tmp_Sum_{0＜flow_ratio＜100}的取值均为当前所有pod的已发送业务请求流量中的最小值；

(3)若tmp_Sum_{0＜flow_ratio＜100}小于flow_size_{0＜flow_ratio＜100}，则flow_size_{0＜flow_ratio＜100}和tmp_Sum_{0＜flow_ratio＜100}的取值均为Sum_{flow_ratio＝100}。

当slow_start_time倒计时为0时，自动设置flow_ratio为100％，此时，pod对应的flow_size取值为当前所有pod的已发送业务请求流量中的最大值，并将slow_start_status设置为1，表示应用慢启动的流量预热控制结束。

若pod对应的配置文件中的参数设置为：slow_start_status＝0，slow_start_time＝0，flow_recovery_policy＝0，0<flow_ratio<100％，则可以通过以下三种方式确定pod的已发送业务请求流量flow_size_{0＜flow_ratio<100}：

(1)若tmp_Sum_{0<flow_ratio<100}与flow_size_{0<flow_ratio＜100}相等，则确定flow_size_{0<flow_ratio<100}的取值为pod当前的已发送业务请求流量，即保持不变；

(2)若则flow_size_{0<flow_ratio＜100}和tmp_Sum_{0＜flow_ratio＜100}的取值均为当前所有pod的已发送业务请求流量中的最小值；

(3)若tmp_Sum_{0＜flow_ratio＜100}小于flow_size_{0＜flow_ratio＜100}，则flow_size_{0＜flow_ratio＜100}和tmp_Sum_{0＜flow_ratio＜100}的取值均为Sum_{flow_ratio＝100}。

若pod对应的配置文件中的参数设置为：slow_start_status＝1(即关闭应用慢启动，此时slow_start_time和flow_recovery_policy均不生效)，0<flow_ratio<100％，则可以通过以下三种方式确定pod的已发送业务请求流量flow_size_{0＜flow_ratio＜100}：

(1)若tmp_Sum_{0＜flow_ratio＜100}与flow_size_{0＜flow_ratio＜100}相等，则确定flow_size_{0＜flow_ratio＜100}的取值为pod当前的已发送业务请求流量，即保持不变；

(2)若则flow_size_{0＜flow_ratio＜100}和tmp_Sum_{0＜flow_ratio＜100}的取值均为当前所有pod的已发送业务请求流量中的最小值；

(3)若tmp_Sum_{0＜flow_ratio＜100}小于flow_size_{0＜flow_ratio＜100}，则flow_size_{0＜flow_ratio＜100}和tmp_Sum_{0＜flow_ratio＜100}的取值均为Sum_{flow_ratio＝100}。

通过业务服务器对应的配置文件中的参数设置(即流量控制规则)，负载均衡设备可以确定对应的业务服务器的已发送业务请求流量，以用于负载均衡设备在多个业务服务器中，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。因此，能够在不同时间段控制不同的流量比例到指定的业务服务器，实现应用慢启动的流量预热控制。

图3为本申请另一实施例提供的流量控制方法的流程图。在上述实施例的基础上，本申请实施例对如何实现负载均衡进行进一步说明。如图3所示，本申请实施例的方法可以包括：

S301、负载均衡设备在接收到业务请求后，确定业务请求对应的目标流量。

该步骤的具体描述可以参见图2所示实施例中S201的相关描述，此处不再赘述。

本申请实施例中，图2中S202步骤可以进一步细化为如下的S302和S303两个步骤：

S302、若监听到业务系统发生预设状态变化事件，则负载均衡设备获取多个业务服务器分别对应的已发送业务请求流量，负载均衡设备根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

其中，预设状态变化事件至少包括创建业务服务器或重启业务服务器。示例性地，业务服务器为pod，在k8s环境中，负载均衡设备监听k8s编排文件的默认参数资源版本(resourceVersion)的值是否发生变化，若resourceVersion的值发生变化，表示可能创建了新的pod或重启了pod，则负载均衡设备获取多个pod分别对应的已发送业务请求流量。负载均衡设备在获取了多个业务服务器分别对应的已发送业务请求流量后，可以根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

进一步地，若监听到业务系统发生预设状态变化事件，则负载均衡设备获取多个业务服务器分别对应的已发送业务请求流量，可以包括：若监听到业务系统发生预设状态变化事件，则负载均衡设备将根据预设接口获得的业务服务器信息以及内存中运行的业务服务器信息进行比对；若为新增业务服务器，则负载均衡设备通过初始化预设参数，获取新增业务服务器对应的已发送业务请求流量；若为已经存在的业务服务器，则负载均衡设备将对应的内存中的运行参数导入至已经存在的业务服务器，获取已经存在的业务服务器对应的已发送业务请求流量。

可选的，预设参数包括流量比例，若为新增业务服务器，则负载均衡设备通过初始化预设参数，获取新增业务服务器对应的已发送业务请求流量，可以进一步包括：若新增业务服务器对应的流量比例的值为第一预设值，则新增业务服务器对应的已发送业务请求流量为所有业务服务器的已发送业务请求流量中的最大值；或者，若新增业务服务器对应的流量比例的值为第二预设值，则新增业务服务器对应的已发送业务请求流量为所有业务服务器对应的已发送业务请求流量的总和。具体地，第一预设值比如为100％；第二预设值比如为0至100％之间的数值，不包括0和100％，这时当前业务系统中只有对应该流量比例的业务服务器处于启动状态。

示例性地，业务服务器为pod，预设参数为pod对应的配置文件中配置的参数，具体地，预设参数可以包括：flow_ratio、slow_start_time、flow_recovery_policy、slow_start_status。预设接口比如为k8s提供的应用程序编程接口(Application ProgrammingInterface，API)。示例性地，负载均衡设备在监听到业务系统发生预设状态变化事件时，将根据预设接口获得的多个pod分别对应的IP信息以及内存中运行的多个pod分别对应的IP信息进行比对，若确定为新增pod，则负载均衡设备通过初始化预设参数，获取新增pod对应的已发送业务请求流量。具体地，可以通过以下两种方式确定新增pod对应的已发送业务请求流量：

(1)若新增pod对应的配置文件中的参数设置为：flow_ratio为100％，则flow_size为当前所有pod的已发送业务请求流量中的最大值；

(2)若新增pod对应的配置文件中的参数设置为：0<flow_ratio<100％，则flow_size_{0＜flow_ratio＜100}的初始值为Sum_{flow_ratio＝100}，并记录tmp_Sum_{0＜flow_ratio＜100}的初始值以及flow_size_{0＜flow_ratio＜100}的初始值至内存中。用Sum_All表示所有pod对应的已发送业务请求流量的总和，若Sum_All为0，则flow_size_{0＜flow_ratio＜100}的取值为0；若Sum_All大于0，则flow_size_{0＜flow_ratio＜100}的取值为Sum_{flow_ratio＝100}。

若确定为已经存在的pod，则负载均衡设备将对应的内存中的运行参数值(即flow_size)复制给已经存在的pod，获取已经存在的pod对应的已发送业务请求流量，以维持已经存在的pod的运行状态，保证流量计算的准确性。

可选的，若确定根据预设接口获得的业务服务器已未在内存中运行，则负载均衡设备删除已未在内存中运行的业务服务器对应的数据。

示例性地，若确定根据预设接口获得的pod已未在内存中运行，则根据已未在内存中运行的pod对应的IP，删除已未在内存中运行的pod在内存中的对应数据。

可选的，负载均衡设备根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，可以包括：若多个业务服务器分别对应的已发送业务请求流量均为第三预设值，则负载均衡设备确定从多个业务服务器中随机选择的一个业务服务器为目标业务服务器；或者，若多个业务服务器分别对应的已发送业务请求流量不全为第三预设值，则负载均衡设备确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

示例性地，第三预设值比如为0。若负载均衡设备获取的所有pod分别对应的已发送业务请求流量均为0，则确定从所有pod中随机选择的一个pod为目标pod。若负载均衡设备获取的所有pod分别对应的已发送业务请求流量不全为0，则负载均衡设备确定对应的已发送业务请求流量最小的pod为目标pod。可选的，若存在多个相同的已发送业务请求流量最小的pod，则随机选择一个为目标pod。

S303、若多个业务服务器中的一个业务服务器的已发送业务请求流量发生变化，则负载均衡设备获取多个业务服务器分别对应的已发送业务请求流量，负载均衡设备根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

示例性地，负载均衡设备在向一个pod发送业务请求后，会更新该pod对应的已发送业务请求流量，即该pod对应的已发送业务请求流量会发生变化，负载均衡设备根据该pod对应的已发送业务请求流量的变化，从内存中获取所有pod分别对应的已发送业务请求流量。负载均衡设备在获取了多个pod分别对应的已发送业务请求流量后，可以根据多个pod分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的pod为目标pod。

需要说明的是，本申请不对S302和S303执行的先后顺序做限制。

S304、负载均衡设备将目标业务服务器的标识存储至转发队列。

该步骤中，队列为一种数据结构，也是一种特殊的线性表，只允许在表的前端(front)进行删除操作，而在表的后端(rear)进行插入操作，队列比如为顺序队列或链表队列。转发队列是用于存储目标业务服务器的标识的队列。示例性地，负载均衡设备在确定目标pod后，将目标pod的IP存储至转发队列。

可选的，若业务服务器对应的flow_ratio值为第二预设值，第二预设值比如为0，则将该业务服务器的标识存储至返回队列(返回队列是用于存储flow_ratio值为第二预设值的业务服务器的标识的队列)，相应地，该业务服务器的已发送业务请求流量不会发生变化，即保持不变。

S305、负载均衡设备从转发队列中获取目标业务服务器的标识，并根据目标业务服务器的标识向目标业务服务器发送业务请求。

示例性地，负载均衡设备从转发队列中获取目标pod的IP，根据目标pod的IP向目标pod发送业务请求。

在步骤S305之后，负载均衡设备可以根据目标流量，更新目标业务服务器对应的已发送业务请求流量。进一步地，可选的，根据目标流量，更新目标业务服务器对应的已发送业务请求流量，可以包括：负载均衡设备将目标业务服务器对应的已发送业务请求流量更新为目标流量以及目标业务服务器在转发业务请求之前的已发送业务请求流量之和。

示例性地，目标流量为1M，目标pod在转发业务请求之前的已发送业务请求流量为9M，则负载均衡设备将目标pod对应的已发送业务请求流量更新为10M。

进一步地，可选的，若目标业务服务器对应的配置文件中的参数设置为：slow_start_status＝1(此时slow_start_time和flow_recovery_policy不生效)，flow_ratio＝100％，则负载均衡设备将目标业务服务器对应的已发送业务请求流量更新为目标流量以及目标业务服务器在转发业务请求之前的已发送业务请求流量之和。

负载均衡设备在执行完步骤S305之后，对于接收到的新的业务请求，重复执行S301至S305的步骤，从而实现基于流量的负载均衡。

本申请实施例提供的流量控制方法，通过负载均衡设备在接收到业务请求后，确定业务请求对应的目标流量，若监听到业务系统发生预设状态变化事件，或者，若多个业务服务器中的一个业务服务器的已发送业务请求流量发生变化，则负载均衡设备获取多个业务服务器分别对应的已发送业务请求流量，因此，能够保证及时准确地获取多个业务服务器分别对应的已发送业务请求流量；根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，负载均衡设备将目标业务服务器的标识存储至转发队列，负载均衡设备从转发队列中获取目标业务服务器的标识，并根据目标业务服务器的标识向目标业务服务器发送业务请求，能够保证将业务请求准确地发送给目标业务服务器。由于本申请实施例的负载均衡设备根据每个业务服务器对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，向目标业务服务器发送业务请求，因此，能够准确地对业务服务器进行流量控制，进而更加准确地实现业务服务器的负载均衡

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图4为本申请一实施例提供的流量控制装置的结构示意图，应用于业务系统，业务系统包含负载均衡设备和多个业务服务器。如图4所示，本申请实施例的流量控制装置400包括：第一确定模块401、第二确定模块402和处理模块403。其中：

第一确定模块401，用于在接收到业务请求后，确定业务请求对应的目标流量。

第二确定模块402，用于根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，已发送业务请求流量为在预设时段内向业务服务器发送的业务请求对应的总流量。

处理模块403，用于向目标业务服务器发送业务请求。

可选的，第二确定模块402可以具体用于：若监听到业务系统发生预设状态变化事件，则获取多个业务服务器分别对应的已发送业务请求流量，负载均衡设备根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器，预设状态变化事件至少包括创建业务服务器或重启业务服务器；或者，若多个业务服务器中的一个业务服务器的已发送业务请求流量发生变化，则获取多个业务服务器分别对应的已发送业务请求流量，负载均衡设备根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

可选的，第二确定模块402在用于若监听到业务系统发生预设状态变化事件，则获取多个业务服务器分别对应的已发送业务请求流量时，可以具体用于：若监听到业务系统发生预设状态变化事件，则将根据预设接口获得的业务服务器信息以及内存中运行的业务服务器信息进行比对；若为新增业务服务器，则通过初始化预设参数，获取新增业务服务器对应的已发送业务请求流量；若为已经存在的业务服务器，则将对应的内存中的运行参数导入至已经存在的业务服务器，获取已经存在的业务服务器对应的已发送业务请求流量。

可选的，预设参数包括流量比例，第二确定模块402在用于若为新增业务服务器，则通过初始化预设参数，获取新增业务服务器对应的已发送业务请求流量时，可以具体用于：若新增业务服务器对应的流量比例的值为第一预设值，则新增业务服务器对应的已发送业务请求流量为所有业务服务器的已发送业务请求流量中的最大值；或者，若新增业务服务器对应的流量比例的值为第二预设值，则新增业务服务器对应的已发送业务请求流量为所有业务服务器对应的已发送业务请求流量的总和。

在一些实施例中，第二确定模块402在用于根据多个业务服务器分别对应的已发送业务请求流量，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器时，可以具体用于：若多个业务服务器分别对应的已发送业务请求流量均为第三预设值，则确定从多个业务服务器中随机选择的一个业务服务器为目标业务服务器；或者，若多个业务服务器分别对应的已发送业务请求流量不全为第三预设值，则确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器。

可选的，第二确定模块402在多个业务服务器中，确定对应的已发送业务请求流量最小的业务服务器为目标业务服务器之后，还可以用于：将目标业务服务器的标识存储至转发队列；处理模块403可以具体用于：从转发队列中获取目标业务服务器的标识，并根据目标业务服务器的标识向目标业务服务器发送业务请求。

可选的，第二确定模块402还可以用于：若业务服务器配置了流量控制规则，则根据流量控制规则，确定对应的业务服务器的已发送业务请求流量。

可选的，流量控制规则为慢启动业务服务器流量控制规则，第二确定模块402在用于若业务服务器配置了流量控制规则，则根据流量控制规则，确定对应的业务服务器的已发送业务请求流量时，可以具体用于：若业务服务器配置了慢启动业务服务器流量控制规则，则根据慢启动业务服务器流量控制规则，控制业务服务器实现慢启动，并确定对应的业务服务器的已发送业务请求流量。

可选的，第二确定模块402还用于：若业务服务器配置了慢启动业务服务器流量控制规则，且业务服务器的当前流量的大小表示限速流量，则确定业务服务器的已发送业务请求流量为当前流量；或者，若业务服务器配置了慢启动业务服务器流量控制规则，且流量比例的值表示限速流量，则确定业务服务器的已发送业务请求流量为未进行限速流量的业务服务器对应的已发送业务请求流量的总和，或确定业务服务器的已发送业务请求流量为所有业务服务器对应的已发送业务请求流量的总和。

本实施例的装置，可以用于执行上述任一所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图5为本申请另一实施例提供的流量控制装置的结构示意图。如图5所示，本申请实施例的流量控制装置500可以包括：计算模块501、调度模块502和转发模块503。其中：

计算模块501，用于获取内存中运行的最新pod并确定每个pod对应的已发送业务请求流量；若为新增pod，则对新增pod的参数进行初始化，若为已经存在的pod，则将运行参数导入至已经存在的pod，若pod已不存在，则删除计算模块501中已不存在pod对应的信息，并删除转发队列以及返回队列中已不存在pod对应的数据，将确定的最新pod以及每个pod对应的已发送业务请求流量数据导入至调度模块502。

调度模块502，用于根据每个pod对应的已发送业务请求流量，确定存储至转发队列的目标pod；若pod对应的flow_ratio值为0，则将该pod存储至返回队列，并将该pod对应的已发送业务请求流量直接返回给计算模块501。

转发模块503，用于从转发队列中获取可以转发的目标pod，向目标pod发送业务请求；根据业务请求，确定业务请求对应的目标流量，并将该目标流量发送给计算模块501，用于更新目标pod对应的已发送业务请求流量。

可以理解，本申请实施例中的计算模块和调度模块的功能与上述实施例中的第二确定模块的功能类似；本申请实施例中的转发模块的功能与上述实施例中的第一确定模块和处理模块的功能类似。

基于图5所示的流量控制装置，图6为本申请一实施例提供的流量控制系统的示意图。如图6所示，流量控制系统600中，计算模块501获取内存中运行的最新pod601并确定每个pod601对应的已发送业务请求流量；若为新增pod601，则对新增pod601的参数进行初始化，若为已经存在的pod601，则将运行参数导入至已经存在的pod601，若pod601已不存在，则删除计算模块501中已不存在pod601对应的信息，并删除转发队列602以及返回队列603中已不存在pod601对应的数据，将确定的最新pod601以及每个pod601对应的已发送业务请求流量数据导入至调度模块502。调度模块502根据每个pod601对应的已发送业务请求流量，确定存储至转发队列602的目标pod601；若pod601对应的flow_ratio值为0，则将该pod601存储至返回队列603，并将该pod601对应的已发送业务请求流量直接返回给计算模块501。转发模块503从转发队列602中获取可以转发的目标pod601，向目标pod601发送业务请求；根据业务请求，确定业务请求对应的目标流量，并将该目标流量发送给计算模块501，用于更新目标pod601对应的已发送业务请求流量。

图7为本申请一实施例提供的电子设备的结构示意图。示例性地，电子设备比如为本申请中公开的负载均衡设备，电子设备可以被提供为一服务器或计算机。参照图7，电子设备700包括处理组件701，其进一步包括一个或多个处理器，以及由存储器702所代表的存储器资源，用于存储可由处理组件701的执行的指令，例如应用程序。存储器702中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件701被配置为执行指令，以执行上述任一方法实施例。

电子设备700还可以包括一个电源组件703被配置为执行电子设备700的电源管理，一个有线或无线网络接口704被配置为将电子设备700连接到网络，和一个输入输出(I/O)接口705。电子设备700可以操作基于存储在存储器702的操作系统，例如WindowsServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

本申请还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上流量控制方法的方案。

本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如上的流量控制方法的方案。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于流量控制装置中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。