CN118233401A - 一种服务网格限流方法及相关装置 - Google Patents

Abstract

本申请提供了一种服务网格限流方法及相关装置，所述方法应用于具有上下游对应关系的上游容器组Pod，所述方法包括：在确定上游容器组Pod发生过载的情况下，确定上游容器组Pod对应的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；根据多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将多个第一业务请求中除部分业务请求之外的剩余部分业务请求丢弃。本申请综合考虑了下游Pod的业务等级和真实过载情况，选择综合等级低的业务请求丢弃，从而保证系统的稳定性和业务的稳定性，提高服务质量。

Description

一种服务网格限流方法及相关装置

技术领域

本申请涉及云计算领域，尤其涉及一种服务网格限流方法及相关装置。

背景技术

随着云技术的发展，越来越多的应用程序通过微服务的形式实现，由于微服务众多，微服务之间的调用关系复杂，当后台系统在面临大量业务请求时，容易造成过载的情况，这就需要对业务请求进行限流，避免系统崩溃，又要尽量保持业务稳定。

常用的限流方法是，基于业务请求速率的阈值进行限流控制，即，计算一个时间窗口内的业务请求量，当一个时间窗口内的业务请求量超过设定的阈值的情况下，不再接收业务请求或者丢弃新的业务请求，直至当前时间窗口结束。上述限流方法，采用一刀切的方式进行限流，没有关注业务等级，容易导致业务受损。另外，有可能存在这种情况：上游Pod中的业务请求量过载，但是该上游Pod对应的某个下游Pod可能处于空闲状态，这种情况下，上游Pod采用一刀切的方式丢弃新的业务请求是不合理的。

发明内容

本申请提供了一种服务网格限流方法及相关装置，采用本申请所述的方法，上游节点能够根据下游节点的综合情况来进行限流，提高业务服务质量。

第一方面，本申请提供了一种服务网格限流方法，所述方法应用于具有上下游对应关系的上游容器组Pod，每个容器组Pod中部署了边车容器与应用程序容器，所述应用程序容器用于处理所述业务请求，所述边车容器用于对业务请求的流量进行管控，所述方法包括：

在当前时间窗口下：

在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第一业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级，所述下游容器组Pod的综合等级是基于预先设置的所述下游容器组Pod的静态业务等级和所述下游容器组Pod实际处理业务请求的能力确定的；

根据所述多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将所述多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将所述多个第一业务请求中除所述部分业务请求之外的剩余部分业务请求丢弃。

可以看到，上游容器组Pod根据下游容器组Pod的综合等级，确定将哪些第一业务请求丢弃，从而达到限流的目的，其中各个下游容器组Pod的综合等级并非是根据单一因素确定的，而是根据各个下游容器组Pod的静态业务等级和实际处理业务请求的能力确定的。采用本申请所述的限流方法来确定丢弃的部分请求是哪些，需要处理的部分请求是哪些，并非通过单一因素确定或者一刀切的方式，提高了业务服务的质量。

基于第一方面，在可能的实现方式中，所述下游容器组Pod实际处理业务请求的能力包括所述下游容器组Pod的业务请求丢弃率阈值和所述下游容器组Pod的过载率中的一项或多项，所述下游容器组Pod的过载率与丢弃率差值成正相关，所述丢弃率差值指的是所述下游容器组Pod的业务请求丢弃率与所述业务请求丢弃率阈值的差值。

业务请求丢弃率阈值指的是预先设置的业务请求丢弃率的界限，可以理解为允许丢弃的业务请求的数量是多少，或者可以理解为该下游容器组Pod对丢弃的业务请求的容忍度是多少，因此预先设置的业务请求率阈值可以反映该下游容器组Pod实际处理业务请求的能力。过载率可以体现该下游容器组Pod的实际处理业务请求的能力，过载率与该容器组Pod实际业务请求丢弃率和预设的业务请求丢弃率阈值的差值成正相关。

基于第一方面，在可能的实现方式中，所述下游容器组Pod的综合等级与所述下游容器组Pod的静态业务等级成正相关；所述下游容器组Pod的综合等级与所述下游容器组Pod的业务请求丢弃率阈值成负相关；所述下游容器组Pod的综合等级与所述下游容器组Pod的过载率成负相关。

可以理解，静态业务等级越低，该容器组Pod的综合等级越低；预设的业务请求丢弃率阈值越大，表示该容器组Pod允许丢弃的业务请求的数量越多，则该容器组Pod的综合等级越低，预设的业务请求丢弃率阈值越小，表示该容器组Pod允许丢弃的业务请求的数量越少，则该容器组Pod的综合等级越高；实际业务请求丢弃率和预设的业务请求丢弃率阈值的差值越大，表示该容器组Pod过载程度越高，则该容器组Pod的综合等级越低。

基于第一方面，在可能的实现方式中，所述方法还包括：获取当前时间窗口下所述上游容器组Pod的资源使用率；根据所述上游容器组Pod的资源使用率，确定当前窗口下所述上游容器组Pod是否发生过载。

基于第一方面，在可能的实现方式中，所述上游容器组Pod的资源使用率包括所述上游容器组Pod中处理器的使用率和/或内存的使用率；所述根据所述上游容器组Pod的资源使用率，确定当前窗口下所述上游容器组Pod是否发生过载，包括：当所述处理器的使用率大于设置的处理器使用率过载阈值，和/或当所述内存的使用率大于设置的内存使用率过载阈值时，确定当前窗口下所述上游容器组Pod发生过载；否则，确定当前窗口下所述上游容器组Pod未发生过载。

基于第一方面，在可能的实现方式中，所述根据所述多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将所述多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将所述多个第一业务请求中除所述部分业务请求之外的剩余部分业务请求丢弃，包括：

从所述多个第一业务请求所需调用的各个下游容器组Pod中，确定出综合等级最低的下游容器组Pod，作为第一目标容器组Pod；

将所述多个第一业务请求中用于指示调用综合等级高于所述第一目标容器组Pod的下游容器组Pod的业务请求下发至对应的下游容器组Pod，将剩余部分业务请求丢弃。

可以理解，将调用综合等级最低的下游容器组Pod的第一业务请求丢弃，下游容器组Pod的综合等级最低包括以下情况中的任意一种或多种：下游容器组Pod的静态业务等级比较低；下游容器组Pod预设的业务请求丢弃率阈值比较大(或者称，下游容器组Pod允许丢弃的业务请求的数量较多)；下游容器组Pod的过载率(过载程度)较高。

基于第一方面，在可能的实现方式中，所述方法还包括：

在所述当前时间窗口之后的第一个时间窗口下：

