一种网络请求处理方法、装置、电子设备、芯片及介质

技术领域

本公开涉及云计算领域，尤其涉及一种网络请求处理方法、装置、电子设备、芯片及介质。

背景技术

随着互联网技术的迅猛发展，网络业务不断发展壮大，把应用部署到云上已经成为了一种趋势。在云计算领域中，基础设施即服务(IaaS)技术已经非常成熟，在业界得到了广泛应用。万维网(World Wide Web，web)控制台是用户访问，操作云上资源的重要入口，web控制台的响应速度，响应及时率一直是用户使用云上资源体验的重要指标。

而对于由于业务繁忙，网络拥塞等原因造成超文本传输协议(HypertextTransfer Protocol，http)请求无法及时返回的情况，很容易造成用户体验不佳的问题。相关技术中，对于http请求超时，仅仅通过判断http请求超时时长是否超过总超时阈值处理http请求。存在http超时处理的笼统和粗糙，用户体验差的问题。

发明内容

本公开提供一种网络请求处理方法、装置、电子设备、芯片及介质，针对http超时处理的笼统和粗糙，用户体验差的问题，通过http请求链路中的总超时阈值和不同服务中的分段超时阈值的设置，对各种超时情况进行了细粒度的处理并及时反馈给用户处理结果，提升了用户体验。

本公开的第一方面实施例提出了一种网络请求处理方法，该方法包括：

根据从客户端获取http请求中的链路数据，确定总超时阈值；

通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间；

根据所述总处理时间、所述总超时阈值、所述分段处理时间、预设的分段超时阈值，确定所述http请求的处理方式。

本公开的一种实施例中，所述根据所述总处理时间、所述总超时阈值、所述分段处理时间、预设的分段超时阈值，确定所述http请求的处理方式，包括：

若总处理时间未超过总超时阈值，或者，若总处理时间超过总超时阈值，且分段处理时间未超过预设的分段超时阈值，则向客户端返回http请求的处理结果；

若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，则发起补偿查询，并向客户端发送反馈消息。

本公开的一种实施例中，根据从客户端获取的http请求中的链路数据，确定总超时阈值包括：

对http请求相关的多次请求的时长进行分析，确定基准时长，基准时长为多次请求的时长的四分位数；

获取预设的链路外部最大时长和不同服务之间的保护间隔时长；

根据基准时长、链路外部最大时长、保护间隔时长，确定总超时阈值。

本公开的一种实施例中，总处理时间为从http请求到达服务端开始至服务端发出http响应的时间，分段处理时间为http请求到达对应的服务开始至服务发出响应的时间。

本公开的一种实施例中，方法还包括：

根据http请求的链路数据，确定任务队列的初始容量大小；

若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值时，则确定任务队列已满，向客户端发送失败反馈消息。

本公开的一种实施例中，若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，则发起补偿查询，并向客户端发送反馈消息包括：

若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，且任务队列未满，则将http请求添加至任务队列；

以预设轮询周期，在服务端周期性地查询http请求的处理状态，得到轮询结果；

若轮询结果指示http请求正在处理中，则继续轮询直至到达预设轮询时长；以及若仍未得到http请求的处理结果，则向客户端发送失败反馈消息；

若轮询结果指示http请求已处理完成，则向客户端发送http请求的处理结果。

本公开的一种实施例中，方法还包括：

若任务队列中的http请求数量达到初始容量大小持续预设时长，则将初始容量大小缩减为第一容量大小；

当任务队列中的http请求数量小于第一容量大小时，开放任务队列并允许新的http请求入队；

若任务队列http请求数量达到第一容量大小持续预设时长，则将第一容量大小缩减为零；

若任务队列http请求数量未在预设时长内达到第一容量大小，则将第一容量大小扩大为初始容量大小。

本公开的第二方面实施例提出了一种网络请求处理装置，该装置包括：

第一确定模块，用于根据从客户端获取的http请求中的链路数据，确定总超时阈值；

第二确定模块，用于通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间；

第三确定模块，用于根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。

本公开的第三方面实施例提出了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行本公开第一方面实施例中任一项的方法。

本公开的第四方面实施例提出了一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，计算机指令用于使计算机执行本公开第一方面实施例中的方法。

本公开的第五方面实施例提出了一种计算机程序产品，其特征在于，包括计算机程序，计算机程序在被处理器执行时实现本公开第一方面实施例中任一项的方法。

综上，根据本公开提出的网络请求处理方法，根据从客户端获取http请求中的链路数据，确定总超时阈值，为总超时时长内监听链路数据提供了时间参考；通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间，为确定超时中运行的各个子服务的状态提供了时间依据；根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。实现了对各种超时情况进行细粒度的处理并及时反馈给用户处理结果提升了用户体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1为本公开实施例的一种网络请求处理方法的流程图；

图2为本公开实施例的一种根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式的流程图；

图3为本公开实施例的一种根据从客户端获取的http请求中的链路数据，确定总超时阈值的流程图；

图4为本实施例的一种计时器的示意图；

图5为公开实施例的一种网络请求处理方法的流程图；

图6为本公开实施例的一种若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，发起补偿查询，并向客户端发送反馈消息的流程图；

图7为本实施例的一种超时设置的示意图；

图8为本实施例的一种分段超时设置的示意图；

图9为本实施例的一种链路总超时时长未超过内部交互时间门限的超时处理示意图；

图10为本实施例的一种链路总超时时长超过内部交互时间门限的超时处理示意图；

图11为本公开实施例的一种网络请求处理的流程图；

图12为队列达到容量上限后主机缩容的示意图；

图13为本公开实施例的一种队列熔断及恢复过程的示意图；

图14为本公开实施例的一种网络请求处理系统的架构示意图；

图15为本公开实施例的一种网络请求处理装置的结构示意图；

图16是根据一示例性实施例示出的一种用于实现本公开网络请求处理方法的电子设备的框图。

具体实施方式

下面详细描述本公开的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号标识相同或类似的原件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本公开，而不能理解为对本公开的限制。

首先对本公开中的相关词语进行简单介绍：

http：在本公开中，是指超文本传输协议，是一种用于分布式、协作式和超媒体信息系统的应用层协议。http为整个web的数据通信的基础，在web开发领域有着至关重要的地位。具体而言，http主要有以下关键特点。

请求-响应模型：http是一个基于请求-响应模式的协议，客户端通过发送http请求到服务器，并接收服务器返回的http响应来完成一次通信过程。

无状态性：http通常是无状态的，这意味着服务器不会保留关于客户端之前请求或响应的内容，除非通过像cookie这样的机制来显式地维护状态。

灵活性：http允许数据传输灵活多样，内容可以是超文本标记语言(HyperTextMarkup Language，HTML)文档、图片、视频流等，支持多种类型的媒体格式。

可靠性：http通常运行在传输控制协议(Transmission Control Protocol，TCP)协议之上，确保数据包的可靠传输，如果发生数据丢失或错误，会由TCP协议负责重传。

可扩展性：http具备良好的可扩展性，可以通过添加新的http头、方法或状态码来实现功能的扩展。

简单性：尽管http的功能非常强大，但它的设计却非常简单，这使得它易于实现和部署，也便于开发者理解和使用。

广泛支持：几乎所有的现代操作系统都内建了对http的支持，而且大多数编程语言都有处理http请求和响应的库或框架。

链路：在本公开中，指数据链路，既可以为网络中两个节点之间的逻辑通道，也可以为物理介质，用于实现数据传输。

同步任务：在本公开中，是指收到任务请求后，响应该任务请求进行处理，将处理的结果即时反馈给该任务请求发出方的任务，发出方和接收方需要使用同一的时钟信号来保持完全的同步状态。

异步任务：在本公开中，是指收到任务请求后，将该异步任务添加到待处理任务列表中进行处理，且任务之间不需要严格的时钟同步的任务。

相关技术中，通过web控制台使用云上资源。在web端，响应速度、响应及时率作为衡量使用体验的重要指标。而由于在云端业务繁忙、网络拥塞等原因造成http请求无法及时返回，给用户带来响应速度慢、甚至中断的不好体验。对于该超时接口，主要使用建立熔断机制处理，但依旧存在状态改变无法知晓，熔断保护期内无法快速恢复，用户体验较差等问题。

本公开旨在解决上述问题，让web端对于云端资源的控制在http请求超时之前返回中间态结果，同步了状态改变信息，控制任务队列大小，在波动时不直接熔断而只拒绝超时任务，确保了任务的快速恢复，提升了用户体验。

本公开提出的方法应用于网络请求处理任务，其应用具有丰富的场景，可以应用于需要高可用性和弹性的应用场景或领域中。以下是一些具体的应用实例：

在线服务平台：如电子商务网站、在线预订系统，在高流量期间通过控制任务队列大小和适时拒绝超时任务，保证系统的响应时间和稳定性，从而维护良好的用户体验。

