CN112965823A - 调用请求的控制方法、装置、电子设备和存储介质 - Google Patents

Abstract

公开了一种调用请求的控制方法，涉及云服务或云计算技术领域，具体涉及远程服务调用。该方法包括：确定第一时段内接收到的调用请求的数量和调用请求的重试次数；基于调用请求的数量和调用请求的重试次数，确定熔断系数和重试次数预算；以及根据熔断系数和重试次数预算，对与第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。还公开了一种调用请求的控制装置、电子设备和存储介质。

Description

调用请求的控制方法、装置、电子设备和存储介质

技术领域

本公开涉及云服务或云计算技术领域，具体涉及远程服务调用，尤其涉及一种调用请求的控制方法、装置、电子设备和存储介质。

背景技术

在云服务框架中，可以采用远程方法调用RPC(Remote Procedure Call)技术来实现多个服务实体之间的通信。RPC允许一台机器上的服务通过网络协议调用另一台机器上的服务。网络协议可以是HTTP协议或其他自定义的协议。服务的稳定性会受到机器之间的流量链路的影响。

发明内容

本公开提供了一种调用请求的控制方法、装置、电子设备和存储介质。

根据本公开的一方面，提供了一种调用请求的控制方法，包括：

确定第一时段内接收到的调用请求的数量和调用请求的重试次数；

基于所述调用请求的数量和所述调用请求的重试次数，确定熔断系数和重试次数预算；以及

根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。

根据本公开的另一方面，提供了一种调用请求的控制装置，包括：

第一确定模块，配置为确定第一时段内接收到的调用请求的数量和调用请求的重试次数；

第二确定模块，配置为基于所述调用请求的数量和所述调用请求的重试次数，确定熔断系数和重试次数预算；以及

重试控制模块，配置为根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行上述方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现上述方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开实施例的NPC应用场景的示意图；

图2是根据本公开实施例的调用请求的控制方法的流程图；

图3是根据本公开实施例的滑动的时间窗口的示例；

图4是根据本公开实施例的对调用请求的重试进行控制的示例过程；

图5是根据本公开实施例的环形缓冲区的示例；

图6是根据本公开实施例的调用请求的控制装置的框图；

图7是用来实现本公开实施例的调用请求的控制方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

RPC允许一台机器上的服务通过网络协议调用另一台机器上的服务。调用方可以被称为客户端，被调用方可以被称为服务器。图1是根据本公开实施例的NPC应用场景的示意图。如图1所示，设备101可以作为调用方，即客户端。设备102和103可以作为被调用方，即服务器。在图1中，带箭头的虚线表示设备之间的调用过程。如图1所示，设备101向设备102发起RPC请求，以对设备102上的服务进行调用。设备102收到请求后，根据业务需求通常会调用其它外部服务或存储，并进行一系列的处理，最终将响应返回给设备101。例如，设备102在对调用请求进行处理的过程中，还可以向设备103发起RPC请求，以对设备103上的服务进行调用，从而通过多次RPC操作共同实现对设备101所发起的RPC请求的响应。一般的，设备102可以称为设备101的下游服务器，设备103可以称为设备102的下游服务器。容易理解，调用方和被调用方可以相互转换。例如，设备102相对于设备101是被调用方，相对于设备103是调用方。此外，在如图1所示的应用场景中，设备101、102和103可以是能够提供相应服务的任何电子设备，本公开实施例对此不做限定。

在客户端处通常会设置一个超时时间，在发起RPC请求之后，在超时时间内等待服务器的响应。如果服务器在规定时间内返回相应结果，则调用成功，如果服务器返回失败的响应(在响应中包含有相应的错误码)，或者在超时时间内没有返回响应，则调用失败。在分布式环境下，服务器的服务通常有多个服务实例，由于机器混布其它服务以及机器性能参数的差异，造成每个服务实例可能具有不同的处理能力。例如，各个服务实例的吞吐量可能并不相同。对于在线服务来说，服务的稳定性受复杂的线上环境影响，因此，不可避免的出现客户端调用服务器的服务出现失败的情况。当客户端对服务器的一次RPC请求失败时，为了保证流量链路的可用性，可以对RPC请求进行重试，即由客户端再次发起RPC请求。这种重试策略可能会导致服务雪崩和重试风暴的问题。