在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第二业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从所述多个第二业务请求所需调用的各个下游容器组Pod中，确定出综合等级比所述第一目标容器组Pod高的下游容器组Pod，作为第一集合；

确定出所述第一集合中综合等级最低的下游容器组Pod，作为第二目标容器组pod；

将所述多个第二业务请求中用于指示调用综合等级高于所述第二目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

可以看到，当前时间窗口时上游容器组Pod过载的情况下，丢弃的是调用综合等级最低的下游容器组Pod的业务请求，在当前时间窗口自后的第一个时间窗口下上游容器组Pod过载的情况下，丢弃的是调用比上一个时间窗口中综合等级最低的下游容器组Pod高的容器组Pod的业务请求，因此，当某个上游容器组Pod连续时间窗口发生过载的情况下，丢弃的业务请求所调用的下游容器组Pod的综合等级越来越高，以尽快消除当前上游容器组Pod和/或下游容器组Pod的过载状态。

基于第一方面，在可能的实现方式中，所述方法还包括：

在所述当前时间窗口之后的第二个时间窗口下：

若所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第三业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从所述多个第三业务请求所需调用的各个下游容器组Pod中，确定出综合等级比所述第二目标容器组Pod高的下游容器组Pod，作为第二集合；

确定出所述第二集合中综合等级最低的下游容器组Pod，作为第三目标容器组pod；

将所述多个第三业务请求中用于指示调用综合等级高于所述第三目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

可以看到，当某个上游容器组Pod连续时间窗口发生过载的情况下，丢弃的业务请求所调用的下游容器组Pod的综合等级越来越高，目的是尽快消除当前上游容器组Pod和/或下游容器组Pod的过载状态。

基于第一方面，在可能的实现方式中，所述下游容器组Pod的综合等级通过数值表示。

可以理解，综合等级可以通过数值来表示，在一种示例中，数值越大，综合等级越高，在一种示例中，数值越小，综合等级越高。

第二方面，本申请提供了一种服务网格限流装置，所述装置包括具有上下游对应关系的上游容器组Pod，每个容器组Pod中部署了边车容器与应用程序容器，所述应用程序容器用于处理所述业务请求，所述边车容器用于对业务请求的流量进行管控，所述装置包括：

在当前时间窗口下：

综合等级确定模块，用于在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第一业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级，所述下游容器组Pod的综合等级是基于预先设置的所述下游容器组Pod的静态业务等级和所述下游容器组Pod实际处理业务请求的能力确定的；

通信模块，用于根据所述多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将所述多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将所述多个第一业务请求中除所述部分业务请求之外的剩余部分业务请求丢弃。

基于第二方面，在可能的实现方式中，所述下游容器组Pod实际处理业务请求的能力包括所述下游容器组Pod的业务请求丢弃率阈值和所述下游容器组Pod的过载率中的一项或多项，所述下游容器组Pod的过载率与丢弃率差值成正相关，所述丢弃率差值指的是所述下游容器组Pod的业务请求丢弃率与所述业务请求丢弃率阈值的差值。

基于第二方面，在可能的实现方式中，所述下游容器组Pod的综合等级与所述下游容器组Pod的静态业务等级成正相关；所述下游容器组Pod的综合等级与所述下游容器组Pod的业务请求丢弃率阈值成负相关；所述下游容器组Pod的综合等级与所述下游容器组Pod的过载率成负相关。

基于第二方面，在可能的实现方式中，获取模块，用于获取当前时间窗口下所述上游容器组Pod的资源使用率；过载确定模块，用于根据所述上游容器组Pod的资源使用率，确定当前窗口下所述上游容器组Pod是否发生过载。

基于第二方面，在可能的实现方式中，所述上游容器组Pod的资源使用率包括所述上游容器组Pod中处理器的使用率和/或内存的使用率；所述过载确定模块用于：当所述处理器的使用率大于设置的处理器使用率过载阈值，和/或当所述内存的使用率大于设置的内存使用率过载阈值时，确定当前窗口下所述上游容器组Pod发生过载；否则，确定当前窗口下所述上游容器组Pod未发生过载。

基于第二方面，在可能的实现方式中，所述综合等级确定模块用于，从所述多个第一业务请求所需调用的各个下游容器组Pod中，确定出综合等级最低的下游容器组Pod，作为第一目标容器组Pod；

所述通信模块用于，将所述多个第一业务请求中用于指示调用综合等级高于所述第一目标容器组Pod的下游容器组Pod的业务请求下发至对应的下游容器组Pod，将剩余部分业务请求丢弃。

基于第二方面，在可能的实现方式中，所述综合等级确定模块用于：

在所述当前时间窗口之后的第一个时间窗口下：

在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第二业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从所述多个第二业务请求所需调用的各个下游容器组Pod中，确定出综合等级比所述第一目标容器组Pod高的下游容器组Pod，作为第一集合；

确定出所述第一集合中综合等级最低的下游容器组Pod，作为第二目标容器组pod；

所述通信模块用于：

将所述多个第二业务请求中用于指示调用综合等级高于所述第二目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

基于第二方面，在可能的实现方式中，所述综合等级确定模块用于：

在所述当前时间窗口之后的第二个时间窗口下：

若所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第三业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从所述多个第三业务请求所需调用的各个下游容器组Pod中，确定出综合等级比所述第二目标容器组Pod高的下游容器组Pod，作为第二集合；

确定出所述第二集合中综合等级最低的下游容器组Pod，作为第三目标容器组pod；

所述通信模块用于：

将所述多个第三业务请求中用于指示调用综合等级高于所述第三目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

基于第二方面，在可能的实现方式中，所述下游容器组Pod的综合等级通过数值表示。

第二方面的各个功能模块用于实现上述第一方面以及第一方面的任意一种可能的实现方式所述的方法。

第三方面，本申请提供了一种计算设备集群，包括至少一台计算设备，所述至少一台计算设备中的每台计算设备包括存储器和处理器，所述至少一台计算设备的处理器用于执行所述至少一台计算设备的存储器中存储的指令，使得所述计算设备集群执行上述第一方面以及第一方面的任意一种可能的实现方式所述的方法。

第四方面，本申请提供了一种包含指令的计算机存储介质，当所述指令在计算设备集群中运行时，使得所述计算设备集群执行上述第一方面以及第一方面的任意一种可能的实现方式所述的方法。

第五方面，本申请提供了一种包含程序指令的计算机程序产品，当所述程序指令在计算设备集群上执行时，所述计算设备集群执行上述第一方面以及第一方面的任意一种可能的实现方式所述的方法。

附图说明

图1为本申请提供的一种系统架构示意图；

图2为本申请提供的一种服务网格限流方法流程示意图；

