CN110505155B - 请求降级处理方法、装置、电子设备及存储介质 - Google Patents

请求降级处理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN110505155B
CN110505155B CN201910744178.XA CN201910744178A CN110505155B CN 110505155 B CN110505155 B CN 110505155B CN 201910744178 A CN201910744178 A CN 201910744178A CN 110505155 B CN110505155 B CN 110505155B
Authority
CN
China
Prior art keywords
delay
service request
service
mobilized
queue length
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910744178.XA
Other languages
English (en)
Other versions
CN110505155A (zh
Inventor
王玉龙
曹福祥
刘希诚
邢志浩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Dajia Internet Information Technology Co Ltd
Original Assignee
Beijing Dajia Internet Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Dajia Internet Information Technology Co Ltd filed Critical Beijing Dajia Internet Information Technology Co Ltd
Priority to CN201910744178.XA priority Critical patent/CN110505155B/zh
Publication of CN110505155A publication Critical patent/CN110505155A/zh
Application granted granted Critical
Publication of CN110505155B publication Critical patent/CN110505155B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本公开是关于一种请求降级处理方法、装置、电子设备及存储介质，涉及互联网技术领域，用以解决相关技术中基于流量控制的降级策略中容量预估难以实现的问题，本公开方法包括：如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与被调动微服务节点对应的最大业务请求队列长度，其中业务请求队列长度表示已发送给被调动微服务节点且未接收到被调动微服务节点返回的结果的业务请求的数量；若业务请求队列长度不小于被调动微服务节点对应的最大业务请求队列长度，则对业务请求进行降级处理。由于本公开不需要对被调用的被调动微服务节点做容量的预估，因而更易实现对业务请求的降级处理，实现了在被调动微服务节点容量不足时的自动降级。

Description

请求降级处理方法、装置、电子设备及存储介质
技术领域
本公开涉及互联网技术领域，尤其涉及一种请求降级处理方法、装置、电子设备及存储介质。
背景技术
随着互联网技术的快速发展，越来越多的业务可以通过网络实现，比如:支付、购物等。业务服务提供商可以在后台部署多个用于提供业务服务的微服务节点(也可称作业务系统)，各微服务节点之间可以进行服务调用，以协同完成业务。某个微服务节点的调用响应时间过长或者不可用对微服务节点的调用就会占用越来越多的系统资源，进而引起系统崩溃，即所谓的“雪崩效应”。
基于流量控制的降级策略是减少“雪崩效应”发生的一种常见的处理方式，需要对被调微服务的容量做预估，如果实际的业务流量超过预估值，就对超过的流量做请求降级处理。但是容量预估本身是困难的，尤其是在微服务节点级联的情况下，微服务节点会形成一个网状的拓扑结构，微服务节点之间依赖关系复杂，微服务节点容量也会相互依赖，使得容量预估很难进行。
综上所述，基于流量控制的降级策略中容量预估难以实现。
发明内容
本公开提供一种请求降级处理方法、装置、电子设备及存储介质，以至少解决相关技术中基于流量控制的降级策略中容量预估难以实现的问题。本公开的技术方案如下：
根据本公开实施例的第一方面，提供一种请求降级处理方法，包括：
如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与所述被调动微服务节点对应的最大业务请求队列长度，其中所述业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量；
若所述业务请求队列长度不小于所述被调动微服务节点对应的最大业务请求队列长度，则对所述业务请求进行降级处理。
在一种可能的实施方式中，所述方法还包括：
若所述业务请求队列长度小于所述被调动微服务节点对应的最大业务请求队列长度，则将所述业务请求队列长度增大指定步长，并将所述业务请求发送给所述被调动微服务节点；
在接收到所述被调动微服务节点返回的所述业务请求对应的处理结果后，将所述业务请求队列长度减小所述指定步长。
在一种可能的实施方式中，通过下列方式确定所述最大业务请求队列长度：
根据发送给所述被调动微服务节点的业务请求的延迟确定所述最大业务请求队列长度。
在一种可能的实施方式中，所述根据发送给所述被调动微服务节点的业务请求的延迟确定所述最大业务请求队列长度步骤包括：
每隔时长确定所述预设时长内发送给所述被调动微服务节点的业务请求的延迟；
若所述延迟大于与所述延迟对应的阈值，则减小所述最大业务请求队列长度；
若所述延迟不大于与所述延迟对应的阈值，则增大所述最大业务请求队列长度。
在一种可能的实施方式中，若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，则所述延迟对应的阈值为预设的平均延迟阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，则所述阈值为预设的比例阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，则所述延迟对应的阈值为预设的第一指定延迟阈值，其中M为正整数，且M是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与m％的乘积确定的，m为正数；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟，则所述延迟对应的阈值为预设的第二指定延迟阈值，其中N为正整数，且N是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与n％的乘积确定的，n为正数。
在一种可能的实施方式中，所述增大所述最大业务请求队列长度的步骤包括：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长；
将所述最大业务请求队列长度增大所述第一调整步长，并将增大所述第一调整步长后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度；和/或
所述减小所述最大业务请求队列长度的步骤包括：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长；
将所述业务请求队列长度减小所述第二调整步长，并将减小所述第二调整步长后的业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度。
在一种可能的实施方式中，所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长的步骤包括：
根据差值范围与第一调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第一调整步长；和/或
所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长的步骤包括：
根据差值范围与第二调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第二调整步长。
在一种可能的实施方式中，所述对所述业务请求进行降级处理的步骤包括：
若根据所述业务请求的类型确定将所述业务请求暂停处理，则将与所述业务请求的类型对应的预设结果作为所述业务请求的处理结果；或
若根据所述业务请求的类型确定将所述业务请求延迟处理，则在与所述业务请求的类型对应的预设等待时长到达后对所述业务请求恢复处理。
根据本公开实施例的第二方面，提供一种请求降级处理装置，包括：
比较单元，被配置为执行如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与所述被调动微服务节点对应的最大业务请求队列长度，其中所述业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量；。
第一处理单元，被配置为执行若所述业务请求队列长度不小于所述被调动微服务节点对应的最大业务请求队列长度，则对所述业务请求进行降级处理。
在一种可能的实施方式中，所述装置还包括：
发送单元，被配置为执行若所述业务请求队列长度小于所述被调动微服务节点对应的最大业务请求队列长度，则将所述业务请求队列长度增大指定步长，并将所述业务请求发送给所述被调动微服务节点；
第二处理单元，被配置为执行在接收到所述被调动微服务节点返回的所述业务请求对应的处理结果后，将所述业务请求队列长度减小所述指定步长。
在一种可能的实施方式中，所述比较单元还用于通过下列方式确定所述最大业务请求队列长度：
根据发送给所述被调动微服务节点的业务请求的延迟确定所述最大业务请求队列长度。
在一种可能的实施方式中，所述比较单元具体用于：
每隔时长确定所述预设时长内发送给所述被调动微服务节点的业务请求的延迟；
若所述延迟大于与所述延迟对应的阈值，则减小所述最大业务请求队列长度；
若所述延迟不大于与所述延迟对应的阈值，则增大所述最大业务请求队列长度。
在一种可能的实施方式中，若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，则所述延迟对应的阈值为预设的平均延迟阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，则所述阈值为预设的比例阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，则所述延迟对应的阈值为预设的第一指定延迟阈值，其中M为正整数，且M是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与m％的乘积确定的，m为正数；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟，则所述延迟对应的阈值为预设的第二指定延迟阈值，其中N为正整数，且N是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与n％的乘积确定的，n为正数。
在一种可能的实施方式中，所述比较单元具体用于：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长；
将所述最大业务请求队列长度增大所述第一调整步长，并将增大所述第一调整步长后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度；和/或
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长；
将所述业务请求队列长度减小所述第二调整步长，并将减小所述第二调整步长后的业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度。
在一种可能的实施方式中，所述比较单元具体用于：
根据差值范围与第一调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第一调整步长；和/或
所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长的步骤包括：
根据差值范围与第二调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第二调整步长。
在一种可能的实施方式中，所述第一处理单元具体用于：
若根据所述业务请求的类型确定将所述业务请求暂停处理，则将与所述业务请求的类型对应的预设结果作为所述业务请求的处理结果；或
若根据所述业务请求的类型确定将所述业务请求延迟处理，则在与所述业务请求的类型对应的预设等待时长到达后对所述业务请求恢复处理。
根据本公开实施例的第三方面，提供一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现本公开实施例第一方面中任一项所述的请求降级处理方法。
根据本公开实施例的第四方面，提供一种非易失性可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行本公开实施例第一方面中任一项所述的请求降级处理方法。
根据本公开实施例的第五方面，提供一种计算机程序产品，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行实现本公开实施例上述第一方面以及第一方面任一可能涉及的方法。
本公开的实施例提供的技术方案至少带来以下有益效果：
由于本公开实施例不需要对被调用的被调动微服务节点做容量的预估，而是通过比较业务请求队列长度与最大业务请求队列长度的大小对业务请求做是否降级处理的判断，其中的业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量，在业务请求队列长度不小于最大业务请求队列长度时，表明被调动微服务已经无法处理业务请求，此时对该业务请求做降级处理，即在被调动微服务节点容量不足时，能够自动做请求降级，保证了被调动微服务节点的资源利用率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种微服务架构的示意图；
图2是根据一示例性实施例示出的一种请求降级处理方法的示意图；
图3是根据一示例性实施例示出的一种微服务节点的示意图；
图4A是根据一示例性实施例示出的第一种请求降级处理的示意图；
图4B是根据一示例性实施例示出的第二种请求降级处理的示意图；
图4C是根据一示例性实施例示出的第三种请求降级处理的示意图；
图5是根据一示例性实施例示出的另一种请求降级处理方法的示意图；
图6A是根据一示例性实施例示出的第一种周期调整最大业务请求队列长度的示意图；
图6B是根据一示例性实施例示出的第二种周期调整最大业务请求队列长度的示意图；
图7A是根据一示例性实施例示出的一种差值范围和第一调整步长对应关系的示意图；
图7B是根据一示例性实施例示出的一种差值范围和第二调整步长对应关系的示意图；
图8是根据一示例性实施例示出的一种请求降级处理的完整方法的流程图；
图9是根据一示例性实施例示出的另一种请求降级处理的完整方法的流程图；
图10是根据一示例性实施例示出的一种请求降级处理装置的框图；
图11是根据一示例性实施例示出的一种电子设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
下面对文中出现的一些词语进行解释：
1、本公开实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
2、本公开实施例中术语“电子设备”是指由集成电路、晶体管、电子管等电子元器件组成，应用电子技术(包括)软件发挥作用的设备，包括电子计算机以及由电子计算机控制的机器人、数控或程控系统等。
3、本公开实施例中术语“微服务”是一种新型软件架构，是SOA(Service-OrientedArchitecture，面向服务的架构)架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足SLA(Service-Level Agreement，服务等级协议)。
4、本公开实施例中术语“上级微服务”是指一个微服务被其他微服务依赖的情况下，被依赖的微服务即上级微服务。
5、本公开实施例中术语“下级微服务节点”是指一个微服务依赖于其他的微服务协调工作的情况下，需要依赖其他微服务的微服务即下级微服务节点。
6、本公开实施例中术语“服务熔断”一般是某个服务故障或异常引起，类似“保险丝”，当某个异常被触发，直接熔断整个服务，而不是等到此服务超时。对于目标服务的请求和调用大量超时或失败，这时应该熔断该服务的所有调用，并且对于后续调用应直接返回，从而快速释放资源，确保在目标服务不可用的这段时间内，所有对它的调用都是立即返回，不会阻塞的。再等到目标服务好转后进行接口恢复。
7、本公开实施例中术语“请求降级”是指当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。
8、本公开实施例中术语“百分位数”是统计学术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组P个观测值按数值大小排列。如，处于n％位置的值(即第n个百分位的值)则称为第n百分位数。当观测值为延迟时，则一组P个延迟按数值大小排列，处于n％位置的延迟则称第n百分位数。
本公开实施例描述的应用场景是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域普通技术人员可知，随着新应用场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。其中，在本公开的描述中，除非另有说明，“多个”的含义。
在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，如图1所示，假设微服务A调用微服务B、微服务C，微服务B调用微服务D、微服务E，微服务C又调用微服务F、微服务G，这就是所谓的“扇出”。在软件设计中，扇入和扇出的概念是指应用程序模块之间的层次调用情况。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。
雪崩效应产生的几种场景有：1、流量激增：比如异常流量、用户重试导致系统负载升高；2、缓存刷新：假设A为Client(客户)端，B为Server(服务)端，假设A系统请求都流向B系统，请求超出了B系统的承载能力，就会造成B系统崩溃；3、程序有Bug(漏洞)：代码循环调用的逻辑问题，资源未释放引起的内存泄漏等问题；4、硬件故障：比如宕机，机房断电，光纤被挖断等；5、线程同步等待：系统间经常采用同步服务调用模式，核心服务和非核心服务共用一个线程池和消息队列。如果一个核心业务线程调用非核心线程，这个非核心线程交由第三方系统完成，当第三方系统本身出现问题，导致核心线程阻塞，一直处于等待状态，而进程间的调用是有超时限制的，最终这条线程将断掉，也可能引发雪崩。
为了有效减小雪崩效应的发生，常见的两种处理方式为基于流量控制的降级策略以及熔断降级策略。其中，熔断降级策略为：上级微服务节点根据RPC调用的成功情况，决定是否对被调动微服务节点进行熔断。常见的策略是RPC(Remote Procedure CallProtocol，远程过程调用协议)调用失败次数或者比例达到一定的阈值时，对被调动微服务节点整体熔断(即对该被调动微服务节点的所有业务请求降级)，隔一段时间之后再重新尝试发起请求。该方案的缺点是如果因为被调动微服务节点容量不足会造成浪费资源。微服务本身具备一定的容量，比如能处理的最大QPS(Query Per Second，每秒查询率)是8000，如果实际的业务QPS达到10000，可能造成的影响是延迟大幅上升，有大量的超时，为了控制延迟，可将所有业务请求熔断，但是熔断之后，被调动微服务节点可自动恢复。微服务会在恢复和熔断之间不断震荡，无法正常处理请求，造成资源浪费。
现有技术方案在做请求降级处理时，要么是不能对延迟做监测和控制，要么是为了控制延迟，将所有业务请求熔断，造成被调动资源浪费。本公开能够兼顾业务的平均延迟和被调动微服务节点的资源利用率，在最大化利用服务器资源情况下，保证平均延迟可控。
图2是根据一示例性实施例示出的一种请求降级处理方法的流程图，如图2所示，包括以下步骤：
在步骤S21中，如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与被调动微服务节点对应的最大业务请求队列长度；其中，业务请求队列长度表示已发送给被调动微服务节点且未接收到被调动微服务节点返回的结果的业务请求的数量；
在步骤S22中，若业务请求队列长度不小于被调动微服务节点对应的最大业务请求队列长度，则对业务请求进行降级处理。
由于本公开实施例不需要对被调用的被调动微服务节点做容量的预估，而是通过比较业务请求队列长度与最大业务请求队列长度的大小对业务请求做是否降级处理的判断，其中的业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量，在业务请求队列长度不小于最大业务请求队列长度时，表明被调动微服务已经无法处理业务请求，此时对该业务请求做降级处理，保证了被调动微服务节点的资源利用率，并且通过上级微服务对队列长度的判断实现了在被调动微服务节点容量不足时的自动降级。
在本公开实施例中，微服务节点可以是由一个或多个服务器组成的，当一个微服务节点包含多个服务器时，多个服务器可以是集群模式，例如图3所示的一种集群方式，3个不同的Web(World Wide Web，万维网)服务器部署同一套服务对外访问，连接同一网络节点，实现服务的负载均衡，微服务节点与微服务节点之间通过网络节点互联。
在本公开实施例中，某一下游微服务对应的最大业务请求队列长度是上游微服务根据经验值设置的，用于表示下游微服务容量的上限，可以大于下游微服务的实际容量。
例如图1中所示，与上级微服务节点ServiceA对应的下级微服务节点有ServiceB和ServiceC，其中上级微服务节点ServiceA需要向下级微服务节点ServiceB发送业务请求1时，下级微服务节点ServiceB为被调动微服务节点，因而需首先确定与ServiceB对应的业务请求队列长度，假设到目前为止ServiceA发送给ServiceB但未收到返回结果的请求有50个，则与ServiceB对应的业务请求队列长度为50，若上级微服务节点ServiceA确定的当前时刻与被调动微服务节点ServiceB对应的最大业务请求队列长度为80，则比较可知业务请求队列长度小于最大业务请求队列长度，因而无需对业务请求1进行降级处理。
假设，上级微服务节点ServiceA需要向下级微服务节点ServiceC发送业务请求2时，下级微服务节点ServiceC为被调动微服务节点，假设到目前为止ServiceA发送给ServiceC但未收到返回结果的请求有100个，则与ServiceC对应的业务请求队列长度为100，若上级微服务节点ServiceA确定的当前时刻与被调动微服务节点ServiceC对应的最大业务请求队列长度为80，则比较可知业务请求队列长度大于最大业务请求队列长度，因而对业务请求2进行降级处理。
当同一个被调动微服务可被多个上级微服务调用时，在设置某一被调动微服务对应的初始的最大业务请求队列长度时，则可根据经验值确定该被调动微服务只可被该上级微服务调用的情况下的容量作为初始的最大业务请求队列长度。
例如第一购物微服务以及第二购物微服务都被第一商品推荐微服务依赖，则第一购物微服务和第二购物微服务都属于第一商品推荐微服务的上级微服务，在设置第一商品推荐微服务对应的最大业务请求队列长度时，在第一购物微服务有请求需要发送给第一商品推荐微服务的情况下，则可将第一商品推荐微服务只依赖于第一购物微服务协同工作时第一商品推荐微服务的最大容量作为第一商品推荐微服务对应的最大业务请求队列长度，业务请求队列长度即表示到当前时刻位置第一购物微服务已发送给第一商品推荐微服务但未接收到第一商品推荐微服务处理结果的业务请求的数量。
在本公开实施例中，对业务请求进行降级处理的方式有很多种，可根据业务请求的类型来确定处理方式，下面主要列举两种处理方式：
处理方式一、若根据业务请求的类型确定将该业务请求暂停处理，则将与业务请求的类型对应的预设结果或者默认值作为业务请求的处理结果。
一般情况下与暂停处理方式对应的业务请求的类型为一些可返回一个消耗资源很低，但是用户也可以接受的结果的业务，或者是需要在一定时间内接收到返回结果的业务等。
示例1，假设该业务请求的类型为特殊类型：用户认证服务，则对业务请求1进行暂停处理，将该业务请求丢弃，假设该类型的业务请求对应的预设结果为认证失败，则可将认证失败作为业务请求1的处理结果，可直接将该结果返回给用户，如图4A所示，直接告诉用户认证失败了。
示例2，假设该业务请求的类型为商品推荐，则可将该业务请求丢弃，直接获取本地或与该业务请求对应的其他指定位置预先缓存的商品推荐结果作为该业务请求的处理结果向用户返回，例如该业务请求未推荐天文类书籍时，则可将预设的天文类书籍推荐结果返回给用户。
示例3，在交易下单环节的一些无关交易的业务请求，在平时系统没有压力、容量充足的情况下，调用没有问题，但是在类似店庆之类的大促环节，则可将无关交易的业务请求服务降级处理，可将该业务请求丢弃，将与该业务请求对应的预设的购买失败的结果作为处理结果返回给用户，向用户返回错误页，页面中提示如“活动太火爆了，稍后重试”等，或如图4B所示告知同一时间内下单人数太多稍后重试等；或者直接告知用户该商品无货，如图4C所示。
可选的，针对查看历史订单、查看商品历史评论等业务请求，则可只显示最后100条等等。
处理方式二、若根据业务请求的类型确定将该业务请求延迟处理，则在与业务请求的类型对应的预设等待时长到达后对业务请求恢复处理。
一般的，与延迟处理对应的业务请求的类型为一些不需要立即返回处理结果的请求，或者是一些可有可无的附加功能的业务请求、非核心的业务请求等。例如秒杀或抢购一些限购商品时，此时可能会因为访问了太大导致系统崩溃，因而可对被降级的业务请求(例如商品推荐)进行延迟处理，例如将一些用户导流到排队页面等一会重试。
其中，预设等待时长(即延迟的时长)是与业务请求的类型相关的，例如查看浏览历史类型的业务请求，对应的预设等待时长则较短，一般为几十毫秒，假设50毫秒；例如商品推荐类型的业务请求，对应的预设等待时长则较长，一般为几百毫秒，假设100毫秒。
在本公开实施例中，若一种业务类型对应多种处理方式，例如商品推荐的业务请求，既可以是暂停处理，也可以是延迟处理，则可在两种处理方式中随机确定一种方式进行处理，或者是对降级处理的业务请求也可调用其他的下游微服务节点进行该业务请求的处理等。
综上，针对上述两种请求降级处理方式的常用策略具体则可分为如下几种：1、页面拒绝服务：页面提示由于服务繁忙此服务暂停，跳转到一个静态页面，例如“目前系统正在维护”这样的页面。2、延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列，服务恢复后执行。3、随机拒绝服务：服务接口随机拒绝服务，让用户重试。4、服务接口拒绝服务：无用户特定信息，页面能访问，但是添加删除提示服务器繁忙。页面内容也可在CDN(Content Delivery Network，内容分发网络)内或其他位置获取。
需要说明的是，本公开实施例中所列举的对请求降级处理的方式只是举例说明，其他的降级处理方式也适用于本公开实施例。
图5是根据一示例性实施例示出的另一种请求降级处理方法的流程图，如图5所示，包括以下步骤：
在步骤S21中，若需要向被调动微服务节点发送业务请求，比较业务请求队列长度与被调动微服务节点对应的最大业务请求队列长度；其中，业务请求队列长度表示已发送给被调动微服务节点且未接收到被调动微服务节点返回的结果的业务请求的数量；
在步骤S22'中，若业务请求队列长度小于被调动微服务节点对应的最大业务请求队列长度，则将业务请求队列长度增大指定步长，并将业务请求发送给被调动微服务节点；
在步骤S23中，在接收到被调动微服务节点返回的业务请求对应的处理结果后，将业务请求队列长度减小指定步长。
在本公开实施例中，一般在上级微服务节点自动生成一个业务请求或是接收到一个业务请求且需要调用被调动微服务节点处理业务请求时，需要将业务请求发送给被调动微服务节点。若业务请求队列长度小于被调动微服务节点对应的最大业务请求队列长度，则表明该被调动微服务节点还可以处理该请求，就将请求发出。
例如，q_size表示业务请求队列长度，Capacity表示最大业务请求队列长度，假设上级微服务节点有一个业务请求需要发送给被调动微服务节点，且q_size<Capacity时，则将业务请求队列长度加1，即q_size:＝q_size+1，并将该业务请求发送给被调动微服务节点，在上级微服务节点接收到被调动微服务节点返回的该业务请求的处理结果后，将业务请求队列长度减1，即q_size:＝q_size-1。
可选的，计算本次业务请求的延迟(latency)，其中本次业务请求的延迟可通过接收到该业务请求处理结果时刻的时间戳与发送该业务请求时刻的时间戳的差来确定，例如发送该业务请求时刻的时间戳为9，接收到该业务请求处理结果时刻的时间戳为12，则延迟为12-9＝3(假设单位为毫秒)。
在本公开实施例中，初始化时，可将队列长度q_size为0，Capacity设置为根据经验值确定的被调动微服务节点的队列容量最大值。每次需要向被调动微服务节点发送一个业务请求时，则进行q_size与Capacity的比较，如果q_size超过了Capacity，说明被调动微服务节点已经无法处理业务请求，就对该业务请求进行降级处理。如果q_size没有超过Capacity，说明被调动微服务节点还可以处理业务请求，就将该业务请求发出，并将业务请求队列长度q_size加一，当业务请求返回结果时，将业务请求队列长度q_size减一。
在本公开实施例中，还可以根据发送给被调动微服务节点的业务请求的延迟确定最大业务请求队列长度，具体的：每隔时长确定预设时长内发送给被调动微服务节点的业务请求的延迟；若延迟大于与延迟对应的阈值，则减小最大业务请求队列长度；若延迟不大于与延迟对应的阈值，则增大最大业务请求队列长度。即周期调整一次最大请求队列长度，其中初始的最大业务请求队列长度是上级微服务节点根据经验值确定的当某一被调动微服务节点只被该上级微服务节点调用时，由该上级微服务节点设置的该下机微服务节点的最大容量的值。
微服务节点容量本身处于动态变化之中，微服务节点的每次上线升级，或者向集群中增加机器和减少机器，都会使微服务节点容量发生变化，针对基于流量控制的降级策略，则需要相应的调整降级策略的参数，否则可能引发误降级或者不能触发降级等问题。由于本公开实施例中，根据延迟周期调整最大业务请求队列长度，因而可以自动适应被调动微服务节点的容量变化。
具体的，周期调整最大业务请求队列长度Capacity时可以通过使用一个Timer(定时器)触发，即每隔一段时间调整一次Capacity，因此生效的时间会比较平缓。在周期调整时，根据预设时长内发送给被调动微服务节点的业务请求的延迟确定最大业务请求队列长度，在本公开实施例中预设时长内发送给被调动微服务节点的请求是指在满足业务请求队列长度小于最大业务请求队列长度的条件下发送给该被调动微服务节点且接收到被调动微服务节点返回的结果的请求。针对任意一个业务请求，根据发送业务请求以及接收到业务请求处理结果的时间戳可计算得到该业务请求的延迟。其中，延迟的类型不同，对应的阈值也不相同，以具体可分为以下几种情况：
类型一、若延迟为预设时长内发送给被调动微服务节点的所有业务请求的延迟的平均值，则延迟对应的阈值为平均延迟阈值。
例如，预设时长为3秒，初始的最大业务请求队列长度Capacity＝100，假设第一次调整最大业务请求队列长度时，从12:00～12:03的3秒时间窗口内发送的请求为100个，则预设时长内发送给被调动微服务节点的所有业务请求的延迟的平均值即这100个业务请求的延迟的平均值，假设平均值为avg1_latency，平均延迟阈值为ConfigLatency1，则：
当avg1_latency<＝ConfigLatency1时增大Capacity,例如增大为101；
当avg1_latency>ConfigLatency1时减小Capacity，例如减小为99。
在本公开实施例中，如果对平均延迟和业务请求队列长度之间做一个拟合，可以根据平均延迟预测调整的幅度，可以让请求降级更快的收敛。
类型二、若延迟为预设时长内发送给被调动微服务节点的所有业务请求的延迟的标准差与所有业务请求的延迟的平均值的比值，则阈值为比例阈值。
假设预设时长为4秒，上一次调整后最大业务请求队列长度Capacity＝102，假设本次调整最大业务请求队列长度时，从13:00～13:04的4秒时间窗口内发送的请求为100个，则延迟为这100个业务请求的延迟的标准差与这100个延迟的平均值的比值，假设这100个业务请求的延迟的标准差与这100个延迟的平均值的比值为latency_ratio,比例阈值为ConfigLatency2，则：
当latency_ratio<＝ConfigLatency2时增大Capacity；
当latency_ratio>ConfigLatency2时减小Capacity。
类型三、若延迟为预设时长内发送给被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，则延迟对应的阈值为预设的第一指定延迟阈值，其中M为正整数，且M是根据预设时长内发送给被调动微服务节点的所有业务请求的数量与m％的乘积确定的。
假设预设时长为3秒，上一次调整后最大业务请求队列长度Capacity＝99，假设再一次调整最大业务请求队列长度时，从13:30～13:33的3秒时间窗口内发送的请求为100个，m＝95，则M＝95％*100＝95，延迟为这100个业务请求的延迟中除最大的5个延迟外的95个延迟的平均值，假设为avg2_latency，第一指定延迟阈值为ConfigLatency3，则：
当avg2_latency<＝ConfigLatency3时增大Capacity；
当avg2_latency>ConfigLatency3时减小Capacity。
类型四、若延迟为预设时长内发送给被调动微服务节点的所有业务请求的延迟中的第N个延迟，则延迟对应的阈值为预设的第二指定延迟阈值，其中N为正整数，且N是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与n％的乘积确定的，n为正数。
在一种可选的实施方式中，第N个延迟即指第n个百分位的延迟，即一组延迟中的第n百分位数。
假设预设时长为4秒，上一次调整后最大业务请求队列长度Capacity＝98，假设再一次调整最大业务请求队列长度时，从15:30～15:34的4秒时间窗口内发送的请求为100个，n＝95，第n个百分位即100*95％＝95，则这100个业务请求的延迟中的第N个延迟即100个延迟按照数值从小到大顺序排序后的第95个延迟；若从15:30～15:34的4秒时间窗口内发送的请求为200个，n＝95，第n个百分位即200*95％＝190，则这200个业务请求的延迟中的第N个延迟即200个延迟按照数值从小到大顺序排序后的第190个延迟，假设延迟为Percentile_latency，第二指定延迟阈值为ConfigLatency4，则：
当Percentile_latency<＝ConfigLatency4时增大Capacity；
当Percentile_latency>ConfigLatency4时减小Capacity。
在一种可能的实施方式中，若预设时长内发送给被调动微服务节点的所有业务请求的数量与m％的乘积不是整数，则可将乘积取整后的值作为M；若预设时长内发送给被调动微服务节点的所有业务请求的数量与n％的乘积不是整数，则可将乘积取整后的值作为N。其中取整的方式包括但不限于下列的部分或全部：
四舍五入、向上取整、向下取整。
假设预设时长内发送给被调动微服务节点的所有业务请求的数量为100，则当m＝2.5时，100*2.5％＝2.5，则在确定M时可直接向下取整，即M＝2，或者通过向上取整或四舍五入得M＝3。
如果业务对延迟敏感，则可通过类型四中的延迟，例如采用P99延迟或P90延迟、P95延迟等。
当延迟为P90延迟时，n为90，假设预设时间内发生给被调动微服务节点的请求有100个，即预设时长内发送给被调动微服务节点的所有业务请求的延迟按照延迟数据从小到大排列后的第90个延迟；确定这100个请求的延迟按照从大到小排序为：4ms、4ms、4ms、3.9ms、3.8ms、3.7ms、3.6ms、3.5ms、3.4ms、3ms，2.9ms，2.8ms，…，则P90延迟为Percentile_latency＝3ms。
当延迟为P95延迟时，n为95，则P95延迟为Percentile_latency＝3.7ms。
在本公开实施例中，当M为1时，则最大的M个延迟的平均值即最大的延迟。
例如，当延迟为P99延迟时，n为1，则P99延迟为Percentile_latency＝4ms。
以上述四种类型的延迟为例，需要业务指定一个配置参数，即延迟对应的阈值，当该配置参数为平均延迟阈值时。微服务的平均延迟很容易获取，而且平均延迟可以作为SLA存在，这个参数是稳定的，很少会修改。根据利特尔法则，排队长度影响排队时间，减少排队长度可以减少等待时间，从而可以降低平均延迟。所以具体做法是当实际的延迟大于延迟对应的阈值时，就减少最大业务请求队列长度，当实际的延迟小于阈值时，就增大最大业务请求队列长度。
需要说明的是，在本公开实施例中所列举的周期调整最大业务请求队列长度只是一种调整方式，还可以根据实际情况非周期性的调整最大业务请求队列长度。
本公开实施例可以提高微服务的可用性，尤其是在被调动微服务容量不足时，可以有效控制平均延迟的上升。
在本公开实施例中，增大最大业务请求队列长度时的方式有很多种，下面列举几种：
增大方式一：增大指定步长。
当指定一个固定步长为1时，则每次增大最大业务请求队列长度时将Capacity加1，例如当前时刻Capacity＝103，则增大后Capacity＝104。
增大方式二、指数级增大。
例如，当前时刻Capacity＝103，按照e0.1指数级增长，则增大后Capacity＝103*e0.1＝114(乘积为小数，取整后为114)。
增大方式三、按照根据延迟以及与延迟对应的阈值之间的差值确定第一调整步长增大。如图6A所示，具体过程如下：
在步骤S61中，确定延迟以及与延迟对应的阈值的差值；
在步骤S62中，根据差值范围与第一调整步长之间的对应关系确定延迟以及与延迟对应的阈值之间的差值所属的差值范围对应的第一调整步长；
在步骤S63中，将最大业务请求队列长度增大第一调整步长；
在步骤S64中，将增大第一调整步长后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度。
其中，差值范围与第一调整步长的对应关系例如图7A所示的表格确定，由图7A可知，差值越大，第一调整步长越大。假设avg1_latency＝3ms，ConfigLatency2＝4ms，差值为1ms，属于第一个差值范围0～2ms，则第一调整步长为+1，假设当前Capacity＝100，则增大后为Capacity＝101。
在一种可能的实施方式中，可以设置一个最大队列长度(即最大业务请求队列长度的上限)，将增大第一调整步长(或增大指定步长，或指数级增大)后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度，其中预设最大队列长度是根据经验值设定的，可适用于多个被调动微服务节点，即多个被调动微服务节点的最大队列长度可相同，例如预设最大队列长度为Max，以增大指定步长1为例，则Capacity:＝min(Max，Capacity+1)；以增大第一调整步长step1为例，则Capacity:＝min(Max，Capacity+step1)。
例如，Capacity+1＝105>150＝Max，则调整后Capacity＝105；若Capacity+1＝150＝Max，则调整后Capacity＝150；若Capacity+1＝151>150＝Max，则调整后Capacity＝Max＝150。
同理，减小最大业务请求队列长度时的方式也有很多种，下面列举几种：
减小方式一：减小指定步长，例如每次减1。
当指定一个固定步长为1时，则每次减小最大业务请求队列长度时将Capacity减1，例如当前时刻Capacity＝103，则减小后Capacity＝102。
减小方式二、指数级减小。
例如，当前时刻Capacity＝103，按照e-0.1指数级减小，则减小后Capacity＝103*e-0.1＝93(乘积为小数，取整后为93)。
减小方式三、按照根据延迟以及与延迟对应的阈值之间的差值确定第二调整步长减小。如图6B所示，具体过程如下：
在步骤S61中，确定延迟与延迟对应的阈值的差值；
在步骤S62'中，根据差值范围与第二调整步长之间的对应关系确定延迟以及与延迟对应的阈值之间的差值所属的差值范围对应的第二调整步长；
在步骤S63'中，将业务请求队列长度减小第二调整步长；
在步骤S64'中，将减小第二调整步长后的业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度。
其中，差值范围与第二调整步长的对应关系的可通过图7B所示的表格确定，由图7B可知，差值越小，第二调整步长越小。假设avg1_latency＝4ms，ConfigLatency2＝3ms，差值为-1ms，属于第一个差值范围-2～0ms，则第二调整步长为-1，假设当前Capacity＝100，则减小后为Capacity＝99。
在一种可能的实施方式中，可以设置一个最小队列长度(即最大业务请求队列长度的下限)，将减小第二调整步长(或减小指定步长，或指数级减小)后的最大业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度，其中预设最小队列长度也是根据经验值设定的，可适用于多个被调动微服务节点，即多个被调动微服务节点的最小队列长度可相同，例如预设最小队列长度为1，以减小指定步长1为例，则Capacity:＝max(1，Capacity-1)；以减小第二调整步长step2为例，则Capacity:＝max(1，Capacity-step2)。
例如，Capacity-1＝3>1，则调整后Capacity＝3；若Capacity-1＝0>1，则调整后Capacity＝1；若Capacity-1＝1，则调整后Capacity＝1。
图8为例根据一示例性实施例示出的一种上级微服务节点对请求降级处理的完整方法流程图，具体包括以下步骤：
步骤800、接收到业务请求；
步骤801、判断q_size是否小于Capacity，如果是，则执行步骤802，否则，执行步骤803；
步骤802、q_size:＝q_size+1；
步骤803、返回失败；
步骤804、发送业务请求；
步骤805、接收业务请求处理结果；
步骤806、q_size:＝q_size+1，计算本次延迟latency；
步骤807、判断Timer是否触发，如果是，则执行步骤808，否则，返回步骤807；
步骤808、计算Avg_latency，判断Avg_latency是否不大于ConfigLatency，如果是，则只需步骤809，否则，执行步骤810；
步骤809、Capacity:＝min(Max，Capacity+1)；
步骤810、Capacity:＝max(1，Capacity-1)。
在本公开实施例中，能够兼顾业务的平均延迟和被调动微服务节点的资源利用率，在最大化利用服务器资源情况下，保证平均延迟可控。另外本公开需要业务配置的参数只有延迟对应的阈值，而且这个参数几乎不用修改就可以适应服务容量的变化。
图9是根据一示例性实施例示出的另一种请求降级处理的完整方法流程图，具体包括以下步骤：
步骤900、上级微服务节点确定有业务请求需要发送给被调动微服务节点；
步骤901、上级微服务节点判断业务请求队列长度是否小于该被调动微服务节点对应的最大业务请求队列长度，如果是，则执行步骤902，否则，执行步骤903；
步骤902、上级微服务节点将业务请求队列长度加1，并将业务请求发送给被调动微服务节点；
步骤903、上级微服务节点根据该业务请求的类型确定对该业务请求进行降级处理的方式，并根据确定的方式对该业务请求进行降级处理；
步骤904、上级微服务节点在一段时间后接收到被调动微服务节点返回的结果，并将业务请求队列长度减1；
步骤905、上级微服务节点计算该业务请求的延迟；
步骤906、上级微服务节点在预设时长达到后确定该预设时长内发送给该被调动微服务节点的所有业务请求的延迟的平均值；
步骤907、上级微服务节点比较该平均值是否大于预设的平均延迟阈值，如果是，则执行步骤908，否则，执行步骤710；
步骤908、上游微服务节点将该下游微服务节点对应的最大业务请求队列长度加1，并将加1后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度；
步骤909、上游微服务节点将业务请求队列长度减1，并将减1后的业务请求队列长度与最小业务请求队列长度中的最大值作为减小后的最大业务请求队列长度。
图10是根据一示例性实施例示出的一种请求降级处理装置框图。参照图10，该装置包括比较单元1000和第一处理单元1001。
比较单元1000，被配置为执行如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与所述被调动微服务节点对应的最大业务请求队列长度，其中所述业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量；。
第一处理单元1001，被配置为执行若所述业务请求队列长度不小于所述被调动微服务节点对应的最大业务请求队列长度，则对所述业务请求进行降级处理。
在一种可能的实施方式中，所述装置还包括：
发送单元1002，被配置为执行若所述业务请求队列长度小于所述被调动微服务节点对应的最大业务请求队列长度，则将所述业务请求队列长度增大指定步长，并将所述业务请求发送给所述被调动微服务节点；
第二处理单元1003，被配置为执行在接收到所述被调动微服务节点返回的所述业务请求对应的处理结果后，将所述业务请求队列长度减小所述指定步长。
在一种可能的实施方式中，所述比较单元1000还用于通过下列方式确定所述最大业务请求队列长度：
根据发送给所述被调动微服务节点的业务请求的延迟确定所述最大业务请求队列长度。
在一种可能的实施方式中，所述比较单元1000具体用于：
每隔时长确定所述预设时长内发送给所述被调动微服务节点的业务请求的延迟；
若所述延迟大于与所述延迟对应的阈值，则减小所述最大业务请求队列长度；
若所述延迟不大于与所述延迟对应的阈值，则增大所述最大业务请求队列长度。
在一种可能的实施方式中，若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，则所述延迟对应的阈值为预设的平均延迟阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，则所述阈值为预设的比例阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，则所述延迟对应的阈值为预设的第一指定延迟阈值，其中M为正整数，且M是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与m％的乘积确定的，m为正数；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟，则所述延迟对应的阈值为预设的第二指定延迟阈值，其中N为正整数，且N是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与n％的乘积确定的，n为正数。
在一种可能的实施方式中，所述比较单元1000具体用于：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长；
将所述最大业务请求队列长度增大所述第一调整步长，并将增大所述第一调整步长后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度；和/或
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长；
将所述业务请求队列长度减小所述第二调整步长，并将减小所述第二调整步长后的业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度。
在一种可能的实施方式中，所述比较单元1000具体用于：
根据差值范围与第一调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第一调整步长；和/或
所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长的步骤包括：
根据差值范围与第二调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第二调整步长。
在一种可能的实施方式中，所述第一处理单元1001具体用于：
若根据所述业务请求的类型确定将所述业务请求暂停处理，则将与所述业务请求的类型对应的预设结果作为所述业务请求的处理结果；或
若根据所述业务请求的类型确定将所述业务请求延迟处理，则在与所述业务请求的类型对应的预设等待时长到达后对所述业务请求恢复处理。
关于上述实施例中的装置，其中各个单元执行请求的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
图11是根据一示例性实施例示出的一种电子设备1100的框图，该装置包括：
处理器1110；
用于存储所述处理器1110可执行指令的存储器1120；
其中，所述处理器1110被配置为执行所述指令，以实现本公开实施例中的请求降级处理方法。
在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器1120，上述指令可由电子设备1100的处理器1110执行以完成上述方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本公开实施例还提供一种计算机程序产品，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行实现本公开实施例上述任意一项请求降级处理方法或任意一项请求降级处理方法任一可能涉及的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (12)

1.一种请求降级处理方法，其特征在于，包括：
如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与所述被调动微服务节点对应的最大业务请求队列长度，其中所述业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量；
若所述业务请求队列长度不小于所述被调动微服务节点对应的最大业务请求队列长度，则基于所述业务请求的类型进行相应的降级处理；
所述最大业务请求队列长度是通过如下方式确定的：每隔时长确定预设时长内发送给所述被调动微服务节点的业务请求的延迟；若所述延迟大于与所述延迟对应的阈值，则减小所述最大业务请求队列长度；若所述延迟不大于与所述延迟对应的阈值，则增大所述最大业务请求队列长度；所述延迟为，所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，或所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，或所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，或所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟；其中，M、N为正整数；
其中，基于所述业务请求的类型进行相应的降级处理的步骤，包括：
若根据所述业务请求的类型确定将所述业务请求暂停处理，则将与所述业务请求的类型对应的预设结果作为所述业务请求的处理结果；或
若根据所述业务请求的类型确定将所述业务请求延迟处理，则在与所述业务请求的类型对应的预设等待时长到达后对所述业务请求恢复处理。
2.根据权利要求1所述的请求降级处理方法，其特征在于，所述方法还包括：
若所述业务请求队列长度小于所述被调动微服务节点对应的最大业务请求队列长度，则将所述业务请求队列长度增大指定步长，并将所述业务请求发送给所述被调动微服务节点；
在接收到所述被调动微服务节点返回的所述业务请求对应的处理结果后，将所述业务请求队列长度减小所述指定步长。
3.根据权利要求1所述的请求降级处理方法，其特征在于，若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，则所述延迟对应的阈值为预设的平均延迟阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，则所述阈值为预设的比例阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，则所述延迟对应的阈值为预设的第一指定延迟阈值，其中，M是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与m％的乘积确定的，m为正数；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟，则所述延迟对应的阈值为预设的第二指定延迟阈值，其中，N是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与n％的乘积确定的，n为正数。
4.根据权利要求1所述的请求降级处理方法，其特征在于，所述增大所述最大业务请求队列长度的步骤包括：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长；
将所述最大业务请求队列长度增大所述第一调整步长，并将增大所述第一调整步长后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度；和/或
所述减小所述最大业务请求队列长度的步骤包括：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长；
将所述业务请求队列长度减小所述第二调整步长，并将减小所述第二调整步长后的业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度。
5.根据权利要求4所述的请求降级处理方法，其特征在于，所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长的步骤包括：
根据差值范围与第一调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第一调整步长；和/或
所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长的步骤包括：
根据差值范围与第二调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第二调整步长。
6.一种请求降级处理装置，其特征在于，包括：
比较单元，被配置为执行如果需要向被调动微服务节点发送业务请求，比较业务请求队列长度与所述被调动微服务节点对应的最大业务请求队列长度，其中所述业务请求队列长度表示已发送给所述被调动微服务节点且未接收到所述被调动微服务节点返回的结果的业务请求的数量；
第一处理单元，被配置为执行若所述业务请求队列长度不小于所述被调动微服务节点对应的最大业务请求队列长度，则基于所述业务请求的类型进行相应的降级处理；
所述比较单元还用于通过如下方式确定所述最大业务请求队列长度：每隔时长确定预设时长内发送给所述被调动微服务节点的业务请求的延迟；若所述延迟大于与所述延迟对应的阈值，则减小所述最大业务请求队列长度；若所述延迟不大于与所述延迟对应的阈值，则增大所述最大业务请求队列长度；所述延迟为，所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，或所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，或所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，或所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟；其中，M、N为正整数；
其中，所述第一处理单元具体用于：
若根据所述业务请求的类型确定将所述业务请求暂停处理，则将与所述业务请求的类型对应的预设结果作为所述业务请求的处理结果；或
若根据所述业务请求的类型确定将所述业务请求延迟处理，则在与所述业务请求的类型对应的预设等待时长到达后对所述业务请求恢复处理。
7.根据权利要求6所述的请求降级处理装置，其特征在于，所述装置还包括：
发送单元，被配置为执行若所述业务请求队列长度小于所述被调动微服务节点对应的最大业务请求队列长度，则将所述业务请求队列长度增大指定步长，并将所述业务请求发送给所述被调动微服务节点；
第二处理单元，被配置为执行在接收到所述被调动微服务节点返回的所述业务请求对应的处理结果后，将所述业务请求队列长度减小所述指定步长。
8.根据权利要求6所述的请求降级处理装置，其特征在于，若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的平均值，则所述延迟对应的阈值为预设的平均延迟阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟的标准差与所述所有业务请求的延迟的平均值的比值，则所述阈值为预设的比例阈值；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中最大的M个延迟的平均值，则所述延迟对应的阈值为预设的第一指定延迟阈值，其中，M是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与m％的乘积确定的，m为正数；或
若所述延迟为所述预设时长内发送给所述被调动微服务节点的所有业务请求的延迟中的第N个延迟，则所述延迟对应的阈值为预设的第二指定延迟阈值，其中，N是根据所述预设时长内发送给所述被调动微服务节点的所有业务请求的数量与n％的乘积确定的，n为正数。
9.根据权利要求6所述的请求降级处理装置，其特征在于，所述比较单元具体用于：
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第一调整步长；
将所述最大业务请求队列长度增大所述第一调整步长，并将增大所述第一调整步长后的最大业务请求队列长度与预设最大队列长度中的最小值作为增大后的最大业务请求队列长度；和/或
根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长；
将所述业务请求队列长度减小所述第二调整步长，并将减小所述第二调整步长后的业务请求队列长度与预设最小队列长度中的最大值作为减小后的最大业务请求队列长度。
10.根据权利要求9所述的请求降级处理装置，其特征在于，所述比较单元具体用于：
根据差值范围与第一调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第一调整步长；和/或
所述根据所述延迟以及与所述延迟对应的阈值之间的差值确定第二调整步长的步骤包括：
根据差值范围与第二调整步长之间的对应关系确定所述延迟以及与所述延迟对应的阈值之间的差值所属的差值范围对应的第二调整步长。
11.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至权利要求5中任一项所述的请求降级处理方法。
12.一种存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至权利要求5中任一项所述的请求降级处理方法。
CN201910744178.XA 2019-08-13 2019-08-13 请求降级处理方法、装置、电子设备及存储介质 Active CN110505155B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910744178.XA CN110505155B (zh) 2019-08-13 2019-08-13 请求降级处理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910744178.XA CN110505155B (zh) 2019-08-13 2019-08-13 请求降级处理方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN110505155A CN110505155A (zh) 2019-11-26
CN110505155B true CN110505155B (zh) 2023-12-08

Family

ID=68586578

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910744178.XA Active CN110505155B (zh) 2019-08-13 2019-08-13 请求降级处理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN110505155B (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111158904A (zh) * 2019-12-14 2020-05-15 珠海金智维信息科技有限公司 一种任务调度方法、装置、服务器及介质
CN111181777B (zh) * 2019-12-17 2022-09-20 深圳前海环融联易信息科技服务有限公司 一种服务降级的方法、装置、计算机设备及存储介质
CN111563608B (zh) * 2019-12-20 2023-08-01 江苏金智教育信息股份有限公司 一种公开课座位预定缓存系统和方法
CN115868145A (zh) * 2020-06-30 2023-03-28 华为技术有限公司 一种通信方法及相关设备
CN112306659B (zh) * 2020-11-02 2024-03-15 北京中电普华信息技术有限公司 一种应用的降级保护方法及业务处理系统
CN112383639B (zh) * 2020-12-02 2022-02-22 北京达佳互联信息技术有限公司 微服务均衡方法及装置
CN113778730B (zh) * 2021-01-28 2024-04-05 北京京东乾石科技有限公司 分布式系统的服务降级方法和装置
CN113489739B (zh) * 2021-07-16 2024-03-08 北京顶象技术有限公司 基于CDN的抗DDoS攻击的业务稳定性方法和装置
CN113986391B (zh) * 2021-10-29 2024-06-25 杭州网易云音乐科技有限公司 请求处理方法、装置、介质和计算设备
CN115002044B (zh) * 2022-05-26 2024-03-19 平安银行股份有限公司 控制数据传输的方法、装置、计算机设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009032083A (ja) * 2007-07-27 2009-02-12 Nippon Telegr & Teleph Corp <Ntt> 負荷制御装置及び方法及びプログラム
CN102684988A (zh) * 2006-04-26 2012-09-19 日本电信电话株式会社 负荷控制装置及其方法
CN109167761A (zh) * 2018-08-14 2019-01-08 河南恒茂创远科技股份有限公司 一种请求自动处理的方法及装置
CN109189856A (zh) * 2018-08-15 2019-01-11 中国联合网络通信集团有限公司 分布式数据库服务管理方法、装置、服务器及存储介质
CN109684105A (zh) * 2018-12-18 2019-04-26 中国平安人寿保险股份有限公司 在微服务架构下对请求进行控制的方法、设备和存储介质
CN110109766A (zh) * 2019-05-23 2019-08-09 贵阳块数据城市建设有限公司 数据请求方法、装置、系统、数据转发装置及存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8553545B2 (en) * 2010-06-22 2013-10-08 Verizon Patent And Licensing Inc. Congestion buffer control in wireless networks
WO2014144419A2 (en) * 2013-03-15 2014-09-18 Master Lock Company Networked security system
US9913305B2 (en) * 2014-08-11 2018-03-06 Intel IP Corporation Systems, methods, and devices for congestion control on a mobile network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102684988A (zh) * 2006-04-26 2012-09-19 日本电信电话株式会社 负荷控制装置及其方法
JP2009032083A (ja) * 2007-07-27 2009-02-12 Nippon Telegr & Teleph Corp <Ntt> 負荷制御装置及び方法及びプログラム
CN109167761A (zh) * 2018-08-14 2019-01-08 河南恒茂创远科技股份有限公司 一种请求自动处理的方法及装置
CN109189856A (zh) * 2018-08-15 2019-01-11 中国联合网络通信集团有限公司 分布式数据库服务管理方法、装置、服务器及存储介质
CN109684105A (zh) * 2018-12-18 2019-04-26 中国平安人寿保险股份有限公司 在微服务架构下对请求进行控制的方法、设备和存储介质
CN110109766A (zh) * 2019-05-23 2019-08-09 贵阳块数据城市建设有限公司 数据请求方法、装置、系统、数据转发装置及存储介质

Also Published As

Publication number Publication date
CN110505155A (zh) 2019-11-26

Similar Documents

Publication Publication Date Title
CN110505155B (zh) 请求降级处理方法、装置、电子设备及存储介质
US10447789B2 (en) Distributed flow control
US8275787B2 (en) System for managing data collection processes
US10389801B2 (en) Service request processing method, related apparatus, and system
US9948791B2 (en) Sharing group notification
CN116547958A (zh) 用于网络功能选择的排名处理的方法、系统和计算机可读介质
CN108600005A (zh) 一种防御微服务雪崩效应的方法
CN110069337B (zh) 一种容灾降级的方法和装置
CN110351366A (zh) 一种互联网应用的服务调度方法、系统及计算机可读存储介质
JP7103705B1 (ja) クラスタに基づく容量縮小処理方法及び装置
CN108228393A (zh) 一种可扩展的大数据高可用的实现方法
CN112416594A (zh) 一种微服务分配方法、电子设备和计算机存储介质
CN112448987B (zh) 一种熔断降级的触发方法、系统和存储介质
CN109815204A (zh) 一种基于拥塞感知的元数据请求分发方法及设备
CN105430028B (zh) 服务调用方法、提供方法及节点
CN107766156B (zh) 任务处理方法及装置
US20150372895A1 (en) Proactive Change of Communication Models
CN113326100A (zh) 一种集群管理方法、装置、设备及计算机存储介质
CN109104334B (zh) 监控系统中节点的管理方法和装置
JP5829230B2 (ja) 管理システム及び管理方法
CN111835797A (zh) 一种数据处理方法、装置及设备
US11943284B2 (en) Overload protection for edge cluster using two tier reinforcement learning models
CN115776510A (zh) 心跳包的控制方法和装置、处理器及电子设备
CN114816713A (zh) 函数调用方法及系统
CN110865895B (zh) 访问流量控制方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant