CN113364614B - 请求处理方法、装置、服务器、存储介质及程序产品 - Google Patents

Abstract

本公开关于一种请求处理方法、装置、服务器、存储介质及程序产品。其中，该请求处理方法包括：拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同；将第一客户端请求的请求信息转化为目标命令行；执行目标命令行，得到第二客户端请求异常响应时的场景。采用本公开，能够解决难以复现出现线上问题的场景的问题。

Description

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

技术领域

本公开涉及请求处理技术领域，尤其涉及请求处理方法、装置、服务器、存储介质及程序产品。

背景技术

随着移动互联网的蓬勃发展和电子设备的不断普及，互联网应用服务的质量和稳定性日益提高。但在为用户提供服务的过程中，通常还是不可避免地会出现一些线上问题，例如页面无法加载、某些应用功能无法实现等，这为互联网应用服务的质量和稳定性带来影响。

相关技术中，若互联网应用服务出现线上问题，通常利用查看用户日志的方式，拼凑出用户请求参数，以尝试复现出现问题的场景，从而进行问题排查和定位。然而，在利用查看用户日志的方式拼凑用户请求参数时，往往会遇到签名校验，导致无法获取到完整的用户请求参数，难以复现出现线上问题的场景。

发明内容

本公开提供一种请求处理方法、装置、服务器、存储介质及程序产品，以至少解决相关技术中因无法获取到完整的用户请求参数，导致难以复现出现线上问题的场景的问题。

本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种请求处理方法，包括：拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同；将第一客户端请求的请求信息转化为目标命令行；执行目标命令行，得到第二客户端请求异常响应时的场景。

在第一方面的一些可实现方式中，请求信息包括请求头信息、请求体信息和请求参数，将第一客户端请求的请求信息转化为目标命令行，包括：将请求头信息、请求体信息和请求参数编码转化为可执行的目标命令行。

在第一方面的一些可实现方式中，拦截第一客户端请求，包括：调用线上诊断工具拦截第一客户端请求。

在第一方面的一些可实现方式中，线上诊断工具包括阿尔萨斯arthas工具或greys工具。

在第一方面的一些可实现方式中，arthas工具或greys工具包括对象导航图语言OGNL表达式，将第一客户端请求的请求信息转化为目标命令行，包括：基于OGNL表达式触发第一客户端请求的请求信息进行编码转化，得到可执行的目标命令行。

在第一方面的一些可实现方式中，目标命令行包括curl命令行、wget命令行、httpie命令行中的任意一项。

在第一方面的一些可实现方式中，在目标命令行为curl命令行的情况下，执行目标命令行，得到第二客户端请求异常响应时的场景，包括：调用应用程序编程接口API调试工具解析curl命令行，得到第二客户端请求异常响应时的场景。

在第一方面的一些可实现方式中，在拦截第一客户端请求之前，该方法还包括：接收第二客户端请求，第二客户端请求包括用户ID；拦截第一客户端请求，包括：在第二客户端请求响应异常的情况下，调用arthas工具的watch命令拦截第一客户端请求，其中，watch命令包括用户ID。

在第一方面的一些可实现方式中，第一客户端请求和第二客户端请求用于实现客户端中应用程序的功能。

根据本公开实施例的第二方面，提供一种请求处理装置，包括：拦截模块，被配置为执行拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同；转化模块，被配置为执行将第一客户端请求的请求信息转化为目标命令行；执行模块，被配置为执行执行目标命令行，得到第二客户端请求异常响应时的场景。

在第二方面的一些可实现方式中，请求信息包括请求头信息、请求体信息和请求参数，转化模块具体被配置为执行：将请求头信息、请求体信息和请求参数编码转化为可执行的目标命令行。

在第二方面的一些可实现方式中，拦截模块具体被配置为执行：调用线上诊断工具拦截第一客户端请求。

在第二方面的一些可实现方式中，线上诊断工具包括阿尔萨斯arthas工具或greys工具。

在第二方面的一些可实现方式中，arthas工具或greys工具包括对象导航图语言OGNL表达式，转化模块具体被配置为执行：基于OGNL表达式触发第一客户端请求的请求信息进行编码转化，得到可执行的目标命令行。

在第二方面的一些可实现方式中，目标命令行包括curl命令行、wget命令行、httpie命令行中的任意一项。

在第二方面的一些可实现方式中，执行模块具体被配置为执行：在目标命令行为curl命令行的情况下，调用应用程序编程接口API调试工具解析curl命令行，得到第二客户端请求异常响应时的场景。

在第二方面的一些可实现方式中，该装置还包括：接收模块，被配置为执行在拦截第一客户端请求之前，接收第二客户端请求，第二客户端请求包括用户ID；拦截模块具体被配置为执行：在第二客户端请求响应异常的情况下，调用arthas工具的watch命令拦截第一客户端请求，其中，watch命令包括用户ID。

在第二方面的一些可实现方式中，第一客户端请求和第二客户端请求用于实现客户端中应用程序的功能。

根据本公开实施例的第三方面，提供一种服务器，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现如第一方面或第一方面的一些可实现方式中的请求处理方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当计算机可读存储介质中的指令由服务器的处理器执行时，使得服务器能够执行如第一方面或第一方面的一些可实现方式中的请求处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包括计算机指令，计算机指令被处理器执行时实现如第一方面或第一方面的一些可实现方式中的请求处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

在本公开实施例中，第二客户端请求为响应异常的用户请求，而第一客户端请求与第二客户端请求的请求信息相同，基于此，拦截第一客户端请求，并将该第一客户端请求的请求信息转化为目标命令行。然后通过执行该目标命令行，就可以得到第二客户端请求异常响应时，即出现线上问题时的场景。这样，在用户请求异常响应，即出现线上问题时，无需利用查看用户日志的方式拼凑用户请求参数进行场景复现，直接对与该响应异常用户请求的请求信息相同的用户请求进行拦截和转化，就能够基于转化得到的命令行，有效进行用户请求异常响应时的问题场景复现。因而，本公开实施例可以解决因无法获取到完整的用户请求参数，导致难以复现出现线上问题的场景的问题。

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

附图说明

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

图1是根据一示例性实施例示出的一种请求处理的架构图。

图2是根据一示例性实施例示出的一种请求处理方法的流程图。

图3是根据一示例性实施例示出的一种请求处理装置的框图。

图4是根据一示例性实施例示出的一种服务器的框图。

图5是根据一示例性实施例示出的用于请求处理方法的设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

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

首先，本公开实施例所提供的请求处理方法，可以应用于如图1的架构中，具体结合图1进行详细说明。

图1是根据一示例性实施例示出的一种请求处理的架构图。

如图1所示，服务器10通过网络30与客户端20通信连接，以进行数据通信或交互。服务器10可以是一台服务器，也可以是由至少两台服务器组成的用于提供互联网应用服务的服务器集群。客户端20可以是，但不限于个人电脑(Personal Computer，PC)、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。网络30可以是有线或无线网络。应注意的是，图1仅仅是一种示例，实际应用中客户端20的数量可按照实际需求设定。

相关技术中，客户端20可以向服务器10发送用户请求，服务器10接收到该用户请求后进行响应，向客户端20返回请求信息，从而实现客户端20与服务器10之间的数据交互。然而由于各方面原因，有时服务器10接收到用户请求后无法向客户端20返回正确的请求信息，即无法正常响应，从而导致一些线上问题的发生，例如客户端20无法显示加载后的页面内容。这种情况下，由于线上线下环境一般隔离，因此相关技术中通常采用查看用户日志的方式，拼凑出用户请求参数，以尝试复现出现问题的场景，从而进行问题排查和定位。然而，在利用查看用户日志的方式拼凑用户请求参数时，往往会遇到签名校验，导致无法获取到完整的用户请求参数，难以复现出现线上问题的场景。

为了解决上述相关技术中存在的因无法获取到完整的用户请求参数，导致难以复现出现线上问题的场景的问题，本公开实施例提供了一种请求处理方法、装置、服务器、存储介质及程序产品，能够解决难以复现出现线上问题的场景的问题。

下面将对本公开实施例提供的请求处理方法进行详细说明。

图2是根据一示例性实施例示出的一种请求处理方法的流程图。本公开实施例提供的请求处理方法可以应用于图1的服务器10中，可以理解的是，上述执行主体并不构成对本公开的限定。

如图2所示，该请求处理方法可以包括S210-S230。

S210，拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同。

在这里，第一客户端请求与第二客户端请求为同一客户端向服务器发送的两次请求，两次请求的请求信息相同，即第一客户端请求与第二客户端请求向服务器请求的资源相同。由于客户端在向服务器发送第二客户端请求之后，服务器无法对该第二客户端请求进行正常响应，导致该第二客户端请求响应异常/失败，因此当客户端再次发起与第二客户端请求的请求信息相同的第一客户端请求时，服务器可以直接拦截该第一客户端请求，避免其直接响应异常。

在本公开的一些实施例中，第一客户端请求和第二客户端请求可以用于实现客户端中应用程序的功能，例如“点赞”、“转发”、“评论”、“发表”等应用程序功能。

示例性地，用户想要使用客户端应用程序提供的“转发”功能，因而通过对界面显示的“转发”控件的操作，触发客户端向服务器发送一次用户请求，即第二客户端请求，但该第二客户端请求响应异常，用户没有实现成功转发。因此，用户再次对界面显示的“转发”控件进行操作，触发客户端再次向服务器发送用户请求，即第一客户端请求。此时，由于第二客户端请求已经响应异常，因此服务器直接拦截第一客户端请求，以通过该第一客户端请求携带的请求信息进行问题复现和问题定位。

在本公开的另一些实施例中，第一客户端请求和第二客户端请求也可以用于实现客户端中网页的功能，例如“浏览”、“收藏”、“跳转”、“搜索”等网页功能。

如此，在用户使用客户端的应用程序功能或网页功能的场景下，当用户的第一次操作触发的第二客户端请求异常响应时，服务器可以对用户的第二次操作触发的第一客户端请求进行准确拦截，并基于拦截到的第一客户端请求的请求信息进行问题场景复现。

S220，将第一客户端请求的请求信息转化为目标命令行。

S230，执行目标命令行，得到第二客户端请求异常响应时的场景。

通过本公开实施例所提供的请求处理方法，第二客户端请求为响应异常的用户请求，而第一客户端请求与第二客户端请求的请求信息相同，基于此，拦截第一客户端请求，并将该第一客户端请求的请求信息转化为目标命令行。然后通过执行该目标命令行，就可以得到第二客户端请求异常响应时，即出现线上问题时的场景。这样，在用户请求异常响应，即出现线上问题时，无需利用查看用户日志的方式拼凑用户请求参数进行场景复现，直接对与该响应异常用户请求的请求信息相同的用户请求进行拦截和转化，就能够基于转化得到的命令行，有效进行用户请求异常响应时的问题场景复现。因而，本公开实施例可以解决因无法获取到完整的用户请求参数，导致难以复现出现线上问题的场景的问题。

下面结合具体的实施例，详细介绍上述S210-S230。

首先涉及S210，拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同。

在本公开的一些实施例中，请求信息课与包括请求头信息、请求体信息和请求参数。

在上述实施例中，第一客户端请求和第二客户端请求均可以为HTTP请求，服务器可以捕获HTTP请求的HttpServletRequest对象。其中，HttpServletRequest对象中包括请求头信息、请求体信息、请求参数等请求信息。请求头(Request Header)包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。请求体即请求正文，请求正文中可以包含查询字符串信息。

在本公开的一些实施例中，拦截第一客户端请求，可以具体包括：调用线上诊断工具拦截第一客户端请求。

在这里，调用线上诊断工具可以快速对用户请求范围内任意位置进行请求拦截，以获取第一客户端请求中携带的请求信息。

在本公开的一些实施例中，上述线上诊断工具可以为JAVA线上诊断工具，该JAVA线上诊断工具可以包括但不限于：阿尔萨斯arthas工具、greys工具、Bistoury工具。

如此，开发人员无需通过用户日志中携带的参数自行拼接信息，通过调用线上诊断工具，就可以快速获取到第一客户端请求中携带的请求信息，也即异常响应的第二客户端请求的请求信息，从而有效提升问题场景复现的速度。

在本公开的一些实施例中，在S210之前，该方法还可以包括：接收第二客户端请求，其中，第二客户端请求可以包括用户ID；S210具体可以包括：在第二客户端请求响应异常的情况下，调用arthas工具的watch命令拦截第一客户端请求，其中，watch命令包括用户ID。

示例性地，在不添加用户ID的情况下，输入的watch命令可以为：

“watchxxxx.KmovieAdminCommonBannerControllergetBanner'{@com.YYYY.sz.sdk.log.RequestCurl@CURL}'-v-n 5-x 3'1＝＝1'”；

而在上述添加用户ID(例如123456)的情况下，输入的watch命令可以为：

“watchxxxx.KmovieAdminCommonBannerControllergetBanner”@com.YYYY.framework.scope.CurrentScope@visitor()＝＝123456'”。

如此，通过在watch命令中限定用户ID，可以针对个别用户的bug进行准确拦截，实现目标化拦截，提升请求拦截的准确率。

需要说明的是，此处的arthas工具仅是拦截第一客户端请求的一种示例，本公开还可以采用其他线上诊断工具对上述第一客户端请求进行拦截，在此不再赘述。

然后涉及S220，将第一客户端请求的请求信息转化为目标命令行。

在本公开的一些实施例中，将第一客户端请求的请求信息转化为目标命令行，可以具体包括：将请求头信息、请求体信息和请求参数编码转化为可执行的目标命令行。

需要说明的是，在上述实施例中，通过调用线上诊断工具除了可以拦截第一客户端请求，还可以直接将第一客户端请求传入转化逻辑内进行逻辑运算转化，从而得到可执行的目标命令行。例如，在该目标命令行为curl命令行的情况下，该线上诊断工具即为Request To Curl工具，通过此工具，当线上故障发生时刻，可以快速对任意位置进行请求拦截，并转化为curl命令行。

如此，在获取到客户端请求的请求头信息、请求体信息和请求参数之后，可以通过编码转化的方式快捷生成该客户端请求对应的目标命令行，而通过执行该目标命令行，就可以实现客户端请求异常响应时的问题场景复现，提升了故障复现的效率。

在本公开的一些实施例中，arthas工具或greys工具可以包括对象导航图语言(Object-Graph Navigation Language，OGNL)表达式，将第一客户端请求的请求信息转化为目标命令行，可以具体包括：基于OGNL表达式触发第一客户端请求的请求信息进行编码转化，得到可执行的目标命令行。

在本公开的一个实施例中，服务器可以调用arthas工具的watch命令对第一客户端请求进行拦截，并执行OGNL表达式触发第一客户端请求的请求信息进行编码转化，得到可执行的目标命令行。

如此，基于arthas工具的OGNL表达式功能，可以触发第一客户端请求的请求信息进行编码转化，从而快速得到可执行的目标命令行。而采用查看日志、拼凑参数的方式来进行问题复现，此方法时间成本较高，并且当前遇到问题的场景用户请求的参数不一定满足场景复现的要求，因此该方法不一定可行。相比较而言，通过对客户端请求进行拦截并转化的方式，能够在互联网应用服务出现线上问题时快速复现问题，有效降低时间成本。

最后涉及S230，执行目标命令行，得到第二客户端请求异常响应时的场景。

在本公开的一些实施例中，目标命令行包括curl命令行、wget命令行、httpie命令行中的任意一项。

需要说明的是，服务器转化得到的目标命令行不同，则在执行目标命令行时，调用的命令行工具也不相同。

在本公开的一个示例中，在目标命令行为curl命令行的情况下，S220可以具体包括：调用应用程序编程接口API调试工具解析curl命令行，得到第二客户端请求异常响应时的场景。

这样，由于curl命令行除了携带了完整的复现需要的请求信息外，还能在任意终端被快速执行，因此只需要电脑中安装了API调试工具即可快捷执行调用，通过这一调用开发人员就可以进行问题的排查了。