图3为本申请提供的一种第一限流操作的流程示意图；

图4为本申请提供的一种示例图；

图5为本申请提供的一种服务网格限流装置结构示意图；

图6为本申请提供的一种计算设备的结构示意图；

图7为本申请提供的一种计算设备集群的结构示意图；

图8为本申请提供的又一种计算设备集群的结构示意图。

具体实施方式

在云原生架构中，应用程序通常被设计为多个微服务的分布式集合的形式，其中每个微服务用于执行一些离散的业务功能。服务网格(service mesh)是众多服务之间通信的基础设施层，用于负责描述云原生应用程序的复杂服务拓扑关系，以及各个微服务之间的网络流量控制。

参见图1，图1为本申请提供的一种系统架构示意图。如图1所示，云中可以包括多个服务器节点，一个服务器节点可以是一个虚拟机，也可以是一个物理主机。

一个服务器节点上可以包括一个或多个容器组Pod，Pod是Kubernetes(Kubernetes是谷歌开源的一种容器编排引擎，简称为K8s)为部署、管理、编排容器化应用的基本单位，Pod可以包括一个或多个容器。

在云原生架构中，边车(sidecar)容器和应用程序容器部署在一个Pod中，如图1所示。边车容器用于对网络流量进行管理控制，具体的，边车容器用于对本Pod接收到的各个业务请求进行处理，处理包括限流操作和将相应的业务请求分发至对应的Pod。应用程序容器用于实现微服务的业务功能。可以理解，任一个业务请求都需先经过边车容器，由边车容器对业务请求进行分发。具体的，边车容器用于将业务请求分发给本Pod所在的应用程序容器，以便本Pod所在的应用程序容器对业务请求进行处理，以实现相应的功能；或者，边车容器用于将业务请求分发给其他Pod中的边车容器，其他Pod中的边车容器将接收到业务请求发送给自身Pod中的应用程序容器，以使自身Pod中的应用程序容器对业务请求进行处理，以实现相应的功能。

可以理解，一个应用程序可以包括多个微服务，多个微服务可以在一个或多个应用程序容器中实现，因此，一个应用程序可以在一个或多个应用程序容器中实现。一个应用程序的多个微服务之间可以具有调用关系，不同应用程序之间也可以具有调用关系。服务网格管理平台中规定了各个边车容器的排布形式以及各个微服务之间的调用关系，其中各个微服务之间的调用关系也可称为网络拓扑关系。

可选的，图1所示的系统架构中，还可以包括服务网格管理平台(图1中未示出)，服务网格管理平台用于管理各个边车容器，比如增加或删除边车容器，服务网格管理平台还用于管理各个微服务之间的调用关系、调用频率，比如，单位时间内允许微服务a(对应在Pod a中实现)调用微服务b(对应在Pod b中实现)的次数。

可以理解，若多个微服务之间具有调用关系，则多个微服务所在的多个Pod具有上下游关系。例如，微服务a在Pod a中实现，微服务b在Pod b中实现，微服务a可以调用微服务b，则Pod a与Pod b之间具有上下游对应关系，Pod a为上游，Pod b为下游。

需要说明的是，图1所示的系统中可以包括更多或更少的服务器节点，一个服务器节点可以包括更多或更少的Pod，网络拓扑关系仅仅是一种示例，图1并不构成对本申请的限定。

本申请提供了一种基于业务等级进行限流的方法，通过在应用程序容器内部引入一个限流软件开发工具包(software development kit，SDK)，限流SDK判断接收的业务请求的业务等级和过载情况，选择业务等级高的业务请求进行处理，丢弃业务等级低的业务请求。

但是这种方法，需要在应用程序容器中引入SDK，微服务和SDK相互配合处理业务请求，这种方式属于侵入式容器限流方法。随着云计算的发展，微服务数量增多，微服务之间调用关系复杂，这种侵入式容器限流方法实现起来复杂，业务开发较难。

本申请又提供了一种无侵入式服务网格限流方法，所述方法应用于具有上下游对应关系的上游Pod，具体的，可应用于上游Pod中的边车容器，参见图2，图2为本申请提供的一种服务网格限流方法的流程示意图，所述方法包括但不限于以下内容的描述。

S101、本Pod获取当前时间窗口下本Pod的资源使用率。

本申请所述方法中，本Pod指的是上游Pod。时间窗口指的是预设时长的时间间隔，预设时长可以是一分钟，也可以是一秒钟，还可以是其他预设时长，本申请不做限定。

本Pod的资源使用率包括本Pod的处理器使用率和/或本Pod的内存使用率。本Pod的处理器使用率指的是本Pod已消耗的处理器资源量与本Pod处理器资源总量的比值，本Pod的内存使用率指的是本Pod已占用的内存容量与本Pod内存总容量的比值。其中，在建立各个Pod时，已经为各个Pod分配好了资源容量大小，包括每个Pod的处理器容量大小和内存容量大小。计算本Pod的处理器使用率和本Pod的内存使用率时，可以是在当前时间窗口的某一时刻计算一次，也可以是通过其他方法计算，本申请不做限定。

S102、根据本Pod的资源使用率，确定当前时间窗口下本Pod是否发生过载。

将本Pod的资源使用率与本Pod的过载阈值进行比较，确定当前时间窗口下本Pod是否发生过载。本Pod的过载阈值包括本Pod的处理器使用率过载阈值和/或本Pod的内存使用率过载阈值，本Pod的过载阈值是预先设置好的。

在一种示例中，本Pod的过载阈值包括处理器使用率过载阈值，若本Pod的处理器使用率大于处理器使用率过载阈值，则确定当前时间窗口下本Pod发生过载。

在一种示例中，本Pod的过载阈值包括内存使用率过载阈值，若本Pod的内存使用率大于内存使用率过载阈值，则确定当前时间窗口下本Pod发生过载。

在一种示例中，本Pod的过载阈值包括内存使用率过载阈值和处理器使用率过载阈值，若本Pod的内存使用率大于内存使用率过载阈值且处理器使用率大于处理器使用率过载阈值，则确定当前时间窗口下本Pod发生过载。

S103、在确定当前时间窗口下本Pod发生过载的情况下，执行第一限流操作，丢弃调用综合等级最低的下游Pod的业务请求。

在确定当前时间窗口下本Pod发生过载的情况下，执行第一限流操作，具体的，可以包括但不限于步骤S1031和步骤S1032，如图3所示，图3为本申请提供的第一限流操作的方法流程示意图。

S1031、确定本Pod接收到的多个第一业务请求所需调用的至少一个下游Pod中各个下游Pod的综合等级。

