CN113268360A - 请求处理方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请公开了一种请求处理方法、装置、服务器及存储介质，属于计算机技术领域。本申请实施例提供的请求处理方法，在目标微服务注册到第一服务器之后，且对外提供服务之前，先通过该第一服务器对被模拟的第一业务请求进行处理，通过处理该第一业务请求在第一服务器中运行处理业务请求的业务组件，实现对业务组件的预热。在预热完成后，再开放服务接口，处理外部的第二业务请求。由于在处理第二业务请求之前，业务组件已经进行了预热，因此，第一服务器可以快速对第二业务请求进行处理。该方法通过对业务组件进行预热可以降低响应首个业务请求的时长，无需查找问题代码以及对问题代码进行优化，节省了大量的人力物力，从而降低了优化成本。

Description

请求处理方法、装置、服务器及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种请求处理方法、装置、服务器及存储介质。

背景技术

为了提高互联网服务的开发效率，微服务架构应运而生。微服务架构是将应用程序按业务逻辑拆分成多个微服务，将多个微服务分别注册到服务器中，从而通过多个微服务来处理该应用程序不同业务的处理请求。对于每个微服务，将该微服务注册到服务器中之后，经常会出现服务器响应该微服务的首个处理请求时间较长的现象，而这种现象会影响用户的使用体验。为了提高用户体验，需要降低微服务响应首个处理请求的时长。

相关技术中，在服务器响应微服务的首个处理请求的时长较长时，开发人员会分析微服务的业务代码，对该业务代码进行优化，以降低服务器响应该微服务的首个处理请求的时长。

但查找问题代码以及对问题代码进行优化均会耗费大量的人力物力，导致优化成本较高。

发明内容

本申请实施例提供了一种请求处理方法、装置、服务器及存储介质,可以降低优化成本。该技术方案如下：

一方面，提供了一种请求处理方法，该方法包括：

在目标微服务注册到第一服务器之后，且对外提供服务之前，获取被模拟的第一业务请求；

通过所述第一服务器处理所述第一业务请求，在所述第一服务器中运行用于处理业务请求的业务组件；

开放用于对外提供服务的服务接口，通过所述服务接口接收外部的第二业务请求，通过所述业务组件，处理所述第二业务请求。

在一种可能的实现方式中，若所述第一业务请求为写数据请求，则所述业务组件为存储容器；

所述通过所述第一服务器处理所述第一业务请求，在所述第一服务器中运行用于处理业务请求的业务组件，包括：

基于所述第一业务请求，生成处理所述第一业务请求所需的存储容器；

对所述存储容器进行初始化。

在另一种可能的实现方式中，所述基于所述第一业务请求，生成处理所述第一业务请求所需的存储容器，包括以下至少一种实现方式：

若所述第一业务请求用于与关系型数据库交互，则生成用于存储关系型数据的影子表；

若所述第一业务请求用于与缓存服务器交互，则生成用于存储缓存数据的服务器集群；

若所述第一业务请求用于与消息服务器交互，则生成用于存储消息的消息队列；

若所述第一业务请求用于与结构型数据库交互，则生成用于存储结构型数据的对照表。

在另一种可能的实现方式中，所述获取被模拟的第一业务请求，包括：

确定待模拟的目标业务参数；

从请求模拟平台获取所述目标业务参数匹配的第一业务请求，所述请求模拟平台用于模拟业务请求。

在另一种可能的实现方式中，所述第一业务请求为超文本传输协议http请求，则所述从请求模拟平台获取所述目标业务参数匹配的第一业务请求，包括：

从http消息队列中获取与所述目标业务参数匹配的目标日志消息，所述http消息队列用于存储历史http请求的日志消息；

基于所述目标日志消息和http协议，模拟所述第一业务请求。

在另一种可能的实现方式中，所述方法还包括：

从代理服务器中截获历史http请求，所述代理服务器用于向所述第一服务器转发所述历史http请求；

将所述历史http请求所请求的日志消息，基于业务参数分类存储至所述http消息队列中。

在另一种可能的实现方式中，所述第一业务请求为远程过程调用RPC请求，则所述从请求模拟平台获取所述目标业务参数匹配的第一业务请求，包括：

从RPC消息队列中获取与所述目标业务参数匹配的目标请求信息；

基于所述目标请求信息和RPC协议，模拟所述第一业务请求。

在另一种可能的实现方式中，所述方法还包括：

在调用RPC接口时，截获历史RPC请求；

将所述历史RPC请求所请求的请求信息，基于业务参数分类存储至所述RPC消息队列中。

在另一种可能的实现方式中，所述方法还包括：

若所述第一服务器在处理所述第一业务请求的过程中出现异常，重新获取第一业务请求；

基于重新获取的第一业务请求，在所述第一服务器中重新运行所述业务组件。

在另一种可能的实现方式中，所述方法还包括：

若所述第一服务器在处理所述第一业务请求的过程中出现异常，确定对所述第一业务请求处理的第一优先级以及对所述第二业务请求处理的第二优先级；

若所述第二优先级大于所述第一优先级，执行所述开放用于对外提供服务的服务接口的步骤。

一方面，提供了一种请求处理装置，所述装置包括：

第一获取模块，用于在目标微服务注册到第一服务器之后，且对外提供服务之前，获取被模拟的第一业务请求；

第一处理模块，用于通过所述第一服务器处理所述第一业务请求，在所述第一服务器中运行用于处理业务请求的业务组件；

开放模块，用于开放用于对外提供服务的服务接口，通过所述服务接口接收外部的第二业务请求，通过所述业务组件，处理所述第二业务请求。