服务雪崩的典型场景如下：服务器的部分服务实例由于内部资源(例如CPU或者内存)不足或吞吐不足出现故障时，无法及时响应客户端的RPC请求。客户端发现这些请求出现超时后，会进行重试，故障实例接收到的请求越多，则重试的流量越大，这些重试请求又放大了服务器的正常服务实例接收到的流量。当这些流量超过了服务器的正常服务实例的吞吐时，这些实例也会越来越慢并由于吞吐不足变成故障实例，最终导致服务器整体容量不足而服务崩溃。

重试风暴的典型场景如下：某个RPC请求的调用链路为多级调用，例如，如图1中所示的设备101->设备102->设备103的调用过程。如果设备103的容量有限，则设备102发往设备103的部分RPC请求会出现超时，因此，设备102在达到最大重试次数之前会对设备103发起重试。而在设备102->设备103的重试请求得到回复之前，如果设备101->设备102的请求超时了，则设备101由于重试机制会对设备102进行重试，而设备101对设备102的重试又加大了设备102发往设备103的流量。这一系列的重试加大了整条链路上的流量，这些流量会对设备102和设备103的容量提出挑战，如果服务容量不足很容易引起整条流量链路上的服务崩溃。

本公开的实施例提出了一种对RPC请求的重试进行控制的方法，以避免重试策略可能会导致的服务雪崩和重试风暴。图2是根据本公开实施例的调用请求的控制方法200的流程图，该调用请求的控制方法200可以在客户端上执行。如图2所示，根据本公开实施例的调用请求的控制方法200包括以下步骤：

在步骤S210中，确定第一时段内接收到的调用请求的数量和调用请求的重试次数。

在步骤S220中，基于调用请求的数量和调用请求的重试次数，确定熔断系数和重试次数预算。

在步骤S230中，根据熔断系数和重试次数预算，对与第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。

在本公开的实施例中，第一时段是具有预设时长的一个时间区间。根据实施例，第一时段可以根据下游服务器的流量情况进行确定。对于网络服务，在整体上表现出比较稳定的流量状态，因此，可以根据针对下游服务器的流量情况进行监控的历史数据，确定第一时段的时长。确定第一时段的目的是获取对整体流量进行评估的样本，即划定用于统计总流量的范围。

在本公开的实施例中，调用请求的数量指代在客户端处接收到的调用请求的总数量。根据实施例，所述接收到的调用请求包括但不限于：来自相同的发起RPC请求的对象针对不同服务的调用请求、来自相同的发起RPC请求的对象针对相同服务的多次不同的调用请求和来自不同的发起RPC请求的对象针对相同服务的调用请求等。上述各种类型的调用请求彼此之间相互独立的进行计数。在本公开的实施例中，调用请求的重试次数是指针对每个调用请求的重试次数的和。

在本公开的实施例中，通过基于调用请求的数量和调用请求的重试次数确定的熔断系数来评估第一时段内流量的整体情况。根据实施例，熔断系数被定义为第一时段内调用请求的重试次数与调用请求的数量之比，即通过熔断系数，将第一时段内的调用请求的重试次数控制在调用请求的数量的一定范围内，由此保证第一时段内的整体流量不超过允许的最大流量。

在本公开的实施例中，通过基于调用请求的数量和调用请求的重试次数确定的重试次数预算来抑制在第一时段内出现瞬时的流量尖峰。根据实施例，重试次数预算被定义为第一时段内的请求频率(即单位时间内的调用请求的数量)与重试预算比例之积。根据实施例，重试预算比例是根据下游服务器的流量情况预先确定的参数，用于将较短时段内的调用请求的重试次数控制在允许的范围内，以防止在该较短时段内出现较大的流量，从而保证在第一时段内不出现瞬时流量尖峰。

在本公开的实施例中，根据第一时段内调用请求的数量和调用请求的重试次数的统计结果，确定熔断系数和重试次数预算，并利于熔断系数和重试次数预算对接下来的第二时段内的调用请求的重试进行控制，由此实现对重试流量进行控制的目的。根据实施例，第二时段与第一时段在时间上连续，是一段持续时间较短的时间区间，用于采样得到表征瞬时流量状态的样本。