当前时间窗口下，本Pod接收到多个第一业务请求，Pod根据第一业务请求可以识别出每个请求对应的是哪个微服务，可以理解为，Pod根据第一业务请求可以识别出每个请求对应需要调用哪个下游Pod。根据多个第一业务请求，首先，可以确定出多个第一业务请求需要调用的一个或多个下游Pod，然后，计算多个第一业务请求需要调用的一个或多个下游Pod的综合等级。其中，各个下游Pod的综合等级是动态变化的，对于任一个下游Pod来说，在不同时间窗口下，每个下游Pod丢弃业务请求的数量不同，每个Pod的综合等级是基于该Pod的静态业务等级和该Pod实际处理业务请求的能力确定的，其中，下游Pod丢弃业务请求的数量多少是实际处理业务请求的能力的一种体现，关于Pod实际处理业务请求的能力的理解在下文中描述，具体参见下文的描述。

例如，参见图4所示的示例图，本Pod为Pod A，Pod A接收到的各个第一业务请求所需调用的下游Pod包括Pod B、Pod C和Pod D，其中，每个Pod对应一个微服务，用于实现某个业务功能。

下面介绍一下如何计算各个下游Pod的综合等级。

对于任一个下游Pod来说，根据该下游容器组Pod的静态业务等级、该下游容器组Pod的业务请求丢弃率阈值、该下游容器组Pod的过载率，可以确定该下游容器组Pod的综合等级。例如，可以根据下游Pod B的静态业务等级、Pod B的业务请求丢弃率阈值和Pod B的过载率，确定Pod B的综合等级。类似的，可以确定Pod C和Pod D的综合等级。其中，各个Pod的静态业务等级是根据各个Pod中微服务实现的业务预先设置的。

分别以图4中的下游Pod B、Pod C为例，解释一下下游Pod的业务请求丢弃率阈值和下游Pod的业务请求丢弃率。

以下游Pod B为例，在某一个时间窗口下，上游Pod A下发给下游Pod B的业务请求数量为x1，但下游Pod B只处理了x1个业务请求中的y1个业务请求，其中y1小于x1，上游PodA接收到下游Pod B返回的y1个业务请求的响应，x1-y1个业务请求被下游Pod B丢弃，因此，上游Pod A可以确定当前时间窗口下下游Pod B的业务请求丢弃率为(x1-y1)/x1。下游PodB的业务请求丢弃率阈值指的是上游Pod A允许下游Pod B丢弃的业务请求的数量与上游Pod A发送给下游Pod B的业务请求总数量的比值。

以下游Pod C为例，在某一个时间窗口下，上游Pod A下发给下游Pod C的业务请求数量为x2，但下游Pod B只处理了x2个业务请求中的y2个业务请求，其中y2小于x2，上游PodA接收到下游Pod B返回的y2个业务请求的响应，x2-y2个业务请求被下游Pod B丢弃，因此，上游Pod A可以确定当前时间窗口下下游Pod B的业务请求丢弃率为(x2-y2)/x2。下游PodB的业务请求丢弃率阈值指的是上游Pod A允许下游Pod B丢弃的业务请求的数量与上游Pod A发送给下游Pod B的业务请求总数量的比值。对于其他下游Pod，业务请求丢弃率和业务请求丢弃率阈值是类似的。

可选的，各个Pod的静态业务等级可以通过数值来表示，例如，可以使用0-100表示静态业务等级的高低，数值越大，表示静态业务等级越低，0表示静态业务等级最高，100表示静态业务等级最低。

可选的，可以根据下游Pod的静态业务等级、下游Pod的业务请求丢弃率阈值和下游Pod的过载率，使用欧几里得距离算法，计算下游Pod的综合等级。例如，使用p表示下游Pod的静态业务等级，其中p的取值范围为[0,100]，L表示下游Pod的业务请求丢弃率阈值，取值范围为[0,1]，f表示过载率，取值范围为[0,100]，其中，

其中，d表示业务请求丢弃率，计算方式为d＝r/s，r表示上游Pod发送过来的业务请求被下游Pod丢弃的数量，s表示上游Pod发送至下游Pod的业务请求的数量。在一种示例中，d可以表示单位时间内的业务请求丢弃率，r表示单位时间内上游Pod发送过来的业务请求被下游Pod丢弃的数量，s表示单位时间内上游Pod发送至下游Pod的业务请求的数量。在一种示例中，d可以表示上一时间窗口下的业务请求丢弃率，r表示上一时间窗口下上游Pod发送过来的业务请求被下游Pod丢弃的数量，s表示上一时间窗口下上游Pod发送至下游Pod的业务请求的数量。

当d小于L时，实际业务请求丢弃率小于业务请求丢弃率阈值，表示该下游Pod中的业务请求未过载，过载率f取值为0；当d大于或等于L时，实际业务请求丢弃率大于或等于业务请求丢弃率阈值，表示该下游Pod中的业务请求已经发生过载或即将发生过载，f取值为100*α，α为缩放因子，α的取值范围是[0,1]，且丢弃率差值越大，α的取值越大，其中，丢弃率差值指的是实际业务请求丢弃率与预设的丢弃率阈值之间的差值。需要说明的是，α具体取值可以根据业务请求过载情况具体设置，比如，当过载较少时，α可以取较小的值，当过载较多时，α可以取较大的值。本申请中过载率的计算方式以及α的取值仅仅是一种示例，在实际应用中，过载率还可以通过其他方式计算，α取值还可以是其他计算方式，本申请不做限定。

利用欧几里得距离算法计算下游Pod的综合等级，下游Pod的综合等级为

也就是计算三维向量(p，L*100，f)距离坐标原点的欧几里得距离。

例如，图4示例中，下游Pod B的静态业务等级p为10，业务请求丢弃率阈值L为20％，业务请求丢弃率d为0，则对应的三维向量为(10,20,0)，则下游Pod B的综合等级为下游Pod C的静态业务等级p为30，业务请求丢弃率阈值L为10％，业务请求丢弃率d为20％，为了便于计算，这里将α取值为1，则对应的三维向量为(30,10,100)，则下游Pod C的综合等级为/>下游Pod D的静态业务等级p为40，业务请求丢弃率阈值L为30％，业务请求丢弃率d为0，则对应的三维向量为(40,30,0)，则下游Pod D的综合等级为/>由此可以得到，上游Pod A的各个下游Pod中，下游Pod B的综合等级最高，下游Pod D的综合等级次之，下游Pod C的综合等级最低。