在一种可能的实现方式中，若所述第一业务请求为写数据请求，则所述业务组件为存储容器；

所述第一处理模块，用于基于所述第一业务请求，生成处理所述第一业务请求所需的存储容器；对所述存储容器进行初始化。

在另一种可能的实现方式中，所述第一处理模块，还用于若所述第一业务请求用于与关系型数据库交互，则生成用于存储关系型数据的影子表；若所述第一业务请求用于与缓存服务器交互，则生成用于存储缓存数据的服务器集群；若所述第一业务请求用于与消息服务器交互，则生成用于存储消息的消息队列；若所述第一业务请求用于与结构型数据库交互，则生成用于存储结构型数据的对照表。

在另一种可能的实现方式中，所述第一获取模块，用于确定待模拟的目标业务参数；从请求模拟平台获取所述目标业务参数匹配的第一业务请求，所述请求模拟平台用于模拟业务请求。

在另一种可能的实现方式中，所述第一业务请求为超文本传输协议http请求，所述第一获取模块，用于从http消息队列中获取与所述目标业务参数匹配的目标日志消息，所述http消息队列用于存储历史http请求的日志消息；基于所述目标日志消息和http协议，模拟所述第一业务请求。

在另一种可能的实现方式中，所述装置还包括：

第二获取模块，用于从代理服务器中截获历史http请求，所述代理服务器用于向所述第一服务器转发所述历史http请求；

第一存储模块，用于将所述历史http请求所请求的日志消息，基于业务参数分类存储至所述http消息队列中。

在另一种可能的实现方式中，所述第一业务请求为远程过程调用RPC请求，所述第一获取模块，用于从RPC消息队列中获取与所述目标业务参数匹配的目标请求信息；基于所述目标请求信息和RPC协议，模拟所述第一业务请求。

在另一种可能的实现方式中，所述装置还包括：

第三获取模块，用于在调用RPC接口时，截获历史RPC请求；

第二存储模块，用于将所述历史RPC请求所请求的请求信息，基于业务参数分类存储至所述RPC消息队列中。

在另一种可能的实现方式中，所述装置还包括：

第四获取模块，用于若所述第一服务器在处理所述第一业务请求的过程中出现异常，重新获取第一业务请求；

第二处理模块，用于基于重新获取的第一业务请求，在所述第一服务器中重新运行所述业务组件。

在另一种可能的实现方式中，所述装置还包括：

确定模块，用于若所述第一服务器在处理所述第一业务请求的过程中出现异常，确定对所述第一业务请求处理的第一优先级以及对所述第二业务请求处理的第二优先级；

所述开放模块，用于若所述第二优先级大于所述第一优先级，开放用于对外提供服务的服务接口。

一方面，提供了一种计算机设备，该计算机设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条指令，该至少一条指令由该一个或多个处理器加载并执行以实现如上述任一种可能实现方式的请求处理方法所执行的操作。

一方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该至少一条指令由处理器加载并执行以实现如上述任一种可能实现方式的请求处理方法所执行的操作。

一方面，提供了一种计算机程序产品，该计算机程序产品包括至少一条指令，所述至少一条指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取所述至少一条指令，处理器执行所述至少一条指令，使得该计算机设备能够执行上述任一种可能实现方式的请求处理方法所执行的操作。

本申请实施例提供的技术方案带来的有益效果至少包括：

本申请实施例提供的请求处理方法，在目标微服务注册到第一服务器之后，且对外提供服务之前，先通过该第一服务器对被模拟的第一业务请求进行处理，通过处理该第一业务请求在第一服务器中运行处理业务请求的业务组件，实现对业务组件的预热。在预热完成后，再开放对外提供服务的服务接口，通过该服务接口处理外部的第二业务请求。由于在处理第二业务请求之前，业务组件已经进行了预热，因此，第一服务器可以快速对第二业务请求进行处理。该方法通过对业务组件进行预热可以降低响应首个业务请求的时长，无需查找问题代码以及对问题代码进行优化，节省了大量的人力物力，从而降低了优化成本。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种请求处理方法的实施环境的示意图图；

图2是本申请实施例提供的一种请求处理方法的流程图；

图3是本申请实施例提供的一种请求处理方法的流程图；

图4是本申请实施例提供的一种第二服务器获取http请求的示意图；

图5是本申请实施例提供的一种第二服务器获取RPC请求的示意图；

图6是本申请实施例提供的一种对第一服务器的业务组件进行预热的示意图；

图7是本申请实施例提供的一种对第一服务器的业务组件进行预热的示意图；

图8是本申请实施例提供的一种请求处理装置的结构示意图；

图9是本申请实施例提供的一种服务器的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

图1是本申请实施例提供的一种请求处理方法的实施环境的示意图。参见图1，该实施环境包括：第一服务器101和第二服务器102，第一服务器101和第二服务器102通过无线或有线网络连接，第一服务器101为目标微服务对应的服务器，第二服务器102为对第一服务器101进行预热的服务器，该预热是指在目标微服务对外提供服务之前，第二服务器102向第一服务器101发送第一业务请求，以使第一服务器101对第一业务请求进行处理，从而达到对第一服务器101进行预热的目的。

第一服务器101完成预热后，可以接收来自第一终端的第二业务请求。相应的，该实施环境还包括：第一终端，该第一终端为安装目标应用程序的终端，第一服务器101为该目标应用程序对应的服务器。第一服务器101对第二业务请求处理完成后，向第一终端返回该第二业务请求对应的请求数据或成功响应。若第一服务器101向第一终端发送请求数据，第一终端接收该请求数据，可以在当前界面上显示该请求数据。

本申请实施例提供的方法可以应用在多种场景中。例如，该方法可以应用到即时配送客户端、购物客户端、即时通信客户端或者新闻客户端中。若该方法应用到即时配送客户端，该客户端刚发布新版本。在新版本的客户端对应的目标微服务对外提供服务之前，先通过该第一服务器101对被模拟的业务请求进行处理，在处理完成后，开放目标微服务对外提供服务的服务接口，通过该服务接口对外提供服务。例如，用户通过第一终端登录新版本的即时配送客户端浏览商品时，第一终端首次向该客户端对应的服务器发送业务请求。由于在此之前，服务器已经通过处理被模拟的业务请求对业务组件进行了预热，因此，服务器可以快速响应该首个业务请求，也即加载商品信息，从而避免商品加载超时，影响用户体验。

再如，用户通过第一终端登录新版本的即时通信客户端与好友聊天时，用户首次向其好友发送消息时，第一终端首次向该客户端对应的服务器发送业务请求。由于在此之前，服务器已经通过处理被模拟的业务请求对业务组件进行了预热，因此，服务器可以快速响应该首个业务请求，也即向好友的终端发送聊天消息，从而避免消息发送超时，影响用户体验。

第一终端为手机、平板电脑和PC(Personal Computer)设备等设备中的至少一种。第一服务器101和第二服务器102可以为一台服务器、由多台服务器组成的服务器集群、云服务器、云计算平台和虚拟化中心中的至少一种。

图2是本申请实施例提供的一种请求处理方法的流程图，参见图2，该方法包括：

步骤201：在目标微服务注册到第一服务器之后，且对外提供服务之前，获取被模拟的第一业务请求。

步骤202：通过第一服务器处理第一业务请求，在第一服务器中运行用于处理业务请求的业务组件。

步骤203：开放用于对外提供服务的服务接口，通过服务接口接收外部的第二业务请求，通过业务组件，处理第二业务请求。

在一种可能的实现方式中，若第一业务请求为写数据请求，则业务组件为存储容器；

通过第一服务器处理第一业务请求，在第一服务器中运行用于处理业务请求的业务组件，包括：

基于第一业务请求，生成处理第一业务请求所需的存储容器；

对存储容器进行初始化。

在另一种可能的实现方式中，基于第一业务请求，生成处理第一业务请求所需的存储容器，包括以下至少一种实现方式：

若第一业务请求用于与关系型数据库交互，则生成用于存储关系型数据的影子表；

若第一业务请求用于与缓存服务器交互，则生成用于存储缓存数据的服务器集群；

若第一业务请求用于与消息服务器交互，则生成用于存储消息的消息队列；

若第一业务请求用于与结构型数据库交互，则生成用于存储结构型数据的对照表。

在另一种可能的实现方式中，获取被模拟的第一业务请求，包括：

确定待模拟的目标业务参数；

从请求模拟平台获取目标业务参数匹配的第一业务请求，请求模拟平台用于模拟业务请求。

在另一种可能的实现方式中，第一业务请求为超文本传输协议http请求，则从请求模拟平台获取目标业务参数匹配的第一业务请求，包括：

从http消息队列中获取与目标业务参数匹配的目标日志消息，http消息队列用于存储历史http请求的日志消息；

基于目标日志消息和http协议，模拟第一业务请求。

在另一种可能的实现方式中，方法还包括：

从代理服务器中截获历史http请求，代理服务器用于向第一服务器转发历史http请求；

将历史http请求所请求的日志消息，基于业务参数分类存储至http消息队列中。

在另一种可能的实现方式中，第一业务请求为远程过程调用RPC请求，则从请求模拟平台获取目标业务参数匹配的第一业务请求，包括：

从RPC消息队列中获取与目标业务参数匹配的目标请求信息；

基于目标请求信息和RPC协议，模拟第一业务请求。

在另一种可能的实现方式中，方法还包括：

在调用RPC接口时，截获历史RPC请求；

将历史RPC请求所请求的请求信息，基于业务参数分类存储至RPC消息队列中。

在另一种可能的实现方式中，方法还包括：

若第一服务器在处理第一业务请求的过程中出现异常，重新获取第一业务请求；

基于重新获取的第一业务请求，在第一服务器中重新运行业务组件。

在另一种可能的实现方式中，方法还包括：

若第一服务器在处理第一业务请求的过程中出现异常，确定对第一业务请求处理的第一优先级以及对第二业务请求处理的第二优先级；

若第二优先级大于第一优先级，执行开放用于对外提供服务的服务接口的步骤。

本申请实施例提供的请求处理方法，在目标微服务注册到第一服务器之后，且对外提供服务之前，先通过该第一服务器对被模拟的第一业务请求进行处理，通过处理该第一业务请求在第一服务器中运行处理业务请求的业务组件，实现对业务组件的预热。在预热完成后，再开放对外提供服务的服务接口，通过该服务接口处理外部的第二业务请求。由于在处理第二业务请求之前，业务组件已经进行了预热，因此，第一服务器可以快速对第二业务请求进行处理。该方法通过对业务组件进行预热可以降低响应首个业务请求的时长，无需查找问题代码以及对问题代码进行优化，节省了大量的人力物力，从而降低了优化成本。

图3是本申请实施例提供的一种请求处理方法的流程图，由第二服务器执行，参见图3，该方法包括：

步骤301：在目标微服务注册到第一服务器之后，且对外提供服务之前，第二服务器确定待模拟的目标业务参数。