如此，通过调用目标命令行对应的命令行工具来执行目标命令行，可以在互联网应用服务出现线上问题时快速复现问题，帮助开发人员更快地恢复服务，从而提升服务稳定性和质量。同时，避免了在问题发生时，开发人员需要通过日志中携带的参数自行拼接信息，相比于拼接日志参数进行问题复现的方式，从成功率和效率上都得到了很大的提升。

基于上述请求处理方法，本公开实施例还提供了请求处理装置。具体结合图3进行说明。

图3是根据一示例性实施例示出的一种请求处理装置的框图。参照图3，该请求处理装置300可以包括拦截模块310、转化模块320、执行模块330。

其中，拦截模块310，被配置为执行拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同；转化模块320，被配置为执行将第一客户端请求的请求信息转化为目标命令行；执行模块330，被配置为执行执行目标命令行，得到第二客户端请求异常响应时的场景。

通过本公开实施例提供的请求处理装置，第二客户端请求为响应异常的用户请求，而第一客户端请求与第二客户端请求的请求信息相同，基于此，拦截第一客户端请求，并将该第一客户端请求的请求信息转化为目标命令行。然后通过执行该目标命令行，就可以得到第二客户端请求异常响应时，即出现线上问题时的场景。这样，在用户请求异常响应，即出现线上问题时，无需利用查看用户日志的方式拼凑用户请求参数进行场景复现，直接对与该响应异常用户请求的请求信息相同的用户请求进行拦截和转化，就能够基于转化得到的命令行，有效进行用户请求异常响应时的问题场景复现。因而，本公开实施例可以解决因无法获取到完整的用户请求参数，导致难以复现出现线上问题的场景的问题。

在本公开的一些实施例中，请求信息包括请求头信息、请求体信息和请求参数，转化模块320具体被配置为执行：将请求头信息、请求体信息和请求参数编码转化为可执行的目标命令行。

如此，在获取到客户端请求的请求头信息、请求体信息和请求参数之后，可以通过编码转化的方式快捷生成该客户端请求对应的目标命令行，而通过执行该目标命令行，就可以实现客户端请求异常响应时的问题场景复现，提升了故障复现的效率。

在本公开的一些实施例中，拦截模块310具体被配置为执行：调用线上诊断工具拦截第一客户端请求。

如此，开发人员无需通过用户日志中携带的参数自行拼接信息，通过调用线上诊断工具，就可以快速获取到第一客户端请求中携带的请求信息，也即异常响应的第二客户端请求的请求信息，从而有效提升问题场景复现的速度。

在本公开的一些实施例中，线上诊断工具包括阿尔萨斯arthas工具或greys工具。

如此，开发人员无需通过用户日志中携带的参数自行拼接信息，通过调用线上诊断工具，就可以快速获取到第一客户端请求中携带的请求信息，也即异常响应的第二客户端请求的请求信息，从而有效提升问题场景复现的速度。

在本公开的一些实施例中，arthas工具或greys工具包括对象导航图语言OGNL表达式，转化模块具体被配置为执行：基于OGNL表达式触发第一客户端请求的请求信息进行编码转化，得到可执行的目标命令行。

如此，基于arthas工具的OGNL表达式功能，可以触发第一客户端请求的请求信息进行编码转化，从而快速得到可执行的目标命令行。而采用查看日志、拼凑参数的方式来进行问题复现，此方法时间成本较高，并且当前遇到问题的场景用户请求的参数不一定满足场景复现的要求，因此该方法不一定可行。相比较而言，通过对客户端请求进行拦截并转化的方式，能够在互联网应用服务出现线上问题时快速复现问题，有效降低时间成本。

在本公开的一些实施例中，目标命令行包括curl命令行、wget命令行、httpie命令行中的任意一项。

如此，通过调用目标命令行对应的命令行工具来执行目标命令行，可以在互联网应用服务出现线上问题时快速复现问题，帮助开发人员更快地恢复服务，从而提升服务稳定性和质量。同时，避免了在问题发生时，开发人员需要通过日志中携带的参数自行拼接信息，相比于拼接日志参数进行问题复现的方式，从成功率和效率上都得到了很大的提升。