根据公式(2)分析可知：当L和f一定时，静态业务等级p越大，则表示下游Pod的综合等级的数值越大，则下游Pod的综合等级越低，可以理解，p越大时表示该下游Pod的静态业务等级越低，该Pod中微服务的业务等级越低，则计算获得的综合等级越低；当p和f一定时，L越大，则表示下游Pod的综合等级的数值越大，则下游Pod的综合等级越低，业务请求丢弃率阈值可以理解为对丢弃的业务请求数量的容忍度，业务请求丢弃率阈值L越大，即容忍度越大，则该下游Pod的综合等级越低；当p和L一定时，下游Pod的业务请求丢弃率越大，则过载率f越大，则下游Pod的综合等级越低。

需要说明的是，计算各个Pod的综合等级这个步骤是由本Pod(上游Pod)执行的。其中，各个Pod的静态业务等级在服务网格中是全局共享的，因此本Pod(上游Pod)可以获取到各个下游Pod的静态业务等级，从而计算出各个下游Pod的综合等级。

S1032、根据多个第一业务请求所需调用的各个下游Pod的综合等级，将多个第一业务请求中的部分业务请求丢弃，将剩余部分业务请求下发至对应的下游Pod。

在确定出多个第一业务请求所需调用的各个下游Pod的综合等级后，将多个第一业务请求中指示调用综合等级最低的业务请求丢弃，将其他业务请求下发至对应的下游Pod。例如，在图4示例中，上游Pod A接收的各个业务请求中所需调用的下游Pod包括Pod B、Pod C和Pod D，经计算，Pod C的综合等级最低，所以Pod A将各个业务请求中用于指示调用Pod C的业务请求丢弃掉，将其他业务请求对应发送至Pod B、Pod D。

在一种示例中，经计算，表示Pod B综合等级的数值为22，表示Pod C综合等级的数值为104，表示Pod D综合等级的数值为50，根据数值确定出综合等级最低的是Pod C，因此将Pod A将各个业务请求中用于指示调用Pod C的业务请求丢弃掉，将其他业务请求对应发送至Pod B、Pod D。可以，本申请中，将业务请求丢弃，可以理解为不处理该业务请求。

当前时间窗口下，本Pod发生过载的情况下，通过将部分业务请求丢弃后，本Pod中的业务请求数量减少。

S104、在确定当前时间窗口下本Pod未发生过载的情况下，将多个第一业务请求下发至对应的下游容器组Pod。

在确定当前时间窗口下本Pod未发生过载的情况下，本Pod按照正常情况将多个第一业务请求下发至对应的下游Pod，未丢弃任何业务请求，直至下一个时间窗口来临，再判断下一个时间窗口下本Pod是否发生过载，若发生过载执行步骤S105，若未发生过载，则执行步骤S101。

S105、在当前时间窗口发生过载的情况下，确定当前时间窗口之后的第一个时间窗口本Pod是否发生过载。

在当前时间窗口结束后，进入下一个时间窗口，即当前时间窗口之后的第一个时间窗口，判断当前时间窗口之后的第一个时间窗口下本Pod(上游Pod)是否发生过载。判断方法与上述S101和S102步骤中所述方法类似：1)获取本Pod在当前时间窗口之后的第一个时间窗口下的资源使用率，其中，资源使用率包括处理器使用率和/或内存使用率；2)根据本Pod的资源使用率，确定当前时间窗口之后的第一个时间窗口下本Pod是否发生过载。具体的，可以将本Pod的资源使用率与过载阈值进行比较，确定当前时间窗口之后的第一个时间窗口下本Pod是否发生过载，具体内容可参考上述S101和S102步骤中的描述，为了说明书的简洁，在此不再展开介绍。

S106、在确定当前时间窗口之后的第一个时间窗口下本Pod发生过载的情况下，执行第二限流操作，第二限流操作中丢弃的业务请求所调用的下游Pod的综合等级高于第一限流操作中丢弃的业务请求所调用的下游Pod的综合等级。

在确定当前时间窗口之后的第一个时间窗口下本Pod发生过载的情况下，执行第二限流操作，具体的，包括但不限于如下步骤S1061、S1062中的内容。

S1061、确定本Pod接收到的多个第二业务请求所需调用的至少一个下游Pod中各个下游Pod的综合等级。

首先，确定本Pod接收到的多个第二业务请求所需调用的一个或多个下游Pod，其中，Pod根据第一业务请求可以识别出每个请求对应的是哪个微服务，可以理解为，Pod根据第一业务请求可以识别出每个请求对应需要调用哪个下游Pod。然后，确定多个第二业务请求所需调用的一个或多个下游Pod的综合等级。对于任一个下游Pod来说，根据该Pod的静态业务等级、该Pod的业务请求丢弃率阈值、该Pod的业务请求丢弃率，确定该Pod的综合等级。在一种示例中，可以通过数值表示静态业务等级，利用欧几里得距离算法计算获得各个下游Pod的综合等级。具体内容可参考步骤S1031中内容的描述，为了说明书的简洁，在此不再展开介绍。

S1062、根据多个第二业务请求所需调用的各个下游Pod的综合等级，将多个第二业务请求中的部分业务请求丢弃，将剩余部分业务请求下发至对应的下游Pod。

确定出多个第二业务请求所需调用的各个下游Pod的综合等级后，首先，从其中筛选出综合等级比第一限流操作中多个第一业务请求调用的各个下游Pod中综合等级最低的Pod高的Pod，作为第一目标集合。例如，图4示例中，综合等级最低的Pod是Pod B，则从多个第二业务请求所需调用的各个下游Pod中筛选出综合等级比Pod B高的Pod，作为第一目标集合。然后，从第一目标集合中，确定出综合等级最低的Pod并删除，获得第二目标集合。最后，本Pod(上游Pod)将多个第二业务请求中用于指示调用第二目标集合中的任意一个Pod的业务请求下发至对应的下游Pod，将其他业务请求丢弃。

例如，图4示例中，第一限流操作中，Pod B的综合等级最低，表示Pod B的综合等级的数值为104，则在第二限流操作中，首先，计算出多个第二业务请求所需调用的各个下游Pod的综合等级的数值，然后，从其中确定出综合等级数值比104小的Pod(综合等级比Pod B高的Pod)，作为第一目标集合，再从第一目标集合中确定出综合等级数值最大的Pod(综合等级最低的Pod)，并将其删除，获得第二目标集合，最后，将多个第二业务请求中用于指示调用第二目标集合中的任意一个Pod的业务请求下发至对应的Pod，将其他业务请求丢弃。

S107、在当前时间窗口发生过载且在当前时间窗口之后的第一个时间窗口下本Pod未发生过载的情况下，将多个第二业务请求下发至对应的下游容器组Pod。