该目标业务参数可以为URL(Uniform Resource Locator，统一资源定位符)，也可以为RPC(Remote Procedure Call，远程过程调用)接口标识。其中，该RPC接口标识包括接口名称和方法名称，该方法名称为该接口名称对应的接口中存储方法的名称。

本步骤中，第二服务器中可以存储http(Hyper Text Transfer Protocol，超文本传输协议)业务参数列表和RPC业务参数列表，http业务参数列表中存储有多个http业务参数，RPC业务参数列表中存储有多个RPC业务参数。第二服务器可以通过以下任一实现方式确定目标业务参数：

在一种可能的实现方式中，第二服务器可以从http业务参数列表中选择任一http业务参数作为目标业务参数，或者从RPC业务参数列表中选择任一RPC业务参数作为目标业务参数。

在另一种可能的实现方式中，第二服务器也可以从http业务参数列表中按顺序选择http业务参数作为目标业务参数，或者从RPC业务参数列表中按顺序选择RPC业务参数作为目标业务参数。

在另一种可能的实现方式中，第二服务器还可以接收第二终端发送的获取请求，该获取请求中携带业务参数标识。其中，该第二终端为开发人员使用的终端。第二服务器基于该业务参数标识从http业务参数列表和RPC业务参数列表中确定该业务参数标识对应的业务参数，将该业务参数作为目标业务参数。

需要说明的一点是，目标微服务注册到第一服务器是指目标微服务通过服务发布平台进行机器维度的发布操作。该服务发布平台可以进行灰度发布、蓝绿发布、主机管理和发布包管理等操作。

步骤302：第二服务器从请求模拟平台获取该目标业务参数匹配的第一业务请求。

该请求模拟平台用于模拟业务请求。第一业务请求可以为http请求，也可以为RPC请求，在本申请实施例中，对此不作具体限定。

本步骤中，若第一业务请求为http请求，第二服务器可以通过以下(1)和(2)获取第一业务请求，包括：

(1)第二服务器从http消息队列中获取与目标业务参数匹配的目标日志消息。

本步骤中，目标业务参数为URL，第二服务器可以接收第二终端发送的模拟请求，该模拟请求中携带URL，http消息队列中URL和日志消息对应存储，则第二服务器可以基于该URL从http消息队列中获取与该URL匹配的目标日志消息。其中，http消息队列的日志消息中每一行代表一个http请求，该http请求包含请求的控制信息和数据信息，该控制信息可以为method(方法)、header(头信息)、body(内容信息)，该数据信息可以为path(路径)、params(参数)。在本申请实施例中，对http请求包含的信息不作具体限定。

在本步骤之前，第二服务器可以通过以下实现方式将URL和日志消息进行对应存储：第二服务器从代理服务器中截获历史http请求，该代理服务器用于向第一服务器转发该历史http请求；将该历史http请求所请求的日志消息，基于业务参数分类存储至http消息队列中。这样，第二服务器可以基于URL从http消息队列中查询该URL对应的目标日志消息。

需要说明的一点是，第二服务器从代理服务器中截获历史http请求时，可以获取代理服务器中存储的所有历史http请求，可以获取历史时间范围内的http请求，也可以根据请求类型获取历史http请求。在本申请实施例中，对此不作具体限定。若第二服务器根据请求类型获取历史http请求，则第二服务器可以获取终端发送的截获请求，该截获请求中携带请求类型标识，第二服务器根据该请求类型标识从代理服务器中截获该请求类型标识对应的历史http请求。

(2)第二服务器基于目标日志消息和http协议，模拟该第一业务请求。

本步骤中，第二服务器可以通过不同的方法模拟第一业务请求，例如Jmeter(压力测试工具)或者curl(CommandLine URL，文件传输工具)命令。在本申请实施例中，对此不作具体限定。

参见图4，从图4中可以看出：代理服务器向第一服务器转发历史http请求，因此，历史http请求经过代理服务器，第二服务器抓取代理服务器的请求日志，将该请求日志对应的日志消息通过异步执行的方式扔到消息队列中。然后根据每个日志消息对应的URL将日志消息进行分类存储。后续在获取到URL时，根据该URL从http消息队列中获取该URL对应的日志消息，根据该日志消息和http协议，模拟http请求，对该请求进行标记，标记成模拟请求，也即第一业务请求。

若第一业务请求为RPC请求，则第二服务器可以通过以下步骤(3)和(4)获取第一业务请求，包括：

(3)第二服务器从RPC消息队列中获取与目标业务参数匹配的目标请求信息。

本步骤中，目标业务参数为RPC接口标识。RPC消息队列中RPC接口标识和请求信息对应存储，则第二服务器可以根据RPC接口标识从RPC消息队列中获取该RPC接口标识对应的请求信息。其中，该请求信息包括请求时间、请求参数、接口名称、方法名称等，在本申请实施例中，对此不作具体限定。

在本步骤之前，第二服务器可以通过以下实现方式将RPC接口标识和请求信息进行对应存储：第二服务器在调用RPC接口时，截获历史RPC请求；将历史RPC请求所请求的请求信息，基于业务参数分类存储至RPC消息队列中。这样第二服务器可以基于RPC接口标识从RPC消息队列中查询该RPC接口标识对应的请求信息。

(4)第二服务器基于目标请求信息和RPC协议，模拟第一业务请求。

参见图5，从图5中可以看出：第二服务器在调用RPC接口时，截获历史RPC请求，将该RPC请求所请求的请求信息通过异步执行的方式扔到RPC消息队列中。然后根据每个请求信息对应的RPC接口标识将请求信息进行分类存储。后续在获取到RPC接口标识时，根据该RPC接口标识从RPC消息队列中获取该RPC标识对应的请求信息。根据该请求信息和RPC协议，模拟RPC请求，也即第一业务请求。