在本公开的一些实施例中，执行模块330具体被配置为执行：在目标命令行为curl命令行的情况下，调用应用程序编程接口API调试工具解析curl命令行，得到第二客户端请求异常响应时的场景。

这样，由于curl命令行除了携带了完整的复现需要的请求信息外，还能在任意终端被快速执行，因此只需要电脑中安装了API调试工具即可快捷执行调用，通过这一调用开发人员就可以进行问题的排查了。

在本公开的一些实施例中，该装置还包括：接收模块，被配置为执行在拦截第一客户端请求之前，接收第二客户端请求，第二客户端请求包括用户ID；拦截模块310具体被配置为执行：在第二客户端请求响应异常的情况下，调用arthas工具的watch命令拦截第一客户端请求，其中，watch命令包括用户ID。

如此，通过在watch命令中限定用户ID，可以针对个别用户的bug进行准确拦截，实现目标化拦截，提升请求拦截的准确率。

在本公开的一些实施例中，第一客户端请求和第二客户端请求用于实现客户端中应用程序的功能。

如此，在用户使用客户端的应用程序功能或网页功能的场景下，当用户的第一次操作触发的第二客户端请求异常响应时，服务器可以对用户的第二次操作触发的第一客户端请求进行准确拦截，并基于拦截到的第一客户端请求的请求信息进行问题场景复现。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图4是根据一示例性实施例示出的一种服务器的框图。参照图4，本公开实施例还提供了一种服务器，包括处理器410、通信接口420、存储器430和通信总线440，其中，处理器410、通信接口420和存储器430通过通信总线440完成相互间的通信。

该存储器430，用于存放处理器410可执行的指令。

该处理器410，用于执行存储器430上所存放的指令时，实现如下步骤：

拦截第一客户端请求，其中，第一客户端请求与响应异常的第二客户端请求的请求信息相同；

将第一客户端请求的请求信息转化为目标命令行；

执行目标命令行，得到第二客户端请求异常响应时的场景。

可见，应用本公开实施例，第二客户端请求为响应异常的用户请求，而第一客户端请求与第二客户端请求的请求信息相同，基于此，拦截第一客户端请求，并将该第一客户端请求的请求信息转化为目标命令行。然后通过执行该目标命令行，就可以得到第二客户端请求异常响应时，即出现线上问题时的场景。这样，在用户请求异常响应，即出现线上问题时，无需利用查看用户日志的方式拼凑用户请求参数进行场景复现，直接对与该响应异常用户请求的请求信息相同的用户请求进行拦截和转化，就能够基于转化得到的命令行，有效进行用户请求异常响应时的问题场景复现。因而，本公开实施例可以解决因无法获取到完整的用户请求参数，导致难以复现出现线上问题的场景的问题。

图5是根据一示例性实施例示出的用于请求处理方法的设备的框图。例如，该设备500可以被提供为一服务器。参照图5，服务器500包括处理组件522，其进一步包括一个或多个处理器，以及由存储器532所代表的存储器资源，用于存储可由处理组件522的执行的指令，例如应用程序。存储器532中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件522被配置为执行指令，以执行上述任一实施例所述的请求处理方法。

该设备500还可以包括一个电源组件525被配置为执行设备500的电源管理，一个有线或无线网络接口550被配置为执行将设备500连接到网络，和一个输入输出(I/O)接口558。设备500可以操作基于存储在存储器532的操作系统，例如Windows ServerTM，Mac OSXTM，UnixTM，LinuxTM，FreeBSDTM或类似。

在本公开一些实施例中，还提供了一种计算机可读存储介质，当该计算机可读存储介质中的指令由服务器的处理器执行时，使得服务器能够执行上述任一实施例所述的请求处理方法。

可选地，计算机可读存储介质可以是计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在本公开一些实施例中，还提供了一种计算机程序产品，包括计算机指令，计算机指令被处理器执行时实现上述任一实施例所述的请求处理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (16)

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

拦截第一客户端请求，其中，所述第一客户端请求与响应异常的第二客户端请求的请求信息相同；

将所述第一客户端请求的请求信息转化为目标命令行；