在确定当前时间窗口之后的第一个时间窗口下本Pod未发生过载的情况下，按照正常操作将多个第二业务请求下发至对应的下游容器组Pod，等待下一个时间窗口的来临，再次判断下一个时间窗口是否发生过载，若发生过载则执行第三限流操作，若未发生过载，则执行步骤S101。

可选的，在当前时间窗口之后的第二个时间窗口下，确定本Pod是否发生过载，方法类似步骤S105，具体内容可参考上述S105步骤中的描述，为了说明书的简洁，在此不再展开介绍。在确定本Pod发生过载的情况下，执行第三限流操作，包括：

1)确定本Pod接收的多个第三业务请求所需调用的一个或多个下游Pod的综合等级，本步骤可参考步骤S1061的相关描述，在此不再展开描述；

2)从多个第三业务请求所需调用的各个下游Pod中，确定出第三目标集合，第三目标集合包括综合等级比第二限流操作中第一目标集合中综合等级最低的Pod高的Pod；

3)从第三目标集合中确定出综合等级最低的Pod，并删除，获得第四目标集合；

4)将多个第三业务请求中用于指示调用第四目标集合中任意一个Pod的业务请求下发至对应的下游Pod中，将其他业务请求丢弃。

需要说明的是，在执行步骤S101之前，本Pod(上游Pod)未发生过载，即在当前时间窗口之前的一个时间窗口下，本Pod未发生过载。

可选的，在一种示例中，若在当前时间窗口之后的连续n个时间窗口下本Pod均未发生过载，在第n+1个时间窗口下发生过载的情况下，则第n+1个时间窗口下执行第一限流操作，其中n可以由用户根据具体情况具体设置。

可选的，在一种示例中，若本Pod未达到在当前时间窗口之后的连续n个时间窗口下不发生过载，也可以执行类似第一限流或第二限流操作的限流操作，丢弃一部分业务请求。

需要说明的是，为了便于理解，本申请实施例描述了步骤S101至步骤S107连续两个时间窗口的限流方法，实际应用中，可能存在更多数量或更少数量的连续几个时间窗口发生过载。比如，若连续三个时间窗口本Pod(上游Pod)发生过载行为，则本Pod在发生过载行为的这三个时间窗口下，均执行一次限流操作，且第二次限流操作中丢弃的业务请求所调用的下游Pod的综合等级比第一次限流操作中丢弃的业务请求所调用的下游Pod的综合等级高，第三次限流操作中丢弃的业务请求所调用的下游Pod的综合等级比第二次限流操作中丢弃的业务请求所调用的下游Pod的综合等级高，以使本Pod的过载行为尽快消失。

可以看到，本申请提供了一种服务网格限流方法，根据上游Pod的资源使用情况确定该上游Pod是否发生过载，在确定发生过载的情况下，进行限流，在进行限流时，综合考虑了下游Pod的静态业务等级和下游Pod的真实过载情况，来确定下游Pod的综合等级，选择调用综合等级低的业务请求进行丢弃，从而保证系统的稳定性和业务的稳定性。其中综合等级低的Pod可能是静态业务等级低(微服务等级低)，也可能是处于高负载状态。

参见图5，图5为本申请提供的一种服务网格限流装置500的结构示意图，装置500包括具有上下游对应关系的上游容器组Pod，每个容器组Pod中部署了边车容器与应用程序容器，应用程序容器用于处理业务请求，边车容器用于对业务请求的流量进行管控，装置500包括：

在当前时间窗口下：

综合等级确定模块510，用于在确定上游容器组Pod发生过载的情况下，确定上游容器组Pod接收的多个第一业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级，下游容器组Pod的综合等级是基于预先设置的下游容器组Pod的静态业务等级和下游容器组Pod实际处理业务请求的能力确定的；

通信模块520，用于根据多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将多个第一业务请求中除部分业务请求之外的剩余部分业务请求丢弃。

在可能的实现方式中，下游容器组Pod实际处理业务请求的能力包括下游容器组Pod的业务请求丢弃率阈值和下游容器组Pod的过载率中的一项或多项，下游容器组Pod的过载率与丢弃率差值成正相关，丢弃率差值指的是下游容器组Pod的业务请求丢弃率与业务请求丢弃率阈值的差值。

在可能的实现方式中，下游容器组Pod的综合等级与下游容器组Pod的静态业务等级成正相关；下游容器组Pod的综合等级与下游容器组Pod的业务请求丢弃率阈值成负相关；下游容器组Pod的综合等级与下游容器组Pod的过载率成负相关。

在可能的实现方式中，获取模块530，用于获取当前时间窗口下上游容器组Pod的资源使用率；过载确定模块540，用于根据上游容器组Pod的资源使用率，确定当前窗口下上游容器组Pod是否发生过载。

在可能的实现方式中，上游容器组Pod的资源使用率包括上游容器组Pod中处理器的使用率和/或内存的使用率；过载确定模块540用于：当处理器的使用率大于设置的处理器使用率过载阈值，和/或当内存的使用率大于设置的内存使用率过载阈值时，确定当前窗口下上游容器组Pod发生过载；否则，确定当前窗口下上游容器组Pod未发生过载。

在可能的实现方式中，综合等级确定模块510用于，从多个第一业务请求所需调用的各个下游容器组Pod中，确定出综合等级最低的下游容器组Pod，作为第一目标容器组Pod；

通信模块520用于，将多个第一业务请求中用于指示调用综合等级高于第一目标容器组Pod的下游容器组Pod的业务请求下发至对应的下游容器组Pod，将剩余部分业务请求丢弃。

在可能的实现方式中，综合等级确定模块510用于：

在当前时间窗口之后的第一个时间窗口下：

在确定上游容器组Pod发生过载的情况下，确定上游容器组Pod接收的多个第二业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从多个第二业务请求所需调用的各个下游容器组Pod中，确定出综合等级比第一目标容器组Pod高的下游容器组Pod，作为第一集合；

确定出第一集合中综合等级最低的下游容器组Pod，作为第二目标容器组pod；

通信模块520用于：

将多个第二业务请求中用于指示调用综合等级高于第二目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

在可能的实现方式中，综合等级确定模块用于：

在当前时间窗口之后的第二个时间窗口下：

若上游容器组Pod发生过载的情况下，确定上游容器组Pod接收的多个第三业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从多个第三业务请求所需调用的各个下游容器组Pod中，确定出综合等级比第二目标容器组Pod高的下游容器组Pod，作为第二集合；

确定出第二集合中综合等级最低的下游容器组Pod，作为第三目标容器组pod；

通信模块用于：

将多个第三业务请求中用于指示调用综合等级高于第三目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

在可能的实现方式中，下游容器组Pod的综合等级通过数值表示。

其中，综合等级确定模块510、通信模块520、获取模块530、过载确定模块540均可以通过软件实现，或者可以通过硬件实现。示例性的，接下来以综合等级确定模块510为例，介绍综合等级确定模块510的实现方式。类似的，通信模块520、获取模块530、过载确定模块540的实现方式可以参考综合等级确定模块510的实现方式。

模块作为软件功能单元的一种举例，综合等级确定模块510可以包括运行在计算设备上的代码。其中，计算设备可以是物理主机、虚拟机、容器等中的至少一种。进一步地，上述计算设备可以是一台或者多台。例如，综合等级确定模块510可以包括运行在多个主机/虚拟机/容器上的代码。需要说明的是，用于运行该应用程序的多个主机/虚拟机/容器可以分布在相同的区域(region)中，也可以分布在不同的region中。用于运行该代码的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone，AZ)中，也可以分布在不同的AZ中，每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中，通常一个region可以包括多个AZ。

同样，用于运行该代码的多个主机/虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud，VPC)中，也可以分布在多个VPC中。其中，通常一个VPC设置在一个region内。同一region内两个VPC之间，以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关，经通信网关实现VPC之间的互连。

模块作为硬件功能单元的一种举例，综合等级确定模块510可以包括至少一个计算设备，如服务器等。或者，综合等级确定模块510也可以是利用专用集成电路(application-specific integrated circuit，ASIC)实现、或可编程逻辑器件(programmable logic device，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)、现场可编程门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合实现。

综合等级确定模块510包括的多个计算设备可以分布在相同的region中，也可以分布在不同的region中。综合等级确定模块510包括的多个计算设备可以分布在相同的AZ中，也可以分布在不同的AZ中。同样，综合等级确定模块510包括的多个计算设备可以分布在同一个VPC中，也可以分布在多个VPC中。其中，所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。

参见图6，图6为本申请提供的一种计算设备600的结构示意图，计算设备600例如裸金属服务器、虚拟机、容器等，该计算设备600可以配置为方法实施例中的上游容器组Pod，具体的可配置为上游容器组Pod中的边车容器。计算设备600包括：总线602、处理器604、存储器606和通信接口608。处理器604、存储器606和通信接口608之间通过总线602通信。应理解，本申请不限定计算设备600中的处理器、存储器的个数。

总线602可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。总线602可包括在计算设备600各个部件(例如，存储器606、处理器604、通信接口608)之间传送信息的通路。

处理器604可以包括中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

存储器606可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。处理器604还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard diskdrive，HDD)或固态硬盘(solid state drive，SSD)。

存储器606中存储有可执行的程序代码，处理器604执行该可执行的程序代码以分别实现前述综合等级确定模块510、通信模块520、获取模块530、过载确定模块540的功能，从而实现一种服务网格限流方法。也即，存储器606上存有用于执行一种服务网格限流方法的指令。

通信接口608使用例如但不限于网络接口卡、收发器一类的收发模块，来实现计算设备600与其他设备或通信网络之间的通信。可选的，例如通信模块520可以位于通信接口608中。

本申请实施例还提供了一种计算设备集群。该计算设备集群包括至少一台计算设备。该计算设备可以是服务器、虚拟机、容器，例如是中心服务器、边缘服务器、边车容器。

如图7所示，图7为本申请提供的一种计算设备集群的结构示意图，所述计算设备集群包括至少一个计算设备600，在一种场景中，所述计算设备集群中的至少一个计算设备可以配置为边车容器，计算设备集群中的一个或多个计算设备600中的存储器606中可以存有相同的用于执行一种服务网格限流方法的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备600的存储器606中也可以分别存有用于执行一种服务网格限流方法的部分指令。换言之，一个或多个计算设备600的组合可用于共同执行一种服务网格限流方法的指令。

当计算设备集群中的至少一个计算设备配置为服务网格限流装置500时，计算设备集群中的不同的计算设备600中的存储器606可以存储不同的指令，分别用于执行装置500的部分功能。也即，不同的计算设备600中的存储器606存储的指令可以实现综合等级确定模块510、通信模块520、获取模块530、过载确定模块540中的一个或多个模块的功能。

在一些可能的实现方式中，计算设备集群中的一个或多个计算设备可以通过网络连接。其中，所述网络可以是广域网或局域网等等。图8示出了一种可能的计算设备集群的实现方式。如图8所示，两个计算设备600A和600B之间通过网络进行连接。具体地，通过各个计算设备中的通信接口与所述网络进行连接。在这一类可能的实现方式中，计算设备600A中的存储器606中存储有获取模块530、过载确定模块540的功能的指令，计算设备600B中的存储器606中存有执行通信模块520、综合等级确定模块510的功能的指令。

应理解，图8中示出的计算设备600A的功能也可以由多个计算设备600完成，或者计算设备集群中包括多个与计算设备600A具有相同功能的计算设备。同样，计算设备600B的功能也可以由多个计算设备600完成，或者计算设备集群中包括多个与计算设备600B具有相同功能的计算设备。

本申请实施例还提供了另一种计算设备集群。该计算设备集群中各计算设备之间的连接关系可以类似的参考图7和图8所述计算设备集群的连接方式。不同的是，该计算设备集群中的一个或多个计算设备600中的存储器606中可以存有不同的用于执行一种服务网格限流方法的指令。在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备600的存储器606中也可以分别存有用于执行一种服务网格限流方法的部分指令。换言之，一个或多个计算设备600的组合可以共同执行用于执行一种服务网格限流方法的指令。

本申请实施例还提供了一种包含指令的计算机程序产品。所述计算机程序产品可以是包含指令的，能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品。当所述计算机程序产品在至少一个计算设备上运行时，使得至少一个计算设备执行一种服务网格限流方法。

本申请实施例还提供了一种计算机可读存储介质。所述计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，所述指令指示计算设备或计算设备集群执行一种服务网格限流方法。

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

Claims (18)

1.一种服务网格限流方法，其特征在于，所述方法应用于具有上下游对应关系的上游容器组Pod，每个容器组Pod中部署了边车容器与应用程序容器，所述应用程序容器用于处理所述业务请求，所述边车容器用于对业务请求的流量进行管控，所述方法包括：

在当前时间窗口下：

在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第一业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级，所述下游容器组Pod的综合等级是基于预先设置的所述下游容器组Pod的静态业务等级和所述下游容器组Pod实际处理业务请求的能力确定的；

根据所述多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将所述多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将所述多个第一业务请求中除所述部分业务请求之外的剩余部分业务请求丢弃。