云计算服务：云服务提供商可以通过该机制有效管理计算资源和网络请求，避免因过载而导致的服务中断，确保服务的持续性和可靠性。

实时数据处理：对于需要快速响应的实时数据分析和处理系统，例如金融交易系统、物联网设备管理平台，这种机制可以帮助快速从临时的网络波动中恢复，减少数据丢失和错误。

媒体和流服务：视频流服务、在线游戏和其他媒体服务平台可利用此机制在网络状态不佳时适当调整传输速率或质量，防止服务中断。

企业级应用：大型企业的内部系统，如企业资源计划、客户关系管理等，这些系统对业务连续性要求极高，使用该机制可以在遇到网络问题时保持稳定运作。

应用程序接口网关：作为多个微服务或后端服务的统一入口，应用程序接口网关可以使用这种机制来优化请求路由，防止某些服务的过载影响到整个系统的表现。

移动应用后端：移动应用通常依赖于稳定的后端服务，该机制可以帮助后端服务在应对突发的高并发请求时保持稳定，为移动用户提供无缝的体验。

紧急响应系统：如灾害预警、公共安全和卫生事件响应系统，这类系统需在关键时刻提供可靠的服务，该机制有助于在网络不稳定情况下仍能传递关键信息。

支付和交易系统：支付网关和交易平台需处理大量并发事务，该机制能够确保即使在负载高峰时期也能处理请求，降低因超时而引发的交易失败。

总的来说，这种机制提高了系统在面对不确定性网络条件时的鲁棒性，进而提升了整体的服务质量和用户满意度。

在本公开实施例中对应用场景不予限制。

下面结合附图对本公开所提供的网络请求处理方法进行详细介绍。

图1为本公开实施例的一种网络请求处理方法的流程图。本方法执行于服务器端。通常以软件框架的形式存在于服务器端。如图1所示的实施例，该网络请求处理方法包括：

步骤101，根据从客户端获取的http请求中的链路数据，确定总超时阈值。

本实施例中，客户端是指向服务器端发起http请求的web端。http请求是指web端向服务器端发出的基于超文本传输协议的请求。服务器端获得客户端发起的http请求。总超时阈值为一个时间值，用于衡量总计时器记录的较长的时长。一个http请求对应一个链路数据，通过http请求的url和method确定请求方法，通过对其最近n次请求的时长进行分析。利用多次请求时长得到的基准时长和链路外部最长超时时长与保护间隔的差值的比较结果，确定总超时阈值。

步骤102，通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间。

本实施例中，链路总计时器是指用于记录http请求在服务端处理时间的计时器。服务端是指web客户端所控制的云端主机。总处理时间是指http请求在服务端收到直到服务端发出处理结果的时长。分段计时器是指记录http请求在服务端中各个服务中分别记录的每个服务处理的时长的计时器。分段处理时间是指分段计时器记录的http请求在服务端中各个服务的处理时长，即收到时刻到发送处理结果时刻的时长。链路总计时器可得到http请求在服务端的总处理时间，分段计时器可得到该http请求在链路中各个服务的分段处理时间。

步骤103，根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。

本实施例中，为了根据http请求当前的网络状况进行http请求的处理，根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。优选的，通过总处理时间、总超时阈值，确定http请求的处理方式。或者，通过总处理时间、总超时阈值、分段处理时间、分段超时阈值，确定http请求的处理方式。

综上，根据本公开提出的网络请求处理方法，从客户端获取http请求，服务端与客户端建立了网络连接；根据http请求的链路数据，确定总超时阈值，为总超时时长内监听链路数据提供了时间参考；通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间，为确定超时中运行的各个子服务的状态提供了时间依据；根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。实现了对各种超时情况进行细粒度的处理并及时反馈给用户处理结果，提升了用户体验。

图2为本公开实施例的一种根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式的流程图。图2是对图1的步骤103的进一步解释，基于图2所示的实施例，包括如下步骤：

步骤201，若总处理时间未超过总超时阈值，或者，若总处理时间超过总超时阈值，且分段处理时间未超过预设的分段超时阈值，则向客户端返回http请求的处理结果。

本实施例中，分段超时阈值为一个时间值，用于衡量分段计时器记录的较长的时长。如果总处理时间小于或等于总超时阈值，即，http请求在服务端的总处理时间并未超时，或者，如果总处理时间大于总超时阈值，且分段处理时间小于或等于预设的分段超时阈值，即，http请求在服务端的总处理时间已超时，但是分段处理时间并未超时，那么，将http请求的处理结果发送至web客户端。