需要说明的一点是，第二服务器也可以基于请求的类型或历史时间范围获取历史RPC请求，该过程与获取历史http请求的过程相似，在此不再赘述。另外，RPC请求需要有对应的RPC框架支持。在本申请实施例中，对RPC框架不作具体限定。

在本申请实施例中，对业务组件进行预热的第一业务请求为模拟请求，而不是真实发生的用户请求，对用户友好，可以提升用户的使用体验，尽可能减少用户和业务损失。

步骤303：第二服务器通过第一服务器处理该第一业务请求，在第一服务器中运行用于处理业务请求的业务组件。

本步骤中，第二服务器在获取第一业务请求后，可以先确定第一业务请求为写数据请求还是读数据请求，若第一业务请求为写数据请求，则本步骤可以通过以下步骤(1)至(2)实现，若第一业务请求为读数据请求，则本步骤可以通过以下步骤(3)实现。

在一种可能的实现方式中，若第一业务请求为写数据请求，则该业务组件为存储容器，本步骤可以通过以下步骤(1)至(2)实现，包括：

(1)第二服务器基于第一业务请求，生成处理第一业务请求所需的存储容器。

本步骤可以通过以下至少一种实现方式实现，包括：

第一种实现方式，若第一业务请求用于与关系型数据库交互，则第二服务器生成用于存储关系型数据的影子表。

该实现方式中，该影子表即为存储容器，该影子表中存储的关系型数据为关系型数据库中的数据。第二服务器可以接收第二终端发送的创建请求，基于该创建请求生成影子表，然后将关系型数据库中的关系型数据同步到影子表中，这样后续第一服务器可以根据影子表中的关系型数据对第一业务请求进行处理，从而避免影响正常的业务数据。其中，该数据库可以为mysql(关系型数据库管理系统)。

第二种实现方式，若第一业务请求用于与缓存服务器交互，则第二服务器生成用于存储缓存数据的服务器集群。

该实现方式中，该服务器集群即为存储容器，该服务器集群中存储的缓存数据为缓存服务器中的数据。相应的，第二服务器也可以基于创建请求生成服务器集群，然后将缓存服务器中的缓存数据同步到服务器集群中。其中，该缓存服务器可以为redis(RemoteDictionary Server，远程字典服务)。

第三种实现方式，若第一业务请求用于与消息服务器交互，则第二服务器生成用于存储消息的消息队列。

该实现方式中，该消息队列即为存储容器，该消息队列中存储的消息为消息服务器传输的消息。相应的，第二服务器也可以基于创建请求生成消息队列，然后将消息服务器传输的消息同步到消息队列中。其中，该消息队列可以mq(Message Queue，消息队列)。

第四种实现方式，若第一业务请求用于与结构型数据库交互，则第二服务器生成用于存储结构型数据的对照表。

该实现方式中，该对照表即为存储容器，该对照表中存储的数据为结构型数据库中的数据。相应的，第二服务器也可以基于创建请求生成对照表，然后将结构型数据库中的数据同步到对照表中。其中，该对照表可以为tair(结构数据存储系统)。

需要说明的一点是，不同的业务请求对应不同的存储容器，第二服务器生成存储容器后，可以建立请求标识与存储容器的对应关系。

(2)第二服务器向第一服务器发送第一业务请求，第一服务器基于该第一业务请求，对该存储容器进行初始化。

本步骤中，第一服务器基于第一业务请求对存储容器中的数据进行初始化处理，实现对存储容器的初始化。其中，第二服务器向第一服务器发送第一业务请求时，还可以发送请求标识与存储容器的对应关系，第一服务器可以根据该对应关系，对相应的存储容器进行初始化。

在本申请实施例中，由于存储容器中存储的数据与原始数据相同，因此对存储容器进行初始化不会影响正常的业务数据。而相关技术中通过查找问题代码和补充初始化代码的操作不仅会耗费较长时间，对于写数据的接口，初始化操作可能会影响线上正常业务的运行，导致客户投诉甚至是一些系统风险。

在本申请实施例中，第二服务器也可以在获取第一业务请求之前，预先生成多个存储容器，该存储容器可以包括影子表、服务器集群、消息队列和对照表中的一个或多个，然后建立请求标识和存储容器的对应关系。或者，由第一服务器预先生成存储容器，在接收到第二服务器发送的第一业务请求时，第一服务器基于该第一业务请求，对存储容器进行初始化。

在另一种可能的实现方式中，若第一业务请求为读数据请求，该业务组件为业务代码，则本步骤可以通过以下步骤(3)实现，包括：

(3)第二服务器向第一服务器发送该第一业务请求，第一服务器接收该第一业务请求，通过运行业务代码对该第一业务请求进行处理。

本步骤中，第一服务器通过运行业务代码对第一业务请求进行处理，可以实现对业务代码进行预热。

需要说明的一点是，相关技术中在第一服务器响应微服务的首个业务请求的时长较长时，开发人员会分析微服务的业务代码，查找问题代码，对问题代码逐一进行优化。在依赖的下游和中间件很多的情况下，每次查找问题代码和补充初始化代码会耗费较长时间，并且有些问题隐藏较深不好定位，时间成本随着问题的难度变化。另外，初始化代码分布在服务不同的地方，一些会和业务代码强耦合，扩展性和可读性较差，这样导致一些非核心流程的流程可能会影响业务的核心链路，导致整体的系统风险较高。