2.根据权利要求1所述的方法，其特征在于，所述下游容器组Pod实际处理业务请求的能力包括所述下游容器组Pod的业务请求丢弃率阈值和所述下游容器组Pod的过载率中的一项或多项，所述下游容器组Pod的过载率与丢弃率差值成正相关，所述丢弃率差值指的是所述下游容器组Pod的业务请求丢弃率与所述业务请求丢弃率阈值的差值。

3.根据权利要求2所述的方法，其特征在于，

所述下游容器组Pod的综合等级与所述下游容器组Pod的静态业务等级成正相关；

所述下游容器组Pod的综合等级与所述下游容器组Pod的业务请求丢弃率阈值成负相关；

所述下游容器组Pod的综合等级与所述下游容器组Pod的过载率成负相关。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

获取当前时间窗口下所述上游容器组Pod的资源使用率；

根据所述上游容器组Pod的资源使用率，确定当前窗口下所述上游容器组Pod是否发生过载。

5.根据权利要求4所述的方法，其特征在于，所述上游容器组Pod的资源使用率包括所述上游容器组Pod中处理器的使用率和/或内存的使用率；

所述根据所述上游容器组Pod的资源使用率，确定当前窗口下所述上游容器组Pod是否发生过载，包括：

当所述处理器的使用率大于设置的处理器使用率过载阈值，和/或当所述内存的使用率大于设置的内存使用率过载阈值时，确定当前窗口下所述上游容器组Pod发生过载；

否则，确定当前窗口下所述上游容器组Pod未发生过载。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述根据所述多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将所述多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将所述多个第一业务请求中除所述部分业务请求之外的剩余部分业务请求丢弃，包括：

从所述多个第一业务请求所需调用的各个下游容器组Pod中，确定出综合等级最低的下游容器组Pod，作为第一目标容器组Pod；

将所述多个第一业务请求中用于指示调用综合等级高于所述第一目标容器组Pod的下游容器组Pod的业务请求下发至对应的下游容器组Pod，将剩余部分业务请求丢弃。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在所述当前时间窗口之后的第一个时间窗口下：

在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第二业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从所述多个第二业务请求所需调用的各个下游容器组Pod中，确定出综合等级比所述第一目标容器组Pod高的下游容器组Pod，作为第一集合；

确定出所述第一集合中综合等级最低的下游容器组Pod，作为第二目标容器组pod；

将所述多个第二业务请求中用于指示调用综合等级高于所述第二目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述下游容器组Pod的综合等级通过数值表示。

9.一种服务网格限流装置，其特征在于，所述装置包括具有上下游对应关系的上游容器组Pod，每个容器组Pod中部署了边车容器与应用程序容器，所述应用程序容器用于处理所述业务请求，所述边车容器用于对业务请求的流量进行管控，所述装置包括：

在当前时间窗口下：

综合等级确定模块，用于在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第一业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级，所述下游容器组Pod的综合等级是基于预先设置的所述下游容器组Pod的静态业务等级和所述下游容器组Pod实际处理业务请求的能力确定的；

通信模块，用于根据所述多个第一业务请求所需调用的各个下游容器组Pod的综合等级，将所述多个第一业务请求中的部分业务请求下发至对应的下游容器组Pod，将所述多个第一业务请求中除所述部分业务请求之外的剩余部分业务请求丢弃。

10.根据权利要求9所述的装置，其特征在于，所述下游容器组Pod实际处理业务请求的能力包括所述下游容器组Pod的业务请求丢弃率阈值和所述下游容器组Pod的过载率中的一项或多项，所述下游容器组Pod的过载率与丢弃率差值成正相关，所述丢弃率差值指的是所述下游容器组Pod的业务请求丢弃率与所述业务请求丢弃率阈值的差值。

11.根据权利要求10所述的装置，其特征在于，

所述下游容器组Pod的综合等级与所述下游容器组Pod的静态业务等级成正相关；

所述下游容器组Pod的综合等级与所述下游容器组Pod的业务请求丢弃率阈值成负相关；

所述下游容器组Pod的综合等级与所述下游容器组Pod的过载率成负相关。

12.根据权利要求9-11任一项所述的装置，其特征在于，

获取模块，用于获取当前时间窗口下所述上游容器组Pod的资源使用率；

过载确定模块，用于根据所述上游容器组Pod的资源使用率，确定当前窗口下所述上游容器组Pod是否发生过载。

13.根据权利要求12所述的装置，其特征在于，所述上游容器组Pod的资源使用率包括所述上游容器组Pod中处理器的使用率和/或内存的使用率；

所述过载确定模块用于：

当所述处理器的使用率大于设置的处理器使用率过载阈值，和/或当所述内存的使用率大于设置的内存使用率过载阈值时，确定当前窗口下所述上游容器组Pod发生过载；

否则，确定当前窗口下所述上游容器组Pod未发生过载。

14.根据权利要求9-13任一项所述的装置，其特征在于，

所述综合等级确定模块用于，从所述多个第一业务请求所需调用的各个下游容器组Pod中，确定出综合等级最低的下游容器组Pod，作为第一目标容器组Pod；

所述通信模块用于，将所述多个第一业务请求中用于指示调用综合等级高于所述第一目标容器组Pod的下游容器组Pod的业务请求下发至对应的下游容器组Pod，将剩余部分业务请求丢弃。

15.根据权利要求14所述的装置，其特征在于，所述综合等级确定模块用于：

在所述当前时间窗口之后的第一个时间窗口下：

在确定所述上游容器组Pod发生过载的情况下，确定所述上游容器组Pod接收的多个第二业务请求所需调用的至少一个下游容器组Pod中各个下游容器组Pod的综合等级；

从所述多个第二业务请求所需调用的各个下游容器组Pod中，确定出综合等级比所述第一目标容器组Pod高的下游容器组Pod，作为第一集合；

确定出所述第一集合中综合等级最低的下游容器组Pod，作为第二目标容器组pod；

所述通信模块用于：

将所述多个第二业务请求中用于指示调用综合等级高于所述第二目标容器组pod的下游pod的业务请求下发至对应的下游容器组Pod中，将剩余部分业务请求丢弃。

16.根据权利要求9-15任一项所述的装置，其特征在于，所述下游容器组Pod的综合等级通过数值表示。

17.一种计算设备集群，其特征在于，包括至少一台计算设备，所述至少一台计算设备中的每台计算设备包括存储器和处理器，所述至少一台计算设备的处理器用于执行所述至少一台计算设备的存储器中存储的指令，使得所述计算设备集群执行如权利要求1至8任一项所述的方法。

18.一种包含指令的计算机存储介质，其特征在于，当所述指令在计算设备集群中运行时，使得所述计算设备集群执行如权利要求1至8任一项所述的方法。