集中的重试流量超过了服务容量导致整体服务不可用是导致服务雪崩和重试风暴的主要问题。如果短时间内连续出现N次访问失败，那么这段时间内重试流量就会被放大，对下游服务器造成较大压力。

根据本公开的实施例，提供了一种RPC的动态重试框架，通过对当前一段时间内的调用请求的数量和调用请求的重试次数进行统计，并根据统计结果确定评估系数，即熔断系数和重试次数预算，来对未来时段内的流量进行控制，可以避免重试流量超出下游服务器的流量范围，并防止出现瞬时流量尖峰，增加了RPC调用的稳定性，提高了基于RPC进行在线交互的服务的质量。

在一些对时间延迟比较敏感的场景中，例如，在搜索或推荐场景中，当重试流量在短时间内发生集中时，不能通过增加重试之间的退避时间来避免服务雪崩和重试风暴，让两次重试之间的等待时间较大会导致服务的延迟，对用户体验造成不利影响。因此，本公开的实施例特别适用于对服务的实时性要求较高的场景中。

在本公开的实施例中，通过将第一时段和第二时段随时间进行推移来实现对调用请求的重试流量的监控。根据实施例，第一时段可以包括多个子时段，且每个子时段的持续时间与第二时段的持续时间相同。根据实施例，在每个定时时间等于第二时段的持续时间的时刻，将第二时段包含到第一时段中，并从第一时段中删除与第二时段间隔时间最大的一个子时段。根据实施例，可以利用滑动的时间窗口来实现上述定时过程。

图3是根据本公开实施例的滑动的时间窗口的示例。如图3所示，时间窗口301的时间范围为第一时段的时长。时间窗口301包括多个较小的时间间隔302，该时间间隔302对应于第一时段的每个子时段。如图3所示，各时间间隔302具有相同的时间范围，且该时间范围远小于时间窗口301的时间范围。例如，时间窗口301的时间范围确定为10秒，则时间间隔302的时间范围可以确定为1秒，即每个时间窗口301被划分为10个时间间隔302。通过时间窗口301获得一段时间内的流量样本，通过时间间隔302获得瞬时流量样本。

根据实施例，时间窗口301可以随时间的流逝进行滑动，每次平移一个时间间隔。如图3所示，t₀表示开始对流量进行监控的初始时刻，时间窗口301在每个定时时刻滑动。例如，经过一个时间间隔的持续时间t，当前时刻变为t₀+t，时间窗口301滑动平移，将一个持续时间等于时间间隔302的时段(即第二时段)包含到时间窗口301中，作为时间窗口301的一个时间间隔。同时，将距当前时刻最远的一个时间间隔，例如时间间隔302’，从时间窗口301中移除。

在本公开的实施例中，在确定第一时段内接收到的调用请求的数量和调用请求的重试次数时，可以在每个子时段内对，对在子时段内接收到的调用请求的数量和调用请求的重试次数进行计数，并基于每个子时段内的计数结果来确定第一时段内接收到的调用请求的数量和调用请求的重试次数。

如图3所示，实心原点303表示进行的重试，对应于相邻时刻的两个时间窗口301仅有两个时间间隔302中的数据不同，其余的时间间隔302相互重合。因此，可以在每个时间间隔302内对接收到的调用请求的数量和调用请求的重试次数进行统计，并通过调整未重合的时间间隔302中的统计结果来得到时间窗口301内的总的调用请求的数量和调用请求的重试次数。

在本公开的实施例中，还可以通过配置调用请求的错误码与重试次数来调整调用请求的重试。根据实施例，在第二时段内，在接收到调用请求之后，对调用请求进行执行，如果该调用请求执行失败，则确定与该执行失败有关的错误码，并根据指示调用请求执行失败的错误码，确定能够对调用请求进行重试的初始重试次数。在本公开的实施例中，错误码可以根据调用请求的优先级进行配置，初始重试次数可以根据下游服务器能够提供的流量范围进行配置。

在本公开的实施例中，在根据熔断系数和重试次数预算，对与第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制之前，先对错误码和初始重试次数进行判断。在已经执行的调用请求的重试次数小于初始重试次数的情况下，根据熔断系数和重试次数预算，对与第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制；在已经执行的调用请求的重试次数大于或等于初始重试次数的情况下，不允许对调用请求进行重试。

在本公开的实施例中，根据熔断系数和重试次数预算，对与第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制可以包括：将熔断系数与熔断阈值进行比较，在熔断系数小于熔断阈值的情况下，将第二时段内已经执行的调用请求的重试的次数与重试次数预算进行比较，在已经执行的调用请求的重试的次数小于重试次数预算的情况下，允许对接收到的调用请求进行重试。在熔断系数大于或等于熔断阈值的情况下，或在已经执行的调用请求的重试的次数大于或等于重试次数预算的情况下，不允许对接收到的调用请求进行重试。

根据实施例，错误码可以由用户事先配置。具体的，用户可以注册<error code,max_retry>到重试框架中。error code可以是例如RPC错误码或者http状态码等。max_retry表示该与error code对应的本次RPC允许的重试次数，重试次数可以根据下游服务器所给出的流量范围来确定。因为在某些应用场景中，服务器由于内部逻辑期望出现某些错误时上游可以进行更多的重试，这类重试可能不会对容量造成压力，而在另外一些场景中，服务器可能并不希望上游进行任何重试。因此，通过注册错误码和设置对应的重试次数，可以提供一种灵活的重试策略，方便业务根据自身的特点自行选择。

图4是根据本公开实施例的对调用请求的重试进行控制的示例过程。如图4所示，在步骤S410中，执行接收到的RPC请求并接收响应。在步骤S420中，判断RPC请求是否执行失败。如果判断结果为执行成功，则无需进行重试，进行到步骤S480。如果判断结果为执行失败，则需要进行重试，进行到步骤S430。在步骤S430中，判断与执行失败的调用请求有关的错误码是否被命中。如果判断结果为未命中，则无需进行重试，进行到步骤S480。如果判断结果为命中，则需要进行重试，进行到步骤S440。在步骤S440中，判断针对该执行失败的调用请求的重试次数是否达到初始重试次数。如果判断结果为达到初始重试次数，则不能再对调用请求进行重试，进行到步骤S480。如果判断结果为未达到初始重试次数，则可以继续对调用请求进行重试，进行到步骤S450。在步骤S450中，判断滑动窗口的状态。如果滑动窗口处于熔断状态，则说明当滑动窗口所覆盖的时段内总的重试次数已经超出设定的范围，不再允许进行重试，进行到步骤S480。如果滑动窗口未处于熔断状态，则允许进行重试，进行到步骤S460。在步骤S460中，判断已经执行的重试次数是否达到重试次数预算。如果判断已经达到重试次数预算，则说明当前第二时段中已经执行了足够多的重试，再执行重试有可能导致流量尖峰出现，因此不再允许进行重试，进行到步骤S480。如果判断未达到重试次数预算，则允许进行重试，进行到步骤S470，执行调用请求的重试，并在步骤S490中，重新统计并更新请求书和重试次数，例如，在执行重试之后将重试次数加1。

现有技术中，一般通过设置一个全局的重试次数上限来限制一段时间内的重试次数，当该段时间内的重试次数超过重试次数上限后则不再允许重试。但对于有些特征的在线服务，例如搜索和推荐类服务，流量具有明显的高峰和低谷特征，简单的重试次数上限无法根据流量的波动而变化，存在重试次数上限选择困难的问题。

根据本公开的实施例，不仅限制单次RPC请求的重试次数，还基于时间窗口和时间间隔进行流量统计，为重试添加熔断和预算机制，为不同流量提供不同的预算来适配流量变化。通过配置错误码，可以提高重试的成功率，仅对命中配置错误码的RPC请求进行重试来节省重试预算。通过添加熔断和预算机制，可以缓解重试次数上限选择困难，并可以避免流量过大以及防止瞬时流量尖峰，可以在RPC请求失败时，尽可能地进行重试来保证可用性，避免引起服务雪崩和重试风暴。