而在本申请实施例中，在目标微服务对外提供服务之前，先通过第一业务请求对业务组件进行了预热，因此，第一服务器在目标微服务对外提供服务时，可以快速处理首个业务请求，降低响应首个业务请求的时长。该方法可以降低人力成本和时间成本，让开发人员只专注于业务代码逻辑，不需要关注超时的问题，也不需要一个个进行超时问题的初始化分析和优化操作。并且，该方法配置风险低，耦合度低，不需要写任何代码，对业务逻辑不会产生副作用，只需要在发布脚本中添加一行命令即可。

在本申请实施例中，业务组件可以包括多个子业务组件，第一服务器可以通过运行第一子业务组件对第一业务请求进行处理，第二服务器可以在第一服务器对第一业务请求处理完成后，执行步骤304；也可以获取第三业务请求，通过第一服务器对第三业务请求进行处理，在处理过程中运行第二子业务组件，在第一服务器对第三业务请求处理完成后，第二服务器获取第四业务请求，通过第一服务器对第四业务请求进行处理，在处理过程中运行第三业务组件，直至第一服务器将每个子业务组件都运行一遍，这样第一服务器在接收到外部的第二业务请求时，由于每个子业务组件都进行了预热，因此，无论该第二业务请求需要通过运行哪个子业务组件，第一服务器都可以快速响应，从而降低响应首个请求的时长。

其中，上述多个业务请求可以为不同类型的请求，不同类型的请求消耗不同的流量，第一服务器可以通过运行不同的子业务组件处理不同流量的请求，从而将每个子业务组件都运行一遍。

步骤304：第二服务器开放用于对外提供服务的服务接口，通过该服务接口接收外部的第二业务请求，通过该业务组件，处理该第二业务请求。

本步骤中，第一服务器对第一业务请求处理完成后，可以向第二服务器发送第一通知消息，用于通知第二服务器第一业务请求处理完成。第二服务器接收该第一通知消息，将目标微服务注册到服务注册中心。注册完成后，暴露目标微服务对外提供服务的服务接口，对外暴露服务，这样第一服务器可以通过该服务接口接收外部的第二业务请求，通过运行业务组件，处理该第二业务请求，该第二业务请求为目标微服务对外提供服务的首个业务请求。

并且，在注册完成后，第二服务器可以向服务发现中心发送注册完成的第二通知消息，该第二通知消息中携带目标微服务的服务标识。服务发现中心接收该第二通知消息，将该目标微服务的服务标识添加到服务列表中，更新存储的服务列表，该服务列表用于存储已注册完成的微服务的服务标识。

由于第一服务器在处理第二业务请求之前，已通过处理第一业务请求对业务组件进行了预热，因此，第一服务器可以快速响应该第二业务请求，从而降低首个业务请求的时长。

在一种可能的实现方式中，目标微服务可能包括一个或多个服务器，若目标微服务包括一个服务器，则直接执行上述步骤301～304。若目标微服务包括多个服务器，参见图6，例如，目标微服务包括服务器1、服务器2、服务器3、服务器4和服务器5。以服务器1为例进行说明，在该服务器1对外提供服务之前，第二服务器从请求模拟平台获取被模拟的第一业务请求，然后将第一业务请求打入服务器1，服务器1处理第一业务请求，运行用于处理业务请求的业务组件，对业务组件进行预热。若第一业务请求为写数据请求，则生成对应的存储容器，对存储容器进行初始化，从而进行预热。在预热完成后，将该服务器1注册到服务注册中心，对外暴露服务，对目标微服务的上游提供服务，同时服务发现中心及时更新服务列表。服务器2～5也通过上述步骤依次进行，直至每个服务器均完成预热，对外暴露服务。

在本申请实施例中，目标应用程序对应的每个微服务在对外提供服务之前，均可以通过上述步骤301～304来进行预热，这样每个微服务在对外提供服务之前，都进行了预热，从而在每个微服务对外提供服务时，均可以快速响应首个业务请求，从而降低响应首个业务请求的时长。

本申请实施例提供的请求处理方法，在目标微服务注册到第一服务器之后，且对外提供服务之前，先通过该第一服务器对被模拟的第一业务请求进行处理，通过处理该第一业务请求在第一服务器中运行处理业务请求的业务组件，实现对业务组件的预热。在预热完成后，再开放对外提供服务的服务接口，通过该服务接口处理外部的第二业务请求。由于在处理第二业务请求之前，业务组件已经进行了预热，因此，第一服务器可以快速对第二业务请求进行处理。该方法通过对业务组件进行预热可以降低响应首个业务请求的时长，无需查找问题代码以及对问题代码进行优化，节省了大量的人力物力，从而降低了优化成本。

在本申请实施例中，若第一服务器在处理第一业务请求的过程中没有出现异常，第二服务器可以按照上述步骤301～304执行。若第一服务器在处理第一业务请求的过程中出现异常，第二服务器可以重新对第一服务器的业务组件进行预热，在预热完成后，执行上述步骤304，或者，在目标微服务对外提供服务的优先级大于处理第一业务请求的优先级时，忽略该异常，直接执行上述步骤304。在本申请实施例中，对此不作具体限定。

若第一服务器在处理第一业务请求的过程中出现异常，且第二服务器重新对第一服务器的业务组件进行预热，该过程可以为：第二服务器重新获取第一业务请求；基于重新获取的第一业务请求，在第一服务器中重新运行该业务组件。