步骤202，若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，则发起补偿查询，并向客户端发送反馈消息。

本实施例中，补偿查询是指对消息推送模块发起的对于服务端的处理http请求任务补偿的资源。反馈消息是指服务端的各个服务在处理http请求过程中，，返回的处理结果，包括处理完成、处理中、处理异常等信息。如果http请求在服务端的总处理时间超过了总超时阈值，同时分段处理时间也超过了分段超时阈值，那么对该超时的http请求发起补偿查询，并向web客户端发送该http请求的处理结果。

本实施例中，若总处理时间未超过总超时阈值，或者，若总处理时间超过总超时阈值，且分段处理时间未超过预设的分段超时阈值，向客户端返回http请求的处理结果，避免了超时无法收到状态回复的情况，完成了服务端对于web客户端的状态及时通知；若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，发起补偿查询，并向客户端发送反馈消息，有效缩短了业务在熔断下的不可用时长。提升了超时中对于业务的各个服务的运行状态的感知，实现了超时熔断保护期的快速恢复，提高了用户体验。

图3为本公开实施例的一种根据从客户端获取的http请求中的链路数据，确定总超时阈值的流程图。图3是对图1的步骤101做的进一步说明，基于图3所示的实施例，包括如下步骤：

步骤301，对http请求相关的多次请求的时长进行分析，确定基准时长。

本实施例中，基准时长是指多次请求的时长的四分位数。根据http请求url和method确定唯一请求方法，通过对最近多次请求的时长进行分析，取四分位数中的上四分位数Q3作为基准时长T

步骤302，获取预设的链路外部最大时长和不同服务之间的保护间隔时长。

本实施例中，链路外部最大时长是指预设的链路最大超时时长值Tmax，保护间隔时长是指从上一个服务1发到下一个服务2之间的用时θ。获取链路外部最大时长和保护间隔时长。

步骤303，根据基准时长、链路外部最大时长、保护间隔时长，确定总超时阈值。本实施例中，根据链路外部最大时长Tmax和保护间隔时长θ的差值，，可得到外部超时时长T

式中，当基准时长T

本实施例中，根据http请求的基准时长、链路外部最大时长、保护间隔时长，确定了总超时阈值，为网络请求超时处理提供了总超时时长的依据。

本公开实施例中，总处理时间为从http请求到达服务端开始至服务端发出http响应的时间，分段处理时间为http请求到达对应的服务开始至服务发出响应的时间。

本实施的一种实施方式中，图4为本实施例的一种计时器的示意图。如图4所示，计时器分为链路总计时器和分段计时器。链路总计时器为从http请求发出开始，直到接收到http请求的响应，或者超时的时间记录。分段计时器为服务内部调用请求开始，到服务内部调用结束，或者超时的时间记录。服务端接收到web客户端发起的http请求，记录此时时间为t1。该http请求解析为请求1向内部服务的服务1进行访问，记录此时时间为t2。服务1的内部模块服务2收到请求1解析到的请求2的访问，记录此时时间为t3。服务2向服务1返回该请求2的处理结果，记录此时时间为t4。服务1向服务端返回请求1的处理结果，记录此时时间为t5。服务端收到http请求的响应的时间为t6。那么，链路总计时器记录的时长T1＝t6-t1，分段计时器1记录的时长T2＝t5-t2，分段计时器2记录的时长T3＝t4-t3。通过使用分段计时器和链路总计时器，确定了响应http请求过程中，所使用到的各个中间服务，为网络请求处理确定了中间状态的改变过程，明确了网络请求的状态，提升了用户对于网络请求响应的感知，提高了用户体验。

图5为公开实施例的一种网络请求处理方法的流程图。图5是对图1的网络请求处理方法的进一步说明，基于图5所示的实施例，包括如下步骤：

步骤501，根据http请求的链路数据，确定任务队列的初始容量大小。

本实施例中，http请求的链路数据中包括队列容量的上限QC

通过本式可表明，T

步骤502，若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值时，则确定任务队列已满，向客户端发送失败反馈消息。

本实施例中，如果总处理时间Ttotal超过总超时阈值Touter，并且分段处理时间超过分段超时阈值Tinner时。即，当前http请求在各个服务中的处理均超时，且整体处理时长超时，同时，当前任务队列已达到队列容量的上限，那么该http请求的处理判定为失败，向客户端发送失败的反馈消息。