在具体的实施例中，可以使用环形缓冲区来实现时间窗口及时间窗口的滑动。图5是根据本公开实施例的环形缓冲区的示例。如图5所示，将整个时间窗口的相关数据存储在环形缓冲区501中。环形缓冲区501中的Buc₀，……，Buc_i，……Buc_N是用于维护时间窗口中的各时间间隔的相关数据的存储区域。相关数据包括用户配置的熔断阈值WThreshold和时间窗口的熔断状态state。熔断阈值WThreshold用于设置整个时间窗口内允许重试的比例。例如，如果将熔断阈值WThreshold设置为windowThreshold＝0.3，则表示在该时间窗口内允许30％的重试比例。时间窗口的熔断状态state可以根据熔断系数与熔断阈值的比较结果进行设置。例如，如果熔断系数小于熔断阈值，则将state设置为0，即时间窗口未熔断。如果熔断系数大于或等于熔断阈值，则将state设置为1，即时间窗口熔断。如果时间窗口的状态为熔断状态，则在下一个第二时段内，不再对任何调用请求进行重试。熔断机制可以用于控制时间窗口内的重试比例，防止时间窗口内重试过多对下游造成压力。

相关数据还包括在第二时段内接收到的调用请求的数量req和已经在该第二时段内执行的重试次数retry，这两个数据可以通过对接收到的调用请求的数量和执行的重试次数进行计数进行实时更新。相关数据还包括时间窗口内的调用请求的数量totalReq，调用请求的重试次数totalRetry，以及单位时间内的调用请求的数量qps。该调用请求的数量qps根据调用请求的数量totalReq和时间窗口的时间范围T_W计算得到。具体的，qps＝totalReq/T_W。相关数据还包括用户配置的重试预算比例BThreshold和当前的第二时段内允许的重试次数预算retryLimit。重试预算比例BThreshold表示第二时段内，即在一个Buc内最多允许的重试运算比例。重试次数预算retryLimit根据单位时间内的调用请求的数量qps和重试预算比例BThreshold的乘积来确定，即retryLimit＝qps*BThreshold。

根据实施例，上述相关数据分别存储在对应的Buc中。例如，将req0、retry0、retryLimit0、state、qps等存储在Buc₀中，将req1、retry1、retryLimit1、state、qps等存储在Buc₁中等。时间窗口内的调用请求的数量totalReq，调用请求的重试次数totalRetry，单位时间内的调用请求的数量qps以及重试次数预算retryLimit需要在时间窗口滑动至下一个第二时段时进行更新。其中，调用请求的数量totalReq根据totalReq＝totalReq+req0-reqN进行更新。调用请求的重试次数totalRetry根据totalRetry＝totalRetry+retry0-retryN进行更新。qps根据qps＝totalReq/T_W进行更新。retryLimit根据retryLimit＝qps*BThreshold进行更新。

此外，还需要在定时器502每次触发的时刻更新游标cur，由此实现时间窗口的整体平移。游标cur表示当前处于哪个Buc。可以根据cur＝(cur+1)％N进行更新，N表示环形缓冲区501中所包含的Buc的数量。

如图5所示，可以利用定时器502来实现Buc之间的跳转切换。将定时器502的周期确定为第二时段的时长。定时器502每次触发的时刻，对环形缓冲区501中对应的存储区域中的数据进行更新。当前客户端从Buc申请重试次数预算时，会判断当前Buc内重试次数retry0是否大于重试次数预算retryLimit，当重试次数retry0小于重试次数预算retryLimit时则允许进行重试，否则不允许进行重试。

根据本公开的实施例，既可以确保整个时间窗口不处于熔断状态，也可以使大部分Buc内的重试次数较少，避免重试集中在少数几个Buc而造成瞬时的重试流量大增。即根据本公开的实施例，可以平滑时间窗口内的重试流量，防止出现瞬时的流量尖峰。

根据本公开的实施例，针对流量有高峰和低谷的波动特点，通过计算出流量的qps数据来分配相应的局部重试次数预算，让重试可以动态地适配流量的波动，解决简单全局重试上限带来的不适配问题。

本公开的实施例还提供了一种调用请求的控制装置。

图6是根据本公开实施例的调用请求的控制装置600的框图。如图6所示，该调用请求的控制装置600包括第一确定模块610、第二确定模块620和重试控制模块630。

根据实施例，第一确定模块610被配置为确定第一时段内接收到的调用请求的数量和调用请求的重试次数。第二确定模块620被配置为基于调用请求的数量和调用请求的重试次数，确定熔断系数和重试次数预算。重试控制模块630被配置为根据熔断系数和重试次数预算，对与第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。

以上各功能模块的具体操作可以参考前述实施例中的调用请求的控制方法200的操作步骤来获取，此处不再赘述。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7是用来实现本公开实施例的调用请求的控制方法的电子设备700的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，设备700包括计算单元701，其可以根据存储在只读存储器(ROM)702中的计算机程序或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

设备700中的多个部件连接至I/O接口705，包括：输入单元707，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如调用请求的控制方法。例如，在一些实施例中，调用请求的控制方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由计算单元701执行时，可以执行上文描述的调用请求的控制方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行调用请求的控制方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (13)

1.一种调用请求的控制方法，包括：

确定第一时段内接收到的调用请求的数量和调用请求的重试次数；

基于所述调用请求的数量和所述调用请求的重试次数，确定熔断系数和重试次数预算；以及

根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。

2.根据权利要求1所述的方法，所述第一时段包括多个子时段，且每个子时段的持续时间与所述第二时段的持续时间相同，所述方法还包括：

在每个定时时间等于所述第二时段的持续时间的时刻，将所述第二时段包含到所述第一时段中，并从所述第一时段中删除与所述第二时段间隔时间最大的一个子时段。

3.根据权利要求2所述的方法，其中，所述确定第一时段内接收到的调用请求的数量和调用请求的重试次数包括：

在每个子时段内对，对在子时段内接收到的调用请求的数量和调用请求的重试次数进行计数；以及

基于每个子时段内的计数结果来确定第一时段内接收到的调用请求的数量和调用请求的重试次数。

4.根据权利要求1至3中任一项所述的方法，其中，所述基于所述调用请求的数量和所述调用请求的重试次数，确定熔断系数和重试次数预算包括：

将所述调用请求的重试次数与所述调用请求的数量之比确定为所述熔断系数。

5.根据权利要求1至4中任一项所述的方法，其中，所述基于所述调用请求的数量和所述调用请求的重试次数，确定熔断系数和重试次数预算还包括：

根据所述调用请求的数量与所述第一时段的持续时间，确定请求频率；以及

将所述请求频率与针对第一时段的每个子时段预设的重试预算比例之积确定为所述重试次数预算。

6.根据权利要求1至5中任一项所述的方法，其中，所述根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制包括：

将所述熔断系数与熔断阈值进行比较；

在所述熔断系数小于所述熔断阈值的情况下，将所述第二时段内已经执行的调用请求的重试的次数与所述重试次数预算进行比较；以及

在所述已经执行的调用请求的重试的次数小于所述重试次数预算的情况下，允许对接收到的调用请求进行重试。

7.根据权利要求6所述的方法，其中，所述根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制还包括：

在所述熔断系数大于或等于所述熔断阈值的情况下，或在所述已经执行的调用请求的重试的次数大于或等于所述重试次数预算的情况下，不允许对接收到的调用请求进行重试。

8.根据权利要求1所述的方法，还包括：

执行第二时段内接收到的调用请求；以及

根据指示所述调用请求执行失败的错误码，确定能够对所述调用请求进行重试的初始重试次数。

9.根据权利要求8所述的方法，其中，所述根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制包括：

在已经执行的所述调用请求的重试次数小于所述初始重试次数的情况下，根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制；以及

在已经执行的所述调用请求的重试次数大于或等于所述初始重试次数的情况下，不允许对所述调用请求进行重试。

10.一种调用请求的控制装置，包括：

第一确定模块，配置为确定第一时段内接收到的调用请求的数量和调用请求的重试次数；

第二确定模块，配置为基于所述调用请求的数量和所述调用请求的重试次数，确定熔断系数和重试次数预算；以及

重试控制模块，配置为根据所述熔断系数和所述重试次数预算，对与所述第一时段在时间上连续的第二时段内接收到的调用请求的重试进行控制。

11.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-9中任一项所述的方法。

12.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-9中任一项所述的方法。

13.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-9中任一项所述的方法。

Images