执行所述目标命令行，得到所述第二客户端请求异常响应时的场景；

其中，所述请求信息包括请求头信息、请求体信息和请求参数，所述将所述第一客户端请求的请求信息转化为目标命令行，包括：

将所述请求头信息、请求体信息和请求参数编码转化为可执行的所述目标命令行；

所述拦截第一客户端请求，包括：

调用线上诊断工具拦截所述第一客户端请求。

2.根据权利要求1所述的方法，其特征在于，所述线上诊断工具包括阿尔萨斯arthas工具或greys工具。

3.根据权利要求2所述的方法，其特征在于，所述arthas工具或greys工具包括对象导航图语言OGNL表达式，所述将所述第一客户端请求的请求信息转化为目标命令行，包括：

基于所述OGNL表达式触发所述第一客户端请求的请求信息进行编码转化，得到可执行的所述目标命令行。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述目标命令行包括curl命令行、wget命令行、httpie命令行中的任意一项。

5.根据权利要求4所述的方法，其特征在于，在所述目标命令行为所述curl命令行的情况下，所述执行所述目标命令行，得到所述第二客户端请求异常响应时的场景，包括：

调用应用程序编程接口API调试工具解析所述curl命令行，得到所述第二客户端请求异常响应时的场景。

6.根据权利要求2所述的方法，其特征在于，在所述拦截第一客户端请求之前，所述方法还包括：

接收所述第二客户端请求，所述第二客户端请求包括用户ID；

所述拦截第一客户端请求，包括：

在所述第二客户端请求响应异常的情况下，调用所述arthas工具的watch命令拦截所述第一客户端请求，其中，所述watch命令包括所述用户ID。

7.根据权利要求1所述的方法，其特征在于，所述第一客户端请求和所述第二客户端请求用于实现客户端中应用程序的功能。

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

拦截模块，被配置为执行拦截第一客户端请求，其中，所述第一客户端请求与响应异常的第二客户端请求的请求信息相同；

转化模块，被配置为执行将所述第一客户端请求的请求信息转化为目标命令行；

执行模块，被配置为执行所述目标命令行，得到所述第二客户端请求异常响应时的场景；

其中，所述请求信息包括请求头信息、请求体信息和请求参数，所述转化模块具体被配置为执行：

将所述请求头信息、请求体信息和请求参数编码转化为可执行的所述目标命令行；

所述拦截模块具体被配置为执行：

调用线上诊断工具拦截所述第一客户端请求。

9.根据权利要求8所述的装置，其特征在于，所述线上诊断工具包括阿尔萨斯arthas工具或greys工具。

10.根据权利要求9所述的装置，其特征在于，所述arthas工具或greys工具包括对象导航图语言OGNL表达式，所述转化模块具体被配置为执行：

基于所述OGNL表达式触发所述第一客户端请求的请求信息进行编码转化，得到可执行的所述目标命令行。

11.根据权利要求8-10任一项所述的装置，其特征在于，所述目标命令行包括curl命令行、wget命令行、httpie命令行中的任意一项。

12.根据权利要求11所述的装置，其特征在于，所述执行模块具体被配置为执行：

在所述目标命令行为所述curl命令行的情况下，调用应用程序编程接口API调试工具解析所述curl命令行，得到所述第二客户端请求异常响应时的场景。

13.根据权利要求9所述的装置，其特征在于，所述装置还包括：

接收模块，被配置为执行在所述拦截第一客户端请求之前，接收所述第二客户端请求，所述第二客户端请求包括用户ID；

所述拦截模块具体被配置为执行：

在所述第二客户端请求响应异常的情况下，调用所述arthas工具的watch命令拦截所述第一客户端请求，其中，所述watch命令包括所述用户ID。

14.根据权利要求8所述的装置，其特征在于，所述第一客户端请求和所述第二客户端请求用于实现客户端中应用程序的功能。

15.一种服务器，其特征在于，包括：

处理器；

被配置为执行存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1-7中任一项所述的请求处理方法。

16.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由服务器的处理器执行时，使得所述服务器能够执行如权利要求1-7中任一项所述的请求处理方法。

Images