本实施例中，当处理http请求的总处理时间和分段处理时间均超时，且任务队列已被占满，则给客户端发送请求失败的消息，从而及时告知客户端访问失败的状态信息，避免了网络请求超时中状态未知的情况发生。

图6为本公开实施例的一种若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，则发起补偿查询，并向客户端发送反馈消息的流程图。图6是对图2的步骤202进行的具体说明，基于图6所示的实施例，包括如下步骤：

步骤601，若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，且任务队列未满，则将http请求添加至任务队列。

本实施例中，如果总处理时间超过总超时阈值Touter，而且分段处理时间超过分段超时阈值Tinner，同时任务队列中的任务数目还未达到任务容量的上限值QC

步骤602，以预设轮询周期，在服务端周期性地查询http请求的处理状态，得到轮询结果。

本实施例中，预设轮询周期是指查询http请求的循环次数。在服务端以预设轮询周期对http请求的处理状态进行周期性的查询，得到轮询的结果。以表示http请求的处理状态。由于服务端中本身还涉及链路调用，发出请求同时通知超时处理框架启动分段计时器，如果当前http请求已经使用时间为T

其中，θ为保护间隔，n为当前http请求链路中当前框架启动过的计时器个数。

步骤603，若轮询结果指示http请求正在处理中，则继续轮询直至到达预设轮询时长；以及若仍未得到http请求的处理结果，则向客户端发送失败反馈消息。

本实施例中，如果轮询结果指示http请求正在处理中，那么继续轮询直到达到预设轮询时长。如果依旧未能得到http请求的处理结果，那么向客户端发送处理失败的反馈消息。

步骤604，若轮询结果指示http请求已处理完成，则向客户端发送http请求的处理结果。

本实施例中，如果轮询结果指示http请求已处理完成，说明该http请求在服务端处理正常，那么将该http请求的处理结果发送给客户端。

本实施例的一种实施方式中，图7为本实施例的一种超时设置的示意图。如图7所示，web客户端(浏览器)发起http请求到超时处理框架，由超时处理框架转发到服务端，服务端的内部服务包括server服务端1、server服务端2、server服务端3和server服务端4，外部服务包括外部服务1。服务端1在收到http请求时，启动链路总计时器，根据超时处理框架超时时间Touter确定计时器的超时时间。服务端1需要调用服务端2和服务端3时，向服务端2和服务端3分别发起请求，服务端3调用外部服务1完成了该http请求的处理或者服务端3直接完成了该http请求的处理。服务端2调用服务端4，服务端4完成了该http请求的处理。那么，完成该http请求的处理被返回的时间被链路总计时器记录为Touter。Touter时长中包含了当前请求已经使用的时间Tu和逐级嵌套调用服务的时间Ts，以及处理完http请求到返回客户端的时间θ。如果内部服务处理超时，则对该http请求进行超时补偿，将该http请求的任务加入到消息队列中。

本实施例的一种实施方式中，图8为本实施例的一种分段超时设置的示意图。如图8所示，服务端收到客户端发出的http请求，服务端的链路总计时器、分段计时器开始计时，在处理该http请求过程中，需要通过请求1调用服务1，在服务1收到请求1时，服务1的总链路计时器和分段计时器开始计时。为了处理该请求1，服务1需要调用服务2，在服务2收到服务1发起的请求2时，服务2的总链路计时器和分段计时器开始计时。为了处理该请求2，服务2需要调用服务3，在服务3收到服务2发起的请求3时，服务3的总链路计时器和分段计时器开始计时。服务3对该请求3做出响应，服务3的总链路计时器记录时间为Touter-3。服务2对该请求2做出响应，服务2记录的总链路计时器记录时间为Touter-2，服务1对该请求1做出响应，服务1的总链路计时器记录时间为Touter-1，服务端对该http请求做出http响应，服务端的总链路计时器的记录时间为Touter。其中，后一个服务做出对于后一个请求的响应时间到当前服务做出对于当前请求的响应时间之间存在的时间间隔为θ，链路总超时时长Ttotal＝T