该实现方式中，第二服务器可以重新确定待模拟的目标业务参数，然后从请求模拟平台获取重新确定的目标业务参数匹配的第一业务请求。基于该重新获取的第一业务请求，在第一服务器中重新运行业务组件。该过程与上述步骤301～303相似，在此不再赘述。或者，第二服务器也可以获取第三业务请求，通过第一服务器处理第三业务请求，在第一服务器中运行业务组件。

若第二服务器在目标微服务对外提供服务的优先级大于处理第一业务请求的优先级时，不再对第一服务器进行预热，直接执行步骤304，该过程可以为：第二服务器确定对第一业务请求处理的第一优先级以及对第二业务请求处理的第二优先级；若第二优先级大于第一优先级，则开放目标微服务用于对外提供服务的服务接口，也即执行步骤304。

该实现方式中，第二服务器可以预先建立请求类型和优先级之间的对应关系，不同的请求类型对应不同的优先级。然后分别通过以下第一种实现方式和第二种实现方式确定第一优先级和第二优先级。

第一种实现方式：第二服务器在接收到第一服务器由于处理第一业务请求异常而发送的通知消息时，根据第一业务请求的请求类型，从请求类型和优先级之间的对应关系中确定第一业务请求的第一优先级。

第二种实现方式：第二服务器可以预测在目标微服务对外提供服务时，来自外部的第二业务请求的请求类型，根据该请求类型确定第二业务请求的第二优先级。

该实现方式中，第二业务请求的请求类型可能为多个，不同的请求类型对应不同的优先级，得到多个优先级，第二服务器可以确定多个优先级中最小的优先级，将该最小的优先级作为第二优先级。

在本申请实施例中，第二服务器还可以预先建立请求标识和优先级之间的对应关系，不同的请求标识对应不同的优先级。其中，第二服务器基于请求标识确定优先级的方式与基于请求类型确定优先级的方式相似，在此不再赘述。

若第二优先级大于第一优先级，第二服务器执行步骤304；若第二优先级不大于第一优先级，则第二服务器可以重新获取第一业务请求，基于重新获取的第一业务请求，在第一服务器中重新运行业务组件。

参见图7，从图7中可以看出：目标微服务注册到第一服务器之后，启动第二服务器。若第二服务器启动失败，则排查问题代码并修复代码。若第二服务器启动成功，从请求模拟平台拉取第一业务请求，将该第一业务请求打入第一服务器进行预热。若第一服务器在预热过程中出现异常，则重新获取第一业务请求进行预热，或者在对外提供服务的优先级大于处理第一业务请求的优先级时，跳过预热，暴露服务接口，注册到服务注册中心，对外提供服务。

在本申请实施例中，在第一服务器处理第一业务请求的过程中出现异常时，可以根据不同的情况确定继续进行预热还是跳过预热，直接对外提供服务，增加了选择性，处理方式更灵活。

图8是本申请实施例提供的一种请求处理装置的结构示意图，参见图8，该装置包括：

第一获取模块801，用于在目标微服务注册到第一服务器之后，且对外提供服务之前，获取被模拟的第一业务请求；

第一处理模块802，用于通过第一服务器处理第一业务请求，在第一服务器中运行用于处理业务请求的业务组件；

开放模块803，用于开放用于对外提供服务的服务接口，通过服务接口接收外部的第二业务请求，通过业务组件，处理第二业务请求。

在一种可能的实现方式中，若第一业务请求为写数据请求，则业务组件为存储容器；

第一处理模块802，用于基于第一业务请求，生成处理第一业务请求所需的存储容器；对存储容器进行初始化。

在另一种可能的实现方式中，第一处理模块802，还用于若第一业务请求用于与关系型数据库交互，则生成用于存储关系型数据的影子表；若第一业务请求用于与缓存服务器交互，则生成用于存储缓存数据的服务器集群；若第一业务请求用于与消息服务器交互，则生成用于存储消息的消息队列；若第一业务请求用于与结构型数据库交互，则生成用于存储结构型数据的对照表。

在另一种可能的实现方式中，第一获取模块801，用于确定待模拟的目标业务参数；从请求模拟平台获取目标业务参数匹配的第一业务请求，请求模拟平台用于模拟业务请求。

在另一种可能的实现方式中，第一业务请求为超文本传输协议http请求，第一获取模块801，用于从http消息队列中获取与目标业务参数匹配的目标日志消息，http消息队列用于存储历史http请求的日志消息；基于目标日志消息和http协议，模拟第一业务请求。

在另一种可能的实现方式中，装置还包括：

第二获取模块，用于从代理服务器中截获历史http请求，代理服务器用于向第一服务器转发历史http请求；

第一存储模块，用于将历史http请求所请求的日志消息，基于业务参数分类存储至http消息队列中。

在另一种可能的实现方式中，第一业务请求为远程过程调用RPC请求，第一获取模块801，用于从RPC消息队列中获取与目标业务参数匹配的目标请求信息；基于目标请求信息和RPC协议，模拟第一业务请求。

在另一种可能的实现方式中，装置还包括：

第三获取模块，用于在调用RPC接口时，截获历史RPC请求；

第二存储模块，用于将历史RPC请求所请求的请求信息，基于业务参数分类存储至RPC消息队列中。

在另一种可能的实现方式中，装置还包括：

第四获取模块，用于若第一服务器在处理第一业务请求的过程中出现异常，重新获取第一业务请求；

第二处理模块，用于基于重新获取的第一业务请求，在第一服务器中重新运行业务组件。

在另一种可能的实现方式中，装置还包括：

确定模块，用于若第一服务器在处理第一业务请求的过程中出现异常，确定对第一业务请求处理的第一优先级以及对第二业务请求处理的第二优先级；

开放模块803，用于若第二优先级大于第一优先级，开放用于对外提供服务的服务接口。

本申请实施例提供的请求处理装置，在目标微服务注册到第一服务器之后，且对外提供服务之前，先通过该第一服务器对被模拟的第一业务请求进行处理，通过处理该第一业务请求在第一服务器中运行处理业务请求的业务组件，实现对业务组件的预热。在预热完成后，再开放对外提供服务的服务接口，通过该服务接口处理外部的第二业务请求。由于在处理第二业务请求之前，业务组件已经进行了预热，因此，第一服务器可以快速对第二业务请求进行处理。该装置通过对业务组件进行预热可以降低响应首个业务请求的时长，无需查找问题代码以及对问题代码进行优化，节省了大量的人力物力，从而降低了优化成本。

需要说明的是：上述实施例提供的请求处理装置在处理请求时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将服务器的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的请求处理装置与请求处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图9是本申请实施例提供的一种服务器的结构示意图，该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processingunits，CPU)901和一个或一个以上的存储器902，其中，该存储器902中存储有至少一条指令，该至少一条指令由该处理器901加载并执行以实现上述各个方法实施例提供的方法。当然，该服务器900还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器900还可以包括其他用于实现设备功能的部件，在此不做赘述。

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

在一些实施例中，本申请实施例所涉及的计算机程序可被部署在一个计算机设备上执行，或者在位于一个地点的多个计算机设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算机设备上执行，分布在多个地点且通过通信网络互连的多个计算机设备可以组成区块链系统。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (13)

1.一种请求处理方法，其特征在于，所述方法包括：

在目标微服务注册到第一服务器之后，且对外提供服务之前，获取被模拟的第一业务请求；

通过所述第一服务器处理所述第一业务请求，在所述第一服务器中运行用于处理业务请求的业务组件；

开放用于对外提供服务的服务接口，通过所述服务接口接收外部的第二业务请求，通过所述业务组件，处理所述第二业务请求。

2.根据权利要求1所述的方法，其特征在于，若所述第一业务请求为写数据请求，则所述业务组件为存储容器；

所述通过所述第一服务器处理所述第一业务请求，在所述第一服务器中运行用于处理业务请求的业务组件，包括：

基于所述第一业务请求，生成处理所述第一业务请求所需的存储容器；

对所述存储容器进行初始化。

3.根据权利要求2所述的方法，其特征在于，所述基于所述第一业务请求，生成处理所述第一业务请求所需的存储容器，包括以下至少一种实现方式：

若所述第一业务请求用于与关系型数据库交互，则生成用于存储关系型数据的影子表；

若所述第一业务请求用于与缓存服务器交互，则生成用于存储缓存数据的服务器集群；

若所述第一业务请求用于与消息服务器交互，则生成用于存储消息的消息队列；

若所述第一业务请求用于与结构型数据库交互，则生成用于存储结构型数据的对照表。

4.根据权利要求1所述的方法，其特征在于，所述获取被模拟的第一业务请求，包括：

确定待模拟的目标业务参数；

从请求模拟平台获取所述目标业务参数匹配的第一业务请求，所述请求模拟平台用于模拟业务请求。

5.根据权利要求4所述的方法，其特征在于，所述第一业务请求为超文本传输协议http请求，则所述从请求模拟平台获取所述目标业务参数匹配的第一业务请求，包括：

从http消息队列中获取与所述目标业务参数匹配的目标日志消息，所述http消息队列用于存储历史http请求的日志消息；

基于所述目标日志消息和http协议，模拟所述第一业务请求。

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

从代理服务器中截获历史http请求，所述代理服务器用于向所述第一服务器转发所述历史http请求；

将所述历史http请求所请求的日志消息，基于业务参数分类存储至所述http消息队列中。

7.根据权利要求4所述的方法，其特征在于，所述第一业务请求为远程过程调用RPC请求，则所述从请求模拟平台获取所述目标业务参数匹配的第一业务请求，包括：

从RPC消息队列中获取与所述目标业务参数匹配的目标请求信息；

基于所述目标请求信息和RPC协议，模拟所述第一业务请求。

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

在调用RPC接口时，截获历史RPC请求；

将所述历史RPC请求所请求的请求信息，基于业务参数分类存储至所述RPC消息队列中。

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

若所述第一服务器在处理所述第一业务请求的过程中出现异常，重新获取第一业务请求；

基于重新获取的第一业务请求，在所述第一服务器中重新运行所述业务组件。

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

若所述第一服务器在处理所述第一业务请求的过程中出现异常，确定对所述第一业务请求处理的第一优先级以及对所述第二业务请求处理的第二优先级；

若所述第二优先级大于所述第一优先级，执行所述开放用于对外提供服务的服务接口的步骤。

11.一种请求处理装置，其特征在于，所述装置包括：

第一获取模块，用于在目标微服务注册到第一服务器之后，且对外提供服务之前，获取被模拟的第一业务请求；

第一处理模块，用于通过所述第一服务器处理所述第一业务请求，在所述第一服务器中运行用于处理业务请求的业务组件；

开放模块，用于开放用于对外提供服务的服务接口，通过所述服务接口接收外部的第二业务请求，通过所述业务组件，处理所述第二业务请求。

12.一种服务器，其特征在于，所述服务器包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条指令，所述至少一条指令由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求10任一项所述的请求处理方法所执行的操作。

13.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述至少一条指令由处理器加载并执行以实现如权利要求1至权利要求10任一项所述的请求处理方法所执行的操作。

Images