一种拥塞控制方法、装置及设备与流程

本文件涉及计算机技术领域，尤其涉及一种拥塞控制方法、装置及设备。

背景技术：

拥塞是指对资源的需求超过了可用的资源，而随着计算网络规模的不断扩大和应用业务的日益丰富，拥塞控制在保证网络运行和服务质量方面的重要性持续增加。

因此，需要提供更可靠的拥塞控制方案。

技术实现要素：

本说明书实施例提供一种拥塞控制方法，用以实现全链路自动控制容量，并确保实时最高容量的输出。

本说明书实施例还提供一种拥塞控制方法，包括：

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口。

本说明书实施例还提供一种拥塞控制方法，包括：

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

本说明书实施例还提供一种拥塞控制方法，应用于多个业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系；所述方法包括：

上游业务系统接收拥塞中控发送的下游业务系统的tps；

基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口。

本说明书实施例还提供一种拥塞控制方法，应用于多个业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系；所述方法包括：

最下游的业务系统接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。

本说明书实施例还提供一种拥塞控制装置，包括：

确定模块，确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

配置模块，基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口。

本说明书实施例还提供一种拥塞控制装置，包括：

确定模块，确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

发送模块，基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

本说明书实施例还提供一种拥塞控制装置，应用于多个业务系统中的上游业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系，装置包括：

接收模块，接收拥塞中控发送的下游业务系统的tps；

处理模块，基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口。

本说明书实施例还提供一种拥塞控制装置，应用于多个业务系统中的最下游的业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系，装置包括：

接收模块，接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

处理模块，基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。

本说明书实施例还提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口；或者，

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

本说明书实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现以下操作：

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口；或者，

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

本说明书实施例还提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

上游业务系统接收拥塞中控发送的下游业务系统的tps；

基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口；

或者，

最下游的业务系统接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。

本说明书实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现以下操作：

上游业务系统接收拥塞中控发送的下游业务系统的tps；

基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口；

或者，

最下游的业务系统接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。

本说明书一个实施例通过收集全链路中多个业务系统的tps，并从全局维度对各业务系统进行资源调配，从而实现统一的拥塞控制，达到全链路自动控制容量并确保实时最高容量的输出的目的。

附图说明

此处所说明的附图用来提供对本说明书的进一步理解，构成本说明书的一部分，本说明书的示意性实施例及其说明用于解释本说明书，并不构成对本说明书的不当限定。在附图中：

图1为本说明书提供的一种应用场景的示意图；

图2为本说明书一实施例提供的一种拥塞控制方法的流程示意图；

图3为本说明书一实施例提供的步骤204的一种实现方式的流程示意图；

图4为本说明书一实施例提供的全链路示意图；

图5为本说明书另一实施例提供的全链路示意图；

图6为本说明书一实施例提供的拥塞更新步骤的流程示意图；

图7为本说明书另一实施例提供的拥塞控制方法的流程示意图；

图8为本说明书一实施例提供的上游业务系统的拥塞控制方法的流程示意图；

图9为本说明书一实施例提供的最下游的业务系统的拥塞控制方法的流程示意图；

图10a为本说明书一实施例提供的保险全链路的拥塞控制方法的流程示意图；

图10b为本说明书一实施例提供的保险全链路的拥塞控制系统的示意图；

图10c为本说明书一实施例提供的开始和恢复算法的示意图；

图11为本说明书一实施例提供的一种拥塞控制装置的结构示意图；

图12为本说明书另一实施例提供的一种拥塞控制装置的结构示意图；

图13为本说明书又一实施例提供的一种拥塞控制装置的结构示意图；

图14为本说明书又一实施例提供的一种拥塞控制装置的结构示意图；

图15为本说明书一实施例提供的一种电子设备的结构示意图；

图16为本说明书另一实施例提供的一种电子设备的结构示意图。

具体实施方式

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

结合背景技术部分陈述的，在目前的全链路容量控制过程中，链路中的各个业务系统各自为政，无法全局协调资源，导致拥塞控制效果低下。基于此，本说明书提供一种拥塞控制方法，通过抽象出全链路的更高层的拥塞控制中心(拥塞中控)，并由拥塞控制中心将各类决策因子收口统一调配，从而实现全链路中各业务系统的自动容量控制，由此即能满足各业务系统内部对自身资源局部最优的诉求，也能在框架层解决全局一份的竞争类资源合理分配。

其中，全链路是指承载某一类业务场景的整条技术系统链路，如保险投保业务场景中，全链路是指承载保险投保业务的所有系统，其中包括保险业务系统、批量扣款业务系统等。

下面参见图1对本说明书的应用场景进行示例性说明。

第一个应用场景包括：拥塞中控110和全链路120，所述全链路120至少包括两个及以上业务系统，如包括业务系统121-123；其中：

拥塞中控110获取全链路120中各业务系统的tps及其之间的上下游关系，从全局维度为各个业务系统配置拥塞窗口；第一业务系统121和第二业务系统122基于拥塞中控配置的拥塞窗口进行业务处理。

第二个应用场景包括：拥塞中控110和全链路120，所述全链路120至少包括两个及以上业务系统，如包括业务系统121-123；其中：

拥塞中控110预先确定全链路120中各业务系统的上下游关系，然后，将下游业务系统的tps告知上游业务系统；上游业务系统基于下游业务系统的tps，自行决策出拥塞窗口。

其中，所述tps是指业务系统每秒钟request/事务，用于表征业务系统的承压能力；所述上下游关系是指各业务系统所实现的业务在业务流程上的依赖关系，如第三方支付系统实现的支付业务依赖保险业务系统实现的下单业务，即下单业务是支付业务的上游业务，保险业务系统是第三方支付系统上游的业务系统。

以下结合附图，详细说明本说明书各实施例提供的技术方案。

图2为本说明书一实施例提供的一种拥塞控制方法的流程示意图，所述方法可由上述第一应用场景中的拥塞中控执行，参见图2，所述方法具体可以包括如下步骤：

步骤202、确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

具体地，拥塞中控可周期性地检测各业务系统的tps并缓存，在下一次进行检测之前，使用本周期检测的tps进行拥塞控制；若下一次检测出存在业务系统的tps发生变化，则更新缓存的tps。或者，

各业务系统可周期性地向拥塞中控上报本业务系统的tps，供拥塞中控进行拥塞控制；而且，当本业务系统的tps发生变化时，则上报拥塞中控。

进一步地，可按照自上游到下游的顺序，确定各业务系统的tps，如参见图1，所述上下游依赖关系为第一业务系统为最上游的业务系统，第二业务系统为中游的业务系统，第三业务系统为最下游的业务系统，则可按照第一业务系统-第二业务系统-第三业务系统的顺序，确定各业务系统的tps。

基于此，本实施例通过抽象出一更高层的拥塞中控，由拥塞中控记录并维护各业务系统的tps，避免由各业务系统之间交互来采集对方的tps，从而提高全链路tps维护效率，为后续全局拥塞控制提高数据支持；而且，本实施例还进一步提供了tps确定顺序，按照上下游顺序进行tps的确定，与后续拥塞控制顺序相吻合，为提高拥塞控制效率提高数据支持。

步骤204、基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口。

具体地，参见图3，假设所述多个业务系统中包括第一业务系统，该第一业务系统可能是所述多个业务系统中的任一业务系统，则步骤204的一种实现方式可以为：

步骤302、确定所述多个业务系统中的第一业务系统的拥塞窗口预期值，所述第一业务系统由所述第一业务系统的tps或所述第一业务系统相邻的上游业务系统当前的拥塞窗口值确定；

其中，所述拥塞窗口预期值是指业务系统预期需要的拥塞窗口值，如某业务系统的tps为500，则在不考虑上下游业务系统的承压能力的前提下，该业务系统为释放最大业务处理能力可能需要500的拥塞窗口。

步骤304、基于所述第一业务系统的tps或第二业务系统的tps，确定所述第一业务系统的拥塞窗口约束值，所述第二业务系统为第一业务系统相邻的下游业务系统；

步骤306、基于所述拥塞窗口预期值和所述拥塞窗口约束值，确定所述第一业务系统的拥塞窗口值。

具体地，可按照从上游至下游的顺序，依次将多个业务系统中的每个业务系统作为第一业务系统，并执行步骤302至步骤306，从而为各业务系统配置拥塞窗口。

下面从最上游的业务系统、最下游的业务系统以及除两者之外的业务系统的角度，对上述步骤302至步骤306的实现方式进行详细说明：

步骤302至步骤306的第一种实现方式中，假设第一业务系统为所述多个业务系统中最上游的业务系统：

s11、由于最上游的业务系统的业务处理能力的释放不受上游业务系统的影响，因此，此处第一业务系统的拥塞窗口预期值可由所述第一业务系统的tps确定，具体可以等于第一业务系统的tps，也可以是小于第一业务系统的tps的预设值，所述预设值的具体预设方式可视情况而定，此处不再限定。为便于理解，此处将第一业务系统的拥塞窗口预期值设定为第一业务系统的tps。

s12、拥塞中控基于预先采集的所述多个业务系统的上下游依赖关系，检测第二业务系统是否还有其他的上游业务系统。

若所述第二业务系统(如图1中的业务系统122)上游仅存在所述第一业务系统(如图1中的业务系统121)，则认为能约束第一业务系统业务处理能力的变量仅在于第二业务系统的承压能力(或者说下游可用的资源)，进而可将所述第二业务系统的tps作为所述第一业务系统的拥塞窗口约束值。具体可以示例为：

假设图1中的业务系统121的tps为500，业务系统122的tps为2000，则可将500作为业务系统121的拥塞窗口预期值，将2000作为业务系统121的拥塞窗口约束值。

而若所述第二业务系统上游还存在其他业务系统，即所述第二业务系统接入的最上游的业务系统不唯一，则认为第一业务系统可利用的第二业务系统的承压能力可能会被所述其他业务系统瓜分一部分，进而可能无法利用到第二业务系统完整的承压能力，此时，拥塞中控可基于所述第一业务系统和所述其他业务系统的拥塞窗口预期值、所述第二业务系统的tps，确定所述第一业务系统的拥塞窗口约束值。参见图4，具体可以示例为：

示例1、假设图4中的第二业务系统402上游包括第一业务系统401和其他业务系统401`，第一业务系统的tps为500，其他业务系统401`的tps为500，第二业务系统402的tps为2000，通过对比三者的tps，可确定第二业务系统的承压能力足够支持第一业务系统401和其他业务系统401`释放最大业务处理能力，则可将第二业务系统的承压能力分配给第一业务系统与其tps(500)相同的值，即500，并将500作为第一业务系统的拥塞窗口约束值，同理可为其他业务系统401`分配500的业务处理能力作为拥塞窗口约束值。

其中，其他业务系统401`可能不唯一，则将所有业务系统401`的tps之和作为所述其他业务系统的拥塞窗口预期值。

示例2、假设图4中的第二业务系统402上游包括第一业务系统401和其他业务系统401`，第一业务系统的tps为500，其他业务系统401`的tps为2000，第二业务系统402的tps为2000，通过对比三者的tps，可确定第二业务系统的承压能力不能够支持第一业务系统401和其他业务系统401`释放最大业务处理能力，则按照预设分配规则，将第二业务系统的承压能力分配给第一业务系统和第二业务系统。

其中，预设分配规则可基于上游业务系统的拥塞窗口预期值、上游业务系统的业务优先级等影响因素而定，如基于上游业务系统的拥塞窗口预期值，按比例进行分配，则第一业务系统401可分得400的拥塞窗口约束值，其他业务系统401`可分得1600的拥塞窗口约束值；又如，上游业务系统的业务优先级越高，可分配得到的比例越高等。具体可视具体需求而定，此处不再限定。

s13、确定所述拥塞窗口预期值和所述拥塞窗口约束值中的最小值；并将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。具体可以示例为：

假设第一业务系统的拥塞窗口预期值为500，拥塞窗口约束值为2000，两者的最小值为500，则可确定第一业务系统的拥塞窗口值为不大于500。

为达到实时根据最高容量输出的目的，此处确定第一业务系统的拥塞窗口值为最小值500。当然在实际应用中，可能还需要考虑其他影响因素，如系统负载率(不超过80％)，则可确定第一业务系统的拥塞窗口值为400。

步骤302至步骤306的第二种实现方式中，假设第一业务系统为除所述最上游的业务系统和最下游的业务系统之外的业务系统：

s21、由于中游的第一业务系统的业务处理能力的释放受上游需求的下游承压能力的影响，因此，此处所述第一业务系统的拥塞窗口预期值可由所述第一业务系统相邻的上游业务系统当前的拥塞窗口值确定。具体可以示例为：

参见图1，假设第一业务系统为业务系统122，相邻的上游业务系统为业务系统121，业务系统121当前的拥塞窗口值为500(不难理解的是，业务系统121当前的拥塞窗口值已由之前针对业务系统121的拥塞窗口配置步骤实现)，显然，业务系统122需要释放多少的能力由业务系统121需求的下游承压能力而定，此处，业务系统121需求的下游承压能力为500，则确定第一业务系统的拥塞窗口预期值为500。

s22、拥塞中控基于预先采集的所述多个业务系统的上下游依赖关系，检测第二业务系统是否还有其他的上游业务系统。

其中，第二业务系统为第一业务系统相邻的下游业务系统，参见图1，假设第一业务系统为业务系统122时，第二业务系统为业务系统123。

若所述第二业务系统上游仅存在所述第一业务系统，则认为能约束第一业务系统业务处理能力的变量仅在于第二业务系统的承压能力，进而可将所述第二业务系统的tps作为所述第一业务系统的拥塞窗口约束值；

而若所述第二业务系统上游还存在其他业务系统，即所述第二业务系统接入的中游业务系统不唯一，则认为第一业务系统可利用的第二业务系统的承压能力可能会被所述其他业务系统瓜分一部分，进而可能无法利用到第二业务系统完整的承压能力，此时，拥塞中控可基于所述第一业务系统和所述其他业务系统的当前的拥塞窗口值、所述第二业务系统的tps，确定所述第一业务系统的拥塞窗口约束值。参见图5，具体可以示例为：

假设图5中的第二业务系统502上游包括第一业务系统501和其他业务系统501`，第一业务系统501当前的拥塞窗口为500，其他业务系统501`当前的拥塞窗口为1500，第二业务系统的tps为3000，通过对比，可确定第二业务系统的承压能力足够支持第一业务系统501和其他业务系统501`当前拥塞窗口下所需的下游承压能力，则将第二业务系统的业务处理能力分配给第一业务系统501与其当前拥塞窗口相等的值，即500，并作为第一业务系统501的拥塞窗口约束值，同理为其他业务系统501`分配1500的值作为拥塞窗口约束值。

而当第二业务系统的tps为1000时，通过对比，可以确定第二业务系统的承压能力不足以支持第一业务系统501和其他业务系统501`当前拥塞窗口下所需的下游承压能力，则按照预设分配规则，将第二业务系统的资源分配给第一业务系统501和其他业务系统501`。对于其中的所述预设分配规则，此处不再限定。

s23、确定所述拥塞窗口预期值和所述拥塞窗口约束值中的最小值；并将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。

步骤302至步骤306的第三种实现方式中，假设第一业务系统为最下游的业务系统：

s31、由于下游的第一业务系统的业务处理能力的释放受上游需求的下游承压能力的影响，因此，此处所述第一业务系统的拥塞窗口预期值可由所述第一业务系统相邻的上游业务系统当前的拥塞窗口值确定。

具体地，可以将第一业务系统的拥塞窗口预期值确定为所述第一业务系统相邻的上游业务系统当前的拥塞窗口值。若所述第一业务系统相邻的上游业务系统为多个，则计算多个相邻的善上游业务系统当前的拥塞窗口值之和，并将求和结果作为第一业务系统的拥塞窗口预期值。

s32、由于最下游的第一业务系统为业务流程的最后一环，其业务处理能力的释放不受下游业务系统的承压能力的影响，因此，可直接将自身承压能力作为约束，即将所述第一业务系统的tps作为所述第一业务系统的拥塞窗口约束值。

s33、确定所述拥塞窗口预期值和所述拥塞窗口约束值中的最小值；并将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。

需要说明的是，由于相邻的上游业务系统当前的拥塞窗口值也是在第一业务系统的tps约束下生成的，因此，必然不会超出第一业务系统的承压能力，故，也可直接将相邻的上游业务系统当前的拥塞窗口值设置为第一业务系统的拥塞窗口值；当然，也可将第一业务系统的拥塞窗口值设置为相邻的上游业务系统当前的拥塞窗口值和所述第一业务系统的tps之间的任意值。

基于此，本实施例通过分析上游业务系统所需资源与下游业务系统提供的可用资源之间的对应关系，为业务系统一一配置拥塞窗口，从而可从更高的维度对所述多个业务系统进行资源调配，实现统一的拥塞控制；而且，本实施例还提供了从上游至下游，依次为业务系统分配拥塞窗口的方案，从而能够提高统一资源分配的效率。

另外，对于骤302至步骤306的上述三个实现方式中，除最下游的业务系统的之外的业务系统，可能出现的下游业务系统的承压能力(资源)不足以支撑上游业务系统预期的资源需求，如第二个实现方式中陈述的第二业务系统的承压能力不足以支持第一业务系统50(1和其他业务系统501`)当前拥塞窗口下所需的下游承压能力，拥塞中控认为其出现拥塞情况，则执行拥塞处理步骤，其一种实现方式可以为：

s41、若所述第一业务系统下游的第三业务系统出现拥塞，则基于所述第三业务系统的拥塞窗口约束值修正所述第一业务系统的拥塞窗口约束值；

s42、基于修正后的拥塞窗口约束值，修正所述第一业务系统当前的拥塞窗口值。具体可以示例为：

参见图5，假设第一业务系统为业务系统502，其拥塞窗口预期值由相邻上游的业务系统501和业务系统501`当前的拥塞窗口确定(可以为两者当前的拥塞窗口之和)，第三业务系统为业务系统n，其tps设为3000，其拥塞窗口预期值设为2000。若业务系统n发生拥塞，则拥塞中控可判定业务系统n的拥塞窗口预期值与业务系统n相邻的下游业务系统m的tps(设为400)不匹配，或者说，业务系统n预期需要的资源大于业务系统m可提供的资源，则将业务系统m的tps(400)作为业务系统n的拥塞窗口约束值，并使用业务系统n的拥塞窗口约束值(400)按照由下游向上游的顺序，依次修正上游业务系统的拥塞窗口约束值。修正过程具体包括：

首先，判断业务系统n相邻的上游业务系统n-1当前的拥塞窗口约束值(为从业务系统n的tps中分配的tp)是否大于所述业务系统n的拥塞窗口约束值(400)；若是，则将业务系统n-1当前的拥塞窗口约束值修正为400，基于修正后的拥塞窗口约束值，重新计算业务系统n-1的拥塞窗口值；若业务系统n-1有多个，则按照预设分配规则，将修正后的拥塞窗口约束值分配给多个业务系统n-1，并使用各业务系统n-1最新的拥塞窗口约束值，重新计算拥塞窗口值。

基于此，本实施例在配置拥塞窗口的过程中，针对下游业务系统出现的拥塞情况，按照从下游向上游的顺序，依次对已配置拥塞窗口的业务系统进行拥塞窗口的修正，确保全链路均不会出现拥塞情况，从而达到提高拥塞控制效率的目的。

综上所述，本实施例通过由拥塞控制中心基于多个业务系统的tps，从全局维度对各业务系统进行资源调配，从而实现拥塞统一控制，达到全链路自动控制容量并确保实时根据最高容量输出的目的。

在另一可行实施例中，由于全链路中的业务系统可能会出现异常，如网络异常、机器故障等，因此，业务系统的承压能力可能会受到影响，进而影响上下游业务系统的业务处理能力的释放，如目标业务系统中的10个计算机中的2个断开连接，则目标业务系统的承压能力会变弱，若所述目标业务系统上游的业务系统依然按照之前的业务处理效率进行工作，则会在目标业务系统出出现拥塞。基于此，为提高全链路的稳定性，本实施例在图2对应的实施例的基础上，提供了一种拥塞更新方法，参见图6，所述方法具体可以包括如下步骤：

步骤602、周期性地检测多个业务系统的tps；

步骤604、判断各业务系统的tps是否发生变化；

若是，则执行步骤606；否则等待下一检测周期；

为避免过度的拥塞更新操作引起的系统负载过大，本实施例还进一步限定，在业务系统的tps的变化比例大于预设阈值时，方可执行步骤606；否则直接忽略。其中，所述预设阈值可以为5％，如业务系统的tps下降比例大于5％时，方可执行步骤606。

步骤606、基于所述第一目标业务系统变化后的tps，更新所述多个业务系统当前的拥塞窗口值。具体可以为：

假设第一目标业务系统为所述多个业务系统中最上游的业务系统，则步骤606的第一种实现方式可以为：

首先，使用第一目标业务系统变化后的tps更新所述第一目标业务系统的拥塞窗口预期值；基于更新后的拥塞窗口预期值和当前的拥塞窗口约束值，更新所述第一目标业务系统的拥塞窗口值。

然后，基于所述第一目标业务系统更新后的拥塞窗口值，更新所述第一目标业务系统相邻的下游业务系统的拥塞窗口预期值，并基于所述第一目标业务系统相邻的下游业务系统更新后的拥塞窗口预期值和当前的拥塞窗口约束值，更新所述第一目标业务系统相邻的下游业务系统的拥塞窗口值。

以此类推，按照从上游向下游的顺序，依次更新每个业务系统的拥塞窗口值。

假设第一目标业务系统为所述多个业务系统中最下游的业务系统，则步骤606的第二种实现方式可以为：

首先，判断第一目标业务系统的tps是发生了增长还是减少，若是增长，则本次变化并不影响全链路当前的最高容量输出，可忽略本次更新；若是减少，则对比变化后的tps和第一目标业务系统相邻的上游业务系统当前的拥塞窗口，若对比获知变化后的tps依然能够满足所述相邻的上游业务系统需求的资源，如变化后的tps依然大于搜索相邻的上游业务系统当前的拥塞窗口，则依然不影响全链路当前的最高容量输出，可忽略本次更新；而若对比获知变化后的tps无法满足所述相邻的上游业务系统需求的资源，如变化后的tps小于所述相邻的上游业务系统当前的拥塞窗口，即所述相邻的上游业务系统出现拥塞反馈，则按照从下游向上游的顺序，依次修正上游业务系统的拥塞窗口，具体可使用图2对应的实施例中记载的拥塞处理步骤进行拥塞更新，此处不再展开说明。

假设第一目标业务系统为所述多个业务系统中除最下游的业务系统和最上游业务系统之外的业务系统，则步骤606的第三种实现方式可以为：

第一方面，按照从下游向上游的顺序，依次调整所述第一目标业务系统上游的业务系统的拥塞窗口约束值，并基于更新后的拥塞窗口约束值，更新业务系统当前的拥塞窗口。具体可参照步骤606的第二种实现方式，此处不再赘述。

第二方面，基于变化后的tps，更新第一目标业务系统的拥塞窗口预期值；基于更新后的拥塞窗口预期值和当前的拥塞窗口约束值，更新所述第一目标业务系统的拥塞窗口值；

以此类推，按照从上游向下游的顺序，依次调整所述第一目标业务系统下游的业务系统。具体可按照步骤606的第一种实现方式，此处不再赘述。

而且，在完成拥塞更新之后，以及全链路稳定之后，本实施例还提供了恢复方案，具体地：

s61、基于所述第一目标业务系统变化后的tps，更新所述第一目标业务系统当前的慢开始阈值；

其中，当前的慢开始阈值可以是基于经验预设的值。

则s61具体可以示例为：基于变化前的tps和当前的慢开始阈值计算慢开始系数；然后，基于变化后的tps和所述慢开始系数，生成新的慢开始阈值。

s62、基于更新后的慢开始阈值进行恢复。具体可以示例为：

确定所述第一目标业务系统的tps的变化比例；若变化比例大于预设变化阈值，则进行基于更新后的慢开始阈值进行快恢复；反之则进行慢恢复。

简而言之，tps的变化程度越高，则恢复速度越快；反之，tps的变化程度越低，则恢复速度越慢。

基于此，本实施例针对业务系统可能发生tps波动的情况，由拥塞中控基于tps的变化，实时动态更新受影响业务系统的拥塞窗口，从而确保全链路能够实时根据最高容量输出；而且，本实施例还提出了拥塞更新后的恢复方案，通过更新慢开始阈值及选择合适的恢复方式，提高全链路恢复到最高容量输出额效率。

在又一实施例中，由于全链路中的业务系统可能会出现紧急情况导致图6对应实施例中的拥塞更新无法及时发挥作用，如业务系统的承压能力瞬间降低90％，导致拥塞更新方案无法及时响应。基于此，为进一步提高全链路的稳定性，本实施例在图6对应的实施例的基础上，提供一种拥塞抖动处理方法，所述方法的第一种实现方式可以为：

检测到所述多个业务系统中出现至少一个第二目标业务系统时，使用预设的紧急拥塞窗口值替换所述第二目标业务系统当前的拥塞窗口值；然后，使用上述拥塞更新方案，基于紧急拥塞窗口值，进行其他业务系统的拥塞窗口的更新。

第二种实现方式可以为：

检测到所述多个业务系统中出现至少一个第二目标业务系统时，使用预设的紧急拥塞窗口值替换每个业务系统当前的拥塞窗口值。

其中，所述第二目标业务系统为发生紧急抖动的业务系统，且紧急抖动下tps的降低比例大于预设阈值(如下降了80％)，所述紧急拥塞窗口值为预设的专家经验值。

第三种方式可以为：

检测到全链路的输出容量下降比例大于预设阈值(如下降了70％)时，使用预设的紧急拥塞窗口值替换每个业务系统当前的拥塞窗口值；或者，检测出出现紧急抖动的业务系统，并使用预设的紧急拥塞窗口值替换所述第二目标业务系统当前的拥塞窗口值；然后，使用上述拥塞更新方案，基于紧急拥塞窗口值，进行其他业务系统的拥塞窗口的更新。

基于上述三种实现方式，在全链路稳定之后，本实施例还提供了恢复方案，具体地：

使用预设的紧急慢开始阈值替换所述第二目标业务系统当前的慢开始阈值，并基于所述紧急慢开始阈值进行快恢复，所述紧急慢开始阈值为预先设置的专家经验值。

相对于图6对应的实施例中的恢复方案，由于本实施例中紧急抖动的情况时间段、波动大，常规的恢复方案无法适应，因此，本实施例提供了紧急恢复方案，通过预设的紧急慢开始阈值进行快恢复，使得全链路能够尽快恢复到最高容量输出。

基于此，本实施例针对紧急抖动的情况，通过预先设置相关紧急拥塞窗口值进行紧急拥塞更新，并通过预先设置紧急慢开始阈值和预选择快恢复方式，进行紧急拥塞恢复，使得全链路在面对紧急抖动时，能够尽快恢复到最高容量输出，降低影响。

图7为本说明书另一实施例提供的拥塞控制方法的流程示意图。可由上述第二应用场景中的拥塞中控执行，参见图7，所述方法具体可以包括如下步骤：

步骤702、确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

其中，各业务系统的tps确定方案已在图2对应的实施例中进行了陈述，此处不再赘述。

步骤704、基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

假设所述多个业务系统包括第一业务系统和第二业务系统，所述第二业务系统为第一业务系统相邻的下游业务系统，则步骤704具体可以示例为：

示例1、若所述第一业务系统为最上游的业务系统，则将所述第二业务系统的tps发送给所述第一业务系统。

第一业务系统将所述第二业务系统的tps作为拥塞窗口约束值，将本业务系统的tps作为拥塞窗口预期值，对比拥塞窗口约束值和拥塞窗口预期值，将两者中的最小值作为第一业务系统的拥塞窗口值，基于拥塞窗口值进行业务处理。

进一步地，在示例1中，若第二业务系统上游还有其他业务系统，则拥塞中控还将所述其他业务系统的tps一并发送给第一业务系统，由第一业务系统基于约定的分配规则，确定第一业务系统可分配的第二业务系统的资源(如60％的tps)，并由可分配的资源生成拥塞窗口约束值，并将拥塞窗口约束值和拥塞窗口预期值中的最小值作为第一业务系统的拥塞窗口值。

可选的，第一业务系统可直接将本业务系统的拥塞窗口值告知第二业务系统，也可以通过拥塞中控告知第二业务系统，以供第二业务系统确定第二业务系统的拥塞窗口预期值。

示例2、若所述第一业务系统为除最上游的业务系统和最下游的业务系统之外的业务系统，则将所述第二业务系统的tps和所述第一业务系统相邻的上游业务系统决策出的拥塞窗口值发送给所述第一业务系统。

第一业务系统一方面基于下游的第二业务系统的tps确定第一业务系统的拥塞窗口约束值，另一方面基于相邻的上游业务系统当前的拥塞窗口值确定拥塞窗口预期值，然后，对比拥塞窗口约束值和拥塞窗口预期值，将两者中的最小值作为第一业务系统的拥塞窗口值，基于拥塞窗口值进行业务处理。

针对示例1和示例2，在为各业务系统配置拥塞窗口的过程中，若拥塞中控到接收所述多个业务系统中的目标业务系统发送的拥塞反馈，则认为目标业务系统相邻下游业务系统的可用资源无法满足目标业务系统拥塞窗口预期值，则生成拥塞窗口约束条件，所述拥塞窗口约束条件由所述目标业务系统相邻的下游业务系统的tps确定；所述拥塞窗口约束条件具体可以为将相邻的下游业务系统的tps作为拥塞窗口约束值；将所述拥塞窗口约束条件发送给所述目标业务系统的上游业务系统，供修正所述目标业务系统的上游业务系统的拥塞窗口约束值，进而修正其当前的拥塞窗口。

其中，拥塞修正方案具体可以为：

拥塞中控首先将所述拥塞窗口约束条件发送给所述目标业务系统相邻的上游业务系统；所述相邻的上游业务系统基于所述拥塞窗口约束条件修正其当前的拥塞窗口约束值，进而修正其当前的拥塞窗口，并将修正后的拥塞窗口约束值作为新的拥塞窗口约束条件通过拥塞中控或者直接发送给本业务系统相邻的上游业务系统；以此类推，直至完成最上游的业务系统的拥塞窗口的修正。

另外，在完成各业务系统的拥塞窗口的配置之后，本实施例还包括拥塞更新方案，包括：

所述多个业务系统中的第二业务系统的tps发生变化时，将所述第二业务系统的变化后的tps发送给所述第一业务系统，供所述第一业务系统更新拥塞窗口值。需要说明的是，所述拥塞更新方案与上述实施例中的拥塞更新步骤相似，故，此处不再赘述。

在另一可行实施例中，对于所述多个业务系统中的最下游业务系统，拥塞中控将确定最下游业务系统相邻的上游业务系统决策出的拥塞窗口值；然后，将所述最下游业务系统相邻的上游业务系统当前的拥塞窗口值发送给所述最下游业务系统；所述最下游业务系统将对比相邻的上游业务系统当前的拥塞窗口值和所述最下游业务系统的tps，并将两者中的最小值作为最下游业务系统的拥塞窗口。

基于此，本实施例通过为全链路构建拥塞中控，由拥塞中控检测全局的tps及其变化，并为业务系统提供相关业务系统的tps，以供业务系统决策自身的拥塞窗口，从而可在保证业务系统内容需求的情况下，确保全链路的最高容量输入；而且，业务系统还可向拥塞中控进行拥塞反馈，供拥塞中控生成拥塞窗口约束条件，并发送给上游业务系统，供修正上游当前的拥塞窗口，以确保全链路不会出现拥塞情况。

图8为本说明书另一实施例提供的拥塞控制方法的流程示意图，该方法应用于多个业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系，具体可由图1中除最下游的业务系统之外的业务系统执行，参见图8，所述方法具体可以包括：

步骤802、上游业务系统接收拥塞中控发送的下游业务系统的tps；

步骤804、基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口。

下面对步骤802-步骤804进行详细说明：

所述上游业务系统包括第一业务系统，所述第一业务系统为最上游的业务系统，则步骤802-步骤804的第一实现方式可以为：

首先，第一业务系统接收所述拥塞中控发送的第二业务系统的tps，所述第二业务系统为第一业务系统相邻的下游业务系统。然后，确定所述第一业务系统的tps和所述第二业务系统的tps中的最小值；并将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。

进一步地，若第二业务系统相邻上游还有其他业务系统，则拥塞中控还会将上述其他业务系统的tps或者拥塞窗口预期值发送给第一业务系统；第一业务系统基于预约定的分配规则，确定第一业务系统可分配的第二业务系统的资源(tps)，并将所述第一业务系统的拥塞窗口值确定为不大于可分配的tps和第一业务系统的tps中的最小值。

所述上游业务系统包括第一业务系统，所述第一业务系统为除最上游的业务系统和最下游的业务系统之外的业务系统，则步骤802-步骤804的第二实现方式可以为：

首先，接收所述拥塞中控发送的所述第二业务系统的tps和所述第一业务系统相邻的上游业务系统决策出的拥塞窗口值；然后，确定所述第二业务系统的tps和所述第一业务系统相邻的上游业务系统决策出的拥塞窗口值的最小值；并将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。

另外，在由上游向下游进行拥塞窗口配置过程中，可能在目标业务系统出现拥塞情况，则目标业务系统向拥塞中控进行拥塞反馈；拥塞中间基于上述目标业务系统相邻的下游业务系统的tps生成拥塞窗口约束条件，并将拥塞窗口约束条件发送给上游业务系统；上游业务系统接收所述拥塞中控发送的拥塞窗口约束条件，并基于所述拥塞窗口约束条件，修正上游业务系统当前的拥塞窗口值。

其中，拥塞修正方案已在图7对应的实施例中给出了详细陈述，故，此处不再赘述。

基于此，本实施例针对出最下游业务系统之外的业务系统，通过与拥塞中控的交互获知下游业务系统的tps，进而得到下游业务系统可提供的资源；然后，将其与本业务系统需求的资源进行对比，进而决策出本业务系统的拥塞窗口，由此可在确保本业务系统内部的资源最优诉求的基础上，实现与其他业务系统之间的全局资源协调，实现全链路的最高容量输出。

图9为本说明书另一实施例提供的拥塞控制方法的流程示意图，该方法应用于多个业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系，具体可由图1中最下游的业务系统执行，参见图9，所述方法具体可以包括：

步骤902、最下游的业务系统接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

其中，所述拥塞窗口值为所述相邻的上游业务系统基于所述最下游的业务系统的tps和所述相邻的上游业务系统的拥塞窗口预期值确定，具体可将两者中的最小值作为所述拥塞窗口值。所述拥塞窗口预期值的计算方式已在上述实施例中给出了具体介绍，故，此处不再赘述。

步骤904、基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。具体地，

若所述最下游的业务系统的tps大于或等于所述拥塞窗口值，则将拥塞窗口决策为所述拥塞窗口值和所述最下游的业务系统的tps中的最小值。

基于此，本实施例针对出最下游业务系统，通过与拥塞中控的交互获知上游业务系统需求的资源；然后，将其与本业务系统可提供的资源进行对比，进而决策出本业务系统的拥塞窗口，由此可在确保本业务系统内部的资源最优诉求的基础上，实现与其他业务系统之间的全局资源协调，实现全链路的最高容量输出。

图10a为本说明书一实施例提供的保险全链路的拥塞控制方法的流程示意图，参见图10a，下面以保险全链路为例对所述方法进行示例性说明：

从上游到下游，假设保险全链路中的保险业务系统的tps为500，批量扣款业务系统paybatch的tps为2000，业务方系统accorder的tps为3000，支付核心系统paycore的tps为1500，再结合图10b示出的保险全链路拥塞控制系统及其逻辑示意图，则所述拥塞控制方法具体可以为：

步骤1002、保险账单下发，初始化慢开始阈值

具体地，基于业务方的自定义或历史压测数据，初始化慢开始阈值；然后，进行指数级增加保单批扣速率，当批扣速度达到预设的慢开始阈值，进行拥塞控制加法增加(即线性增加批扣速度)，参见图10c中0-44段的线条--■--。

步骤1004、为保险业务系统配置拥塞窗口，具体可以示例为：

示例1、paybatch为2000tps，大于保险系统的500tps。此时，拥塞中控配置保险系统的拥塞窗口为500tps；或者，拥塞中控将‘paybatch为2000tps’的信息发送给保险系统，由保险系统决策增大拥塞窗口直到500tps，并确认paybatch的拥塞窗口预期值为500tps。

示例2、paybatch上游还对接有另一业务系统，所述另一业务系统为1500tps，paybatch依然能够满足所述保险系统和所述另一业务系统的资源需求之和。此时，拥塞中控配置保险系统的拥塞窗口为500tps，所述另一业务系统的拥塞窗口为1500tps，并确认paybatch的拥塞窗口预期值为两者之和，即2000tps；或者，拥塞中控将‘paybatch为2000tps，对接的保险系统为500tps，对接的另一业务系统为1500tps’的信息发送给保险系统和所述另一业务系统，由所述保险系统和所述另一业务系统基于预设的分配规则，分别配置各自的拥塞窗口为500tps和1500tps，并确认paybatch的拥塞窗口预期值为两者之和，即2000tps。

步骤1006、为paybatch配置拥塞窗口

在步骤1004的示例2的基础上，accorder为3000tps，大于paybatch的2000tps。此时，拥塞中控将accorder的tps作为paybatch的拥塞窗口约束值，对比paybatch的拥塞窗口预期值和拥塞窗口约束值，并将两者中的最小值，即2000tps配置为paybatch的拥塞窗口；或者，拥塞中控将‘accorder为3000tps’的信息发送给paybatch，由paybatch将accorder的tps作为paybatch的拥塞窗口约束值，对比paybatch的拥塞窗口预期值和拥塞窗口约束值，并将两者中的最小值，即2000tps配置为paybatch的拥塞窗口。

步骤1008、为accorder配置拥塞窗口

在步骤1006示例的基础上，拥塞中控或accorder将paybatch当前的拥塞窗口(2000tps)作为accorder的拥塞窗口预期值，并增大拥塞窗口到paybatch的2000，则出现拥塞情况；然后，将paycore的1500tps作为accorder的拥塞窗口约束值，并对比拥塞窗口预期值和拥塞窗口约束值，将两者中的最小值即1500tps配置为accorder的拥塞窗口。

由于accorder出现了拥塞情况，则基于accorder下游的paycore的tps生成拥塞窗口约束值，即1500tps；然后，按照由下游向上游的顺序，先基于该拥塞窗口约束值将paybatch的拥塞窗口修正为1500tps；再基于修正后的1500tps，修正paybatch上游的保险业务系统和所述另一业务系统的拥塞窗口。

步骤1010、为paycore配置拥塞窗口值

将paycore相邻上游的accorder实际的拥塞窗口(1500tps)作为paycore的拥塞窗口。

下面对拥塞更新的情况进行详细说明：

拥塞中控定时触发拥塞探测来探测各业务系统的tps，假定探测到paycore从1500降低到1300，则将1300tps作为accorder更新后的拥塞窗口约束值，并对比更新后的拥塞窗口约束值和accorder当前的拥塞窗口1500tps，将accorder的拥塞窗口更新为1300tps；以此类推，更新paybatch和保险业务系统的拥塞窗口。

在完成全链路的拥塞更新之后，待全链路稳定之后，还包括基于paycore当前的tps重新设置慢开始阈值，并基于新的慢开始阈值进行恢复(若降低比例低则采取慢恢复，若比例大则采取快恢复)，参见图10c中的16-44段的--▲--的快恢复；或者，8-36段的—▲—的慢恢复。

下面对紧急抖动的情况进行详细说明：

假定故障发生时间处于两次拥塞周期之前，即未检测到故障发生，假定此时此时accorder机器性能抖动，从3000tps降低到800tps，降低比例较大，已达到紧急抖动的门限值，则将当前的拥塞窗口值替换为预设的紧急拥塞窗口值，并将慢开始阈值重设为预设紧急慢开始阈值，并基于重新的紧急慢开始阈值进行快恢复，以期尽快恢复全链路的容量输出。

基于此，本实施例通过预先摸底各业务系统的瓶颈tps，然后从全局维度对各业务系统进行资源调配，实现全链路的自动控制容量以及实时根据最高容量输出。

图11为本说明书一实施例提供的一种拥塞控制装置的结构示意图，参见图11，所述装置具体可以包括：确定模块111和配置模块112，其中：

确定模块111，确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

具体地，拥塞中控可周期性地检测各业务系统的tps并缓存，在下一次进行检测之前，使用本周期检测的tps进行拥塞控制；若下一次检测出存在业务系统的tps发生变化，则更新缓存的tps。或者，

各业务系统可周期性地向拥塞中控上报本业务系统的tps，供拥塞中控进行拥塞控制；而且，当本业务系统的tps发生变化时，则上报拥塞中控。

进一步地，可按照自上游到下游的顺序，确定各业务系统的tps，如参见图1，所述上下游依赖关系为第一业务系统为最上游的业务系统，第二业务系统为中游的业务系统，第三业务系统为最下游的业务系统，则可按照第一业务系统-第二业务系统-第三业务系统的顺序，确定各业务系统的tps。

配置模块112，基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口。

可选的，配置模块112，包括：

确定单元，确定所述多个业务系统中的第一业务系统的拥塞窗口预期值，所述第一业务系统由所述第一业务系统的tps或所述第一业务系统相邻的上游业务系统当前的拥塞窗口值确定；

其中，所述拥塞窗口预期值是指业务系统预期需要的拥塞窗口值，如某业务系统的tps为500，则在不考虑上下游业务系统的承压能力的前提下，该业务系统为释放最大业务处理能力可能需要500的拥塞窗口。

第一处理单元，基于所述第一业务系统的tps或第二业务系统的tps，确定所述第一业务系统的拥塞窗口约束值，所述第二业务系统为第一业务系统相邻的下游业务系统；

第二处理单元，基于所述拥塞窗口预期值和所述拥塞窗口约束值，确定所述第一业务系统的拥塞窗口值。

可选的，所述第一业务系统为最上游的业务系统，所述拥塞窗口预期值由所述第一业务系统的tps确定；

其中，第一处理单元，若所述第二业务系统上游仅存在所述第一业务系统，则将所述第二业务系统的tps作为所述第一业务系统的拥塞窗口约束值；若所述第二业务系统上游还存在其他业务系统，则所述基于所述第一业务系统和所述其他业务系统的拥塞窗口预期值、所述第二业务系统的tps，确定所述第一业务系统的拥塞窗口约束值。

可选的，所述第一业务系统为除所述最上游的业务系统和最下游的业务系统之外的业务系统，所述拥塞窗口预期值由所述第一业务系统相邻的上游业务系统当前的拥塞窗口值确定；

其中，第一处理单元，若所述第二业务系统上游仅存在所述第一业务系统，则将所述第二业务系统的tps作为所述第一业务系统的拥塞窗口约束值；若所述第二业务系统上游还存在其他业务系统，则所述基于所述第一业务系统和所述其他业务系统的当前的拥塞窗口值、所述第二业务系统的tps，确定所述第一业务系统的拥塞窗口约束值。

可选的，所述第一业务系统为最下游的业务系统，所述拥塞窗口预期值由所述第一业务系统相邻的上游业务系统当前的拥塞窗口值确定；

其中，第一处理单元，将所述第一业务系统的tps作为所述第一业务系统的拥塞窗口约束值。

可选的，第二处理单元，确定所述拥塞窗口预期值和所述拥塞窗口约束值中的最小值；将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。具体可以示例为：

假设第一业务系统的拥塞窗口预期值为500，拥塞窗口约束值为2000，两者的最小值为500，则可确定第一业务系统的拥塞窗口值为不大于500。

为达到实时根据最高容量输出的目的，此处确定第一业务系统的拥塞窗口值为最小值500。当然在实际应用中，可能还需要考虑其他影响因素，如系统负载率(不超过80％)，则可确定第一业务系统的拥塞窗口值为400。

可选的，所述第一业务系统为除最下游的业务系统的之外的业务系统，所述装置还包括：

拥塞修正模块，若所述第一业务系统下游的第三业务系统出现拥塞，则基于所述第三业务系统的拥塞窗口约束值修正所述第一业务系统的拥塞窗口约束值；基于修正后的拥塞窗口约束值，修正所述第一业务系统当前的拥塞窗口值。

可选的，所述装置还包括：

拥塞更新模块，所述多个业务系统中的第一目标业务系统的tps发生变化时，基于所述第一目标业务系统变化后的tps，更新所述多个业务系统当前的拥塞窗口值。

可选的，所述装置还包括：

拥塞恢复模块，基于所述第一目标业务系统变化后的tps，更新所述第一目标业务系统当前的慢开始阈值，并基于更新后的慢开始阈值进行恢复。

可选的，所述拥塞恢复模块，确定所述第一目标业务系统的tps的变化比例；若变化比例大于预设变化阈值，则进行基于更新后的慢开始阈值进行快恢复；反之则进行慢恢复。

可选的，所述装置还包括：

紧急处理模块，所述多个业务系统中出现至少一个第二目标业务系统时，使用预设的紧急拥塞窗口值替换所述第二目标业务系统当前的拥塞窗口值；

其中，所述第二目标业务系统为发生紧急抖动的业务系统，且紧急抖动下tps的降低比例大于预设阈值。

可选的，所述装置还包括：

紧急恢复模块，使用预设的紧急慢开始阈值替换所述第二目标业务系统当前的慢开始阈值，并基于所述紧急慢开始阈值进行快恢复。

可见，本实施例通过由拥塞控制中心基于多个业务系统的tps，从全局维度对各业务系统进行资源调配，从而实现拥塞统一控制，达到全链路自动控制容量并确保实时根据最高容量输出的目的。

图12为本说明书另一实施例提供的一种拥塞控制装置的结构示意图，参见图12，所述装置具体可以包括：确定模块121和发送模块122，其中：

确定模块121，确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

发送模块122，基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

可选的，所述多个业务系统包括第一业务系统和第二业务系统，所述第二业务系统为第一业务系统相邻的下游业务系统；

其中，所述发送模块122，包括：

第一发送单元，若所述第一业务系统为最上游的业务系统，则将所述第二业务系统的tps发送给所述第一业务系统；

第二发送单元，若所述第一业务系统为除最上游的业务系统和最下游的业务系统之外的业务系统，则将所述第二业务系统的tps和所述第一业务系统相邻的上游业务系统决策出的拥塞窗口值发送给所述第一业务系统。

可选的，装置还包括：

拥塞更新模块，所述多个业务系统中的第二业务系统的tps发生变化时，将所述第二业务系统的变化后的tps发送给所述第一业务系统，供所述第一业务系统更新拥塞窗口值。

可选的，装置还包括：

拥塞修正模块，若接收所述多个业务系统中的目标业务系统发送的拥塞反馈，则生成拥塞窗口约束条件，所述拥塞窗口约束条件由所述目标业务系统相邻的下游业务系统的tps确定；

将所述拥塞窗口约束条件发送给所述目标业务系统的上游业务系统，供修正拥塞窗口值。

可选的，装置还包括：

最下游业务系统处理模块，确定所述多个业务系统中的最下游业务系统相邻的上游业务系统决策出的拥塞窗口值；将所述最下游业务系统相邻的上游业务系统当前的拥塞窗口值发送给所述最下游业务系统，供决策所述最下游业务系统的拥塞窗口。

基于此，本实施例通过为全链路构建拥塞中控，由拥塞中控检测全局的tps及其变化，并为业务系统提供相关业务系统的tps，以供业务系统决策自身的拥塞窗口，从而可在保证业务系统内容需求的情况下，确保全链路的最高容量输入；而且，业务系统还可向拥塞中控进行拥塞反馈，供拥塞中控生成拥塞窗口约束条件，并发送给上游业务系统，供修正上游当前的拥塞窗口，以确保全链路不会出现拥塞情况。

图13为本说明书又一实施例提供的一种拥塞控制装置的结构示意图，应用于多个业务系统中的上游业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系，参见图13，所述装置具体可以包括：接收模块131和处理模块132，其中：

接收模块131，接收拥塞中控发送的下游业务系统的tps；

处理模块132，基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口。

可选的，所述上游业务系统包括第一业务系统，所述第一业务系统为最上游的业务系统；

其中，所述接收模块131，接收所述拥塞中控发送的第二业务系统的tps，所述第二业务系统为第一业务系统相邻的下游业务系统。

可选的，所述处理模块132，确定所述第一业务系统的tps和所述第二业务系统的tps中的最小值；将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。

可选的，所述上游业务系统包括第一业务系统，所述第一业务系统为除最上游的业务系统和最下游的业务系统之外的业务系统；

其中，所述接收模块131，接收所述拥塞中控发送的所述第二业务系统的tps和所述第一业务系统相邻的上游业务系统决策出的拥塞窗口值。

可选的，所述处理模块132，确定所述第二业务系统的tps和所述第一业务系统相邻的上游业务系统决策出的拥塞窗口值的最小值；将所述第一业务系统的拥塞窗口值确定为不大于所述最小值。

可选的，所述装置还包括：

拥塞修正模块，接收所述拥塞中控发送的拥塞窗口约束条件，所述拥塞窗口约束条件为下游的目标业务系统出现拥塞时，由所述目标业务系统相邻的下游业务系统的tps确定；基于所述拥塞窗口约束条件，修正当前的拥塞窗口值。

图14为本说明书又一实施例提供的一种拥塞控制装置的结构示意图，应用于多个业务系统中最下游的业务系统，所述多个业务系统在业务流程上存在的上下游依赖关系，参见图14，所述装置具体可以包括：接收模块141和处理模块142，其中：

接收模块141，接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

处理模块142，基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。

可选的，所述处理模块142，确定所述拥塞窗口值和所述最下游的业务系统的tps中的最小值；将所述最下游的业务系统的拥塞窗口值确定为不大于所述最小值。

基于此，本实施例针对最下游业务系统之外的业务系统，通过与拥塞中控的交互获知下游业务系统的tps，进而得到下游业务系统可提供的资源；然后，将其与本业务系统需求的资源进行对比，进而决策出本业务系统的拥塞窗口；或者，针对最下游业务系统，通过与拥塞中控的交互获知上游业务系统需求的资源；然后，将其与本业务系统可提供的资源进行对比，进而决策出本业务系统的拥塞窗口。由此可在确保本业务系统内部的资源最优诉求的基础上，实现与其他业务系统之间的全局资源协调，实现全链路的最高容量输出。

另外，对于上述装置实施方式而言，由于其与方法实施方式基本相似，所以描述的比较简单，相关之处参见方法实施方式的部分说明即可。应当注意的是，在本说明书的装置的各个部件中，根据其要实现的功能而对其中的部件进行了逻辑划分，但是，本说明书不受限于此，可以根据需要对各个部件进行重新划分或者组合。

图15为本说明书一实施例提供的一种电子设备的结构示意图，参见图15，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成拥塞控制装置。当然，除了软件实现方式之外，本说明书并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

网络接口、处理器和存储器可以通过总线系统相互连接。总线可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器可能包含高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器。

处理器，用于执行所述存储器存放的程序，并具体执行：

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在上下游依赖关系；

基于所述多个业务系统的tps和所述上下游关系，分别为各业务系统配置拥塞窗口。

或者，

确定多个业务系统的系统吞吐量tps，所述多个业务系统在业务流程上存在的上下游依赖关系；

基于所述上下游关系，将所述多个业务系统中的下游业务系统的tps发送给上游业务系统，供上游业务系统决策所述上游业务系统的拥塞窗口。

上述如本说明书图11-12所示实施例揭示的拥塞控制装置或管理者(master)节点执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本说明书实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

拥塞控制装置还可执行图2-7的方法，并实现管理者节点执行的方法。

基于相同的发明创造，本说明书实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行图2-7对应的实施例提供的拥塞控制方法。

图16为本说明书一实施例提供的一种电子设备的结构示意图，参见图16，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成拥塞控制装置。当然，除了软件实现方式之外，本说明书并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

网络接口、处理器和存储器可以通过总线系统相互连接。总线可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图16中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器可能包含高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器。

处理器，用于执行所述存储器存放的程序，并具体执行：

上游业务系统接收拥塞中控发送的下游业务系统的tps；

基于所述下游业务系统的tps，决策所述上游业务系统的拥塞窗口；

或者，

最下游的业务系统接收拥塞中控发送的拥塞窗口值，所述拥塞窗口值为所述最下游的业务系统相邻的上游业务系统决策出的拥塞窗口；

基于所述拥塞窗口值和所述最下游的业务系统的tps，决策所述最下游的业务系统的拥塞窗口。

上述如本说明书图13-14所示实施例揭示的拥塞控制装置或管理者(master)节点执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field－programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本说明书实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

拥塞控制装置还可执行图8-9的方法，并实现管理者节点执行的方法。

基于相同的发明创造，本说明书实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行图8-9对应的实施例提供的拥塞控制方法。

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域内的技术人员应明白，本说明书的实施例可提供为方法、系统、或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。