本实施例的一种实施方式中，图9为本实施例的一种链路总超时时长未超过内部交互时间门限的超时处理示意图。如图9所示，超时框架(超时处理框架)收到客户端的http请求，向服务端转发该请求，链路总计时器和分段计时器均开始计时，当链路总计时器记录时长超过总超时阈值Touter，那么超时处理框架向客户端返回http请求处理的中间状态。如果分段计时器记录到完成了服务的服务实际处理时长，则服务端将该http请求的处理结果通过消息推送模块推送至客户端。在这种情况下，即链路总超时时长Touter未超过内部交互时间门限Tinner，通过消息推送方式反馈http请求的处理结果到web客户端和上级服务。

本实施例的一种实施方式中，图10为本实施例的一种链路总超时时长超过内部交互时间门限的超时处理示意图。如图10所示，超时框架(超时处理框架)在收到web客户端的http请求后，链路总计时器记录http请求在服务端的总处理时间在超过总超时阈值Touter，此时超时处理框架向客户端返回http请求的中间状态。超时处理框架将其转发到服务端进行处理，分段计时器开始计时，记录http请求的分段处理时间超过分段超时阈值Tinner。如果内部分段处理时间Tinner超过了链路总处理时间Touter，那么向任务队列中加入补偿任务队列。通知消息推送模块向客户端进行消息推送返回。并且消息推送模块向服务端发起补偿查询并获得补偿结果。

本实施例中，当总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，发起补偿查询，并向客户端发送反馈消息，以确保对于http请求超时后处理状态的及时通知。

图11为本公开实施例的一种网络请求处理的流程图。图11是对图1进行的进一步说明，基于图11所示的实施例，包括以下步骤：

步骤1101，若任务队列中的http请求数量达到初始容量大小持续预设时长，则将初始容量大小缩减为第一容量大小。

本实施例中，第一容量大小为任务队列中的http请求数量，少于初始容量大小。如果服务端的任务队列中http请求数量达到初始容量大小，并且持续预设时长，说明当前任务队列已满负荷长时间运行中，需要对将初始容量大小进行缩减至第一容量大小。

步骤1102，当任务队列中的http请求数量小于第一容量大小时，开放任务队列并允许新的http请求入队。

本实施例中，如果任务队列中的http请求数量小于第一容量大小时，说明当前任务队列中的http请求数目较少，任务队列的容量较为充足，那么开放任务队列并允许新的http请求加入队列中。

步骤1103，若任务队列http请求数量达到第一容量大小持续预设时长，则将第一容量大小缩减为零。

本实施例中，如果任务队列中http请求数量达到了第一容量大小，并且持续了预设时长，说明重新调整后的任务队列的容量再次被占满，且持续了预设时长，需要将第一容量大小缩减为0，从而将任务队列进行清空。

步骤1104，若任务队列http请求数量未在预设时长内达到第一容量大小，则将第一容量大小扩大为初始容量大小。

本实施例中，如果任务队列中http请求数量在预设时长内没有超过第一容量大小，说明在预设时长内任务队列中的任务数量较少且稳定，进而将第一容量大小扩大为初始容量大小。

本实施例的一种实施方式中，图12为队列达到容量上限后主机缩容的示意图。如图12所示，当超时处理框架内对应接口的任务队列达到容量上限后，不再接收新任务，直接返回失败。此时超时处理框架进入以及熔断，即超时熔断。此时超时处理框架对于请求超时的任务，不再返回中间状态，不再转化为异步任务。而是直接返回失败给web客户端或上级服务，同时队列进行逐级缩容，步骤如下：

(1)关闭队列，不再接收新任务，同时采用冷却(cool-down)方式，即逐步缩减队列容量到正常的50％(最小为0)，队列只出不进，对于队列容量在缩减过程中出现不为整数的情况，通过向下取整确定。

(2)当队列中任务小于队列最大容量后，开放队列，让新任务入队，此时队列容量为原先的50％。

(3)如果再次触发了队列的当前容量上限，则继续重复步骤(1)，直到队列容量为0。

本实施例的一种实施方式中，图13为本公开实施例的一种队列熔断及恢复过程的示意图。如图13所示，补偿队列任务到达，判断队列是否触发容量上限，如果队列已触发队列触发容量的上限值，那么丢弃任务，直接返回失败。否则，进一步判断队列是否容量为0，当队列容量为不为0时，将队列容量cool-down到原容量的50％，阻塞任务入队，直接失败。或者，当队列容量为0时，超时处理框架进入二级熔断，即链路熔断，此时超时处理框架标记此接口为阻塞接口，启动预定义的定时探针主动轮询服务检查，确认服务是否恢复。若服务并未恢复，则重新发起主动轮询服务检查，若服务恢复成功，则检查队列中是否有任务，若队列中无任务，则开放队列入队。若队列中存在任务，那么执行等待操作，并判断等待时长是否超过恢复门限值Tx。如果队列经过一段时间未触发队列容量上限，则扩容当前队列容量至当前的2倍。直到达到原先预设的队列容量。

本实施例的一种实施方式中，图14为本公开实施例的一种网络请求处理系统的架构示意图。本系统实际为超时处理框架，运行于服务器中，作为服务器的功能模块以插件的形式存在。例如，Spring框架中存在本超时处理框架作为插件，对超时请求进行处理。如图14所示，内部系统有服务发现和注册的机制，用于实时感知服务的状态，可向服务器发起http请求。外部系统需要通过内部系统向服务端发起http请求。

web客户端向服务器端的超时处理框架发起http请求，首先，启动计时器，处理http请求直到内部系统返回该http请求的处理结果，计时器停止计时，得到该http请求的处理时长。然后，判断该处理时长是否超时，当计时器判断到该处理时长即将超时还未超时，触发定时补偿模式，查询该http请求的下层服务状态，查询已下发的http请求的处理结果，定时补偿任务将该处理结果以消息通知的形式通过消息推送模块发送到内部系统。内部系统收到该消息通知后，回复web客户端该http请求是否被正常执行的结果。当该处理时长已经超时，那么向web客户端返回中间处理结果。

本公开实施例提出了一种网络请求处理方法，从客户端获取http请求，服务端与客户端建立了网络连接；根据http请求的链路数据，确定总超时阈值，为总超时时长内监听链路数据提供了时间参考；通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间，为确定超时中运行的各个子服务的状态提供了时间依据；根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式，特别的，若总处理时间未超过总超时阈值，或者，若总处理时间超过总超时阈值，且分段处理时间未超过预设的分段超时阈值，向客户端返回http请求的处理结果，避免了超时无法收到状态回复的情况，完成了服务端对于web客户端的状态及时通知；若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，发起补偿查询，并向客户端发送反馈消息，有效缩短了业务在熔断下的不可用时长。提升了超时中对于业务的各个服务的运行状态的感知，实现了超时熔断保护期的快速恢复，提高了用户体验。

与上述几种实施例提供的方法相对应，本公开还提供一种网络请求处理装置，由于本公开实施例提供的装置与上述几种实施例提供的方法相对应，因此方法的实施方式也适用于本实施例提供的装置，在本实施例中不再详细描述。

图15为本公开实施例的一种网络请求处理装置1500的结构示意图。如图15所示，该网络请求处理装置包括：

第一确定模块1510，用于根据从客户端获取的http请求中的链路数据，确定总超时阈值；

第二确定模块1520，用于通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间；

第三确定模块1530，用于根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。

在一些实施例中，第三确定模块1530用于：

若总处理时间未超过总超时阈值，或者，若总处理时间超过总超时阈值，且分段处理时间未超过预设的分段超时阈值，则向客户端返回http请求的处理结果；

若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，则发起补偿查询，并向客户端发送反馈消息。

在一些实施例中，第一确定模块1510用于：

对http请求相关的多次请求的时长进行分析，确定基准时长，基准时长为多次请求的时长的四分位数；

获取预设的链路外部最大时长和不同服务之间的保护间隔时长；

根据基准时长、链路外部最大时长、保护间隔时长，确定总超时阈值。

在一些实施例中，总处理时间为从http请求到达服务端开始至服务端发出http响应的时间，分段处理时间为http请求到达对应的服务开始至服务发出响应的时间。

在一些实施例中，装置1500还用于：

根据http请求的链路数据，确定任务队列的初始容量大小；

若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值时，则确定任务队列已满，向客户端发送失败反馈消息。

在一些实施例中，第三确定模块1530采用如下方式若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，则发起补偿查询，并向客户端发送反馈消息：

若总处理时间超过总超时阈值，且分段处理时间超过分段超时阈值，且任务队列未满，则将http请求添加至任务队列；

以预设轮询周期，在服务端周期性地查询http请求的处理状态，得到轮询结果；

若轮询结果指示http请求正在处理中，继续轮询直至到达预设轮询时长，若仍未得到http请求的处理结果，则向客户端发送失败反馈消息；

若轮询结果指示http请求已处理完成，则向客户端发送http请求的处理结果。

在一些实施例中，装置1500还用于：

若任务队列中的http请求数量达到初始容量大小持续预设时长，则将初始容量大小缩减为第一容量大小；

当任务队列中的http请求数量小于第一容量大小时，开放任务队列并允许新的http请求入队；

若任务队列http请求数量达到第一容量大小持续预设时长，则将第一容量大小缩减为零；

若任务队列http请求数量未在预设时长内达到第一容量大小，则将第一容量大小扩大为初始容量大小。

综上，通过网络请求处理装置，从客户端获取http请求；根据http请求的链路数据，确定总超时阈值；通过链路总计时器确定http请求在服务端的总处理时间，以及通过分段计时器确定http请求的链路中各个服务的分段处理时间；根据总处理时间、总超时阈值、分段处理时间、预设的分段超时阈值，确定http请求的处理方式。本装置解决了http超时处理的笼统和粗糙，用户体验差的问题，实现了对各种超时情况进行细粒度的处理并及时反馈给用户处理结果，提升了用户体验。

上述本公开提供的实施例中，对本公开实施例提供的方法及装置进行了介绍。为了实现上述本公开实施例提供的方法中的各功能，电子设备可以包括硬件结构、软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能可以以硬件结构、软件模块、或者硬件结构加软件模块的方式来执行。

图16是根据一示例性实施例示出的一种用于实现上述网络请求处理方法的电子设备1600的框图。

例如，电子设备1600可以是移动电话，计算机，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图16，电子设备1600可以包括以下一个或多个组件：处理组件1602，存储器1604，电源组件1606，多媒体组件1608，音频组件1610，输入/输出(I/O)的接口1612，传感器组件1614，以及通信组件1616。

处理组件1602通常控制电子设备1600的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件1602可以包括一个或多个处理器1620来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件1602可以包括一个或多个模块，便于处理组件1602和其他组件之间的交互。例如，处理组件1602可以包括多媒体模块，以方便多媒体组件1608和处理组件1602之间的交互。

存储器1604被配置为存储各种类型的数据以支持在电子设备600的操作。这些数据的示例包括用于在电子设备1600上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1606为电子设备1600的各种组件提供电力。电源组件1606可以包括电源管理系统，一个或多个电源，及其他与为电子设备1600生成、管理和分配电力相关联的组件。

多媒体组件1608包括在电子设备1600和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1608包括一个前置摄像头和/或后置摄像头。当电子设备1600处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1610被配置为输出和/或输入音频信号。例如，音频组件1610包括一个麦克风(MIC)，当电子设备1600处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1604或经由通信组件1616发送。在一些实施例中，音频组件1610还包括一个扬声器，用于输出音频信号。

I/O接口1612为处理组件1602和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1614包括一个或多个传感器，用于为电子设备1600提供各个方面的状态评估。例如，传感器组件1614可以检测到电子设备1600的打开/关闭状态，组件的相对定位，例如组件为电子设备1600的显示器和小键盘，传感器组件1614还可以检测电子设备1600或电子设备1600一个组件的位置改变，用户与电子设备1600接触的存在或不存在，电子设备1600方位或加速/减速和电子设备1600的温度变化。传感器组件1614可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1614还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1614还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1616被配置为便于电子设备1600和其他设备之间有线或无线方式的通信。电子设备1600可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G LTE、5G NR(NewRadio)或它们的组合。在一个示例性实施例中，通信组件1616经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件1616还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，电子设备1600可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1604，上述指令可由电子设备1600的处理器1620执行以完成上述方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本公开的实施例还提出了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，计算机指令用于使计算机执行本公开上述实施例中描述的网络请求处理方法。

本公开的实施例还提出一种计算机程序产品，包括计算机程序，计算机程序在被处理器执行本公开上述实施例中描述的网络请求处理方法。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本说明书的描述中，参考术语“一个实施方式”、“一些实施方式”、“示意性实施方式”、“示例”、“具体示例”或“一些示例”等的描述意指结合实施方式或示例描述的具体特征、结构、材料或者特点包含于本公开的至少一个实施方式或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施方式或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施方式或示例中以合适的方式结合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本公开的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本公开的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理模块的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(控制方法)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得程序，然后将其存储在计算机存储器中。

应当理解，本公开的实施方式的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本公开的各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。上述提到的存储介质可以是只读存储器，磁盘或光盘等。

尽管上面已经示出和描述了本公开的实施方式，可以理解的是，上述实施方式是示例性的，不能理解为对本公开的限制，本领域的普通技术人员在本公开的范围内可以对上述实施实施进行变化、修改、替换和变型。