CN104270362A - 请求处理方法和装置 - Google Patents

Abstract

本发明公开了一种请求处理方法和装置，属于计算机网络技术领域。所述请求处理方法包括：接收客户端发送的业务处理请求；判断业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；如果业务处理请求是预定类型的请求，则将业务处理请求发送给第一处理逻辑进行处理；如果业务处理请求不是预定类型的请求，则将业务处理请求发送给第二处理逻辑进行处理；其中，第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

Description

请求处理方法和装置

技术领域

本发明涉及计算机网络技术领域，特别涉及一种请求处理方法和装置。

背景技术

当客户端需要从服务器中获取服务时，客户端可以发送业务处理请求至服务器，由服务器对业务处理请求进行处理。

现有的一种请求处理方法包括：客户端发送业务处理请求至负载均衡服务器；负载均衡服务器接收该业务处理请求，根据各个代理服务器的负载配置转发该业务处理请求至对应的代理服务器，由代理服务器对业务处理请求进行处理。

在实现本发明的过程中，发明人发现上述技术至少存在以下问题：代理服务器通常运行有基于Java语言开发的处理逻辑，代理服务器在同一时刻能够处理的业务处理请求的数量存在上限，也就是说，当代理服务器同时接收到多个业务处理请求时，客户端发送的业务处理请求可能不能被及时处理。

发明内容

为了解决现有技术中客户端发出的业务处理请求可能不能被及时处理的问题，本发明实施例提供了一种请求处理方法和装置。所述技术方案如下：

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

接收客户端发送的业务处理请求；

判断所述业务处理请求是否是预定类型的请求，所述预定类型的请求是处理复杂度低于预设复杂度的请求；

如果所述业务处理请求是所述预定类型的请求，则将所述业务处理请求发送给第一处理逻辑进行处理；

如果所述业务处理请求不是所述预定类型的请求，则将所述业务处理请求发送给第二处理逻辑进行处理；

其中，所述第一处理逻辑的处理速度优于所述第二处理逻辑的处理速度，且所述第一处理逻辑的处理能力弱于所述第二处理逻辑的处理能力。

可选地，所述第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

所述第二处理逻辑是基于Java语言开发的处理逻辑。

可选地，所述判断所述业务处理请求是否是预定类型的请求之前，还包括：

对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括用于处理所述业务处理请求的代码逻辑的代码长度；

检测所述处理信息是否满足预设条件，所述预设条件包括所述代码长度小于预定长度；

如果所述处理信息满足所述预设条件，则将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

可选地，所述判断所述业务处理请求是否是预定类型的请求之前，还包括：

对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括所述业务处理请求的平均处理时长和用于处理所述业务处理请求的代码逻辑的代码长度；

检测所述处理信息是否满足预设条件，所述预设条件包括所述平均处理时长大于预定时长和所述代码长度小于预定长度；

如果所述处理信息满足所述预设条件，则将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

可选地，所述判断所述业务处理请求是否是预定类型的请求之前，还包括：

对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括：所述业务处理请求的平均处理时长、用于处理所述业务处理请求的代码逻辑中的子逻辑的数量和每个所述子逻辑的代码长度；

检测所述处理信息是否满足预设条件，所述预设条件包括：所述平均处理时长大于预定时长、所述代码逻辑中的子逻辑的数量为两个或者两个以上和至少有一个所述子逻辑的代码长度小于预定长度；

如果所述处理信息满足所述预设条件，则将用于处理所述业务处理请求的代码逻辑中，所述代码长度小于所述预定长度的所述子逻辑移植至所述第一处理逻辑，并将移植后的所述子逻辑所对应的业务处理请求标记为所述预定类型的请求。

可选地，所述处理信息还包括：所述业务处理请求在单位时长内的并发量；

所述预设条件还包括：所述业务处理请求在所述单位时长内的并发量是否超过预定阈值。

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

请求接收模块，用于接收客户端发送的业务处理请求；

请求判断模块，用于判断所述请求接收模块接收到的所述业务处理请求是否是预定类型的请求，所述预定类型的请求是处理复杂度低于预设复杂度的请求；

第一发送模块，用于在所述请求判断模块的判断结果为所述业务处理请求是所述预定类型的请求时，将所述业务处理请求发送给第一处理逻辑进行处理；

第二发送模块，用于在所述请求判断模块的判断结果为所述业务处理请求不是所述预定类型的请求时，将所述业务处理请求发送给第二处理逻辑进行处理；

其中，所述第一处理逻辑的处理速度优于所述第二处理逻辑的处理速度，且所述第一处理逻辑的处理能力弱于所述第二处理逻辑的处理能力。

可选地，所述第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

所述第二处理逻辑是基于Java语言开发的处理逻辑。

可选地，所述装置还包括：

第一获取模块，用于对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括用于处理所述业务处理请求的代码逻辑的代码长度；

第一检测模块，用于检测所述第一获取模块获取到的所述处理信息是否满足预设条件，所述预设条件包括所述代码长度小于预定长度；

第一结果模块，用于在所述第一检测模块的检测结果为所述处理信息满足所述预设条件时，将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

可选地，所述装置还包括：

第二获取模块，用于对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括所述业务处理请求的平均处理时长和用于处理所述业务处理请求的代码逻辑的代码长度；

第二检测模块，用于检测所述第二获取模块获取到的所述处理信息是否满足预设条件，所述预设条件包括所述平均处理时长大于预定时长和所述代码长度小于预定长度；

第二结果模块，用于在所述第二检测模块的检测结果为所述处理信息满足所述预设条件时，将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

可选地，第三获取模块，用于对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括：所述业务处理请求的平均处理时长、用于处理所述业务处理请求的代码逻辑中的子逻辑的数量和每个所述子逻辑的代码长度；

第三检测模块，用于检测所述第三获取模块获取到的所述处理信息是否满足预设条件，所述预设条件包括：所述平均处理时长大于预定时长、所述代码逻辑中的子逻辑的数量为两个或者两个以上和至少有一个所述子逻辑的代码长度小于预定长度；

第三结果模块，用于在所述第三检测模块的检测结果为所述处理信息满足所述预设条件时，将用于处理所述业务处理请求的代码逻辑中，所述代码长度小于所述预定长度的所述子逻辑移植至所述第一处理逻辑，并将移植后的所述子逻辑所对应的业务处理请求标记为所述预定类型的请求。

可选地，所述处理信息还包括：所述业务处理请求在单位时长内的并发量；

所述预设条件还包括：所述业务处理请求在所述单位时长内的并发量是否超过预定阈值。

本发明实施例提供的技术方案的有益效果是：

通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

附图说明

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

图1是本发明所涉及的一种实施环境的结构示意图；

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

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

图4是本发明再一实施例提供的请求处理方法的方法流程图；

图5A是本发明再一实施例提供的请求处理方法的方法流程图；

图5B是本发明再一实施例提供的请求处理方法的实施环境的结构示意图；

图6是本发明一个实施例提供的请求处理装置的结构方框图；

图7是本发明另一个实施例提供的请求处理装置的结构方框图；

图8是本发明再一个实施例提供的请求处理装置的结构方框图；

图9是本发明再一个实施例提供的请求处理装置的结构方框图；

图10是本发明一个实施例提供的服务器的结构方框图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参考图1，其示出了本发明各个实施例所涉及的实施环境的结构示意图，如图1所示，该实施环境可以包括客户端110和服务器120。

客户端110是运行在终端中的、由服务提供方提供的客户端。客户端110可以通过有线或者无线网络与服务器120连接。

服务器120是服务提供方提供的服务器，用于与客户端110结合来为用户提供服务。服务器120可以通过有线或者无线网络与客户端110连接。

请参考图2，其示出了本发明一个实施例提供的请求处理方法的方法流程图，本实施例以该请求处理方法用于图1所示的服务器120中来举例说明。如图2所示，该请求处理方法包括：

步骤201，接收客户端发送的业务处理请求；

步骤202，判断业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

步骤203，如果业务处理请求是预定类型的请求，则将业务处理请求发送给第一处理逻辑进行处理；

步骤204，如果业务处理请求不是预定类型的请求，则将业务处理请求发送给第二处理逻辑进行处理。

其中，第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力。

综上所述，本实施例提供的请求处理方法，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

需要说明的是，在服务器判断业务处理请求是否是预定类型的请求之前，服务器还可以先标记哪些业务处理请求是预定类型的请求，而哪些业务处理请求不是预定类型的请求，所以下述将在不同实施例中对不同标记情况下的请求处理方法进行详细介绍。

请参考图3，其示出了本发明另一实施例提供的请求处理方法的方法流程图，本实施例以该请求处理方法用于图1所示的服务器120中来举例说明。如图3所示，该请求处理方法包括：

步骤301，对于第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括用于处理业务处理请求的代码逻辑的代码长度；

对于第二处理逻辑中历史处理的各种业务处理请求，服务器可以获取每一种业务处理请求的处理信息。其中，每一种业务处理请求的处理信息包括用于处理业务处理请求的代码逻辑的代码长度。第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力。第一处理逻辑可以是基于脚本语言Lua开发的处理逻辑，第二处理逻辑可以是基于Java开发的处理逻辑。

比如，当处理信息包括用于处理业务处理请求的代码逻辑的代码长度时，服务器可以获取每种业务处理请求的代码长度。

具体的，服务器可以预先存储每种业务处理请求的处理信息，当服务器需要获取该处理信息时，服务器可以读取保存的第二处理逻辑处理的每种业务处理请求的处理信息。或者，服务器还可以发送信息获取请求至第二处理逻辑，接收第二处理逻辑返回的每种业务处理请求的处理信息，本实施例对服务器获取处理信息的获取方法并不做限定。

步骤302，检测处理信息是否满足预设条件，预设条件包括代码长度小于预定长度；

对于服务器获取到的每种业务处理请求的处理信息，服务器可以检测该处理信息是否满足预设条件。预设条件包括代码长度小于预定长度。具体的，服务器可以检测获取到的代码长度是否小于预定长度；如果服务器的检测结果为代码长度小于预定长度，则服务器可以确定该业务处理请求的处理信息满足预设条件；反之，如果服务器的检测结果为代码长度不小于预定长度，则服务器可以确定该业务处理请求的处理信息不满足预设条件。

比如，当预定长度为30行，服务器获取到的用于处理某一业务处理请求的代码逻辑的代码长度为25行时，服务器可以检测获取到的代码长度25行是否小于预定长度30行。

其中，预定长度是根据第一处理逻辑的处理能力预先设置的长度。比如，第一处理逻辑可以处理的代码逻辑的最大代码长度为50行，则预定长度可以为小于等于50行的长度，如40行；而如果第一处理逻辑可以处理的代码逻辑的最大代码长度为30行，则预定长度即为小于等于30行的长度，如30行，本实施例对此并不做限定。

步骤303，如果处理信息满足预设条件，则将业务处理请求标记为预定类型的请求，并在第一处理逻辑中增加用于处理业务处理请求的代码逻辑；

如果服务器的检测结果为处理信息满足预设条件，则说明该业务处理请求的处理逻辑较为简单，处理能力较弱的第一处理逻辑能够处理该业务处理请求，此时，服务器可以将该业务处理请求标记为预定类型的请求，并在第一处理逻辑中增加用于处理该业务处理请求的代码逻辑。其中，预定类型的请求是处理复杂度低于预设复杂度的请求。

而如果服务器的检测结果为不小于预定长度，则说明该业务处理请求的处理逻辑较为复杂，第一处理逻辑可能无法处理，此时，服务器可以不做任何标记。

需要说明的是，服务器在第一处理逻辑中增加用于处理业务处理请求的代码逻辑的增加方法可以包括：服务器接收用户在目标网页中输入的对应于该业务处理请求的代码逻辑，在第一处理逻辑中增加接收到的该代码逻辑。

比如，当第一处理逻辑为基于Lua开发的处理逻辑时，由于Lua编写的代码是轻量级的代码，所以本实施例通过代码在线生成的方式直接接收开发人员在Web网页中输入的代码逻辑，这样，在经过简单测试之后，该代码逻辑即可用于处理对应的业务处理请求，也即可以马上投入应用，这比更改基于Java开发的第二处理逻辑的更改复杂度要低得多(当需要更改基于Java开发的第二处理逻辑时，需要暂停第二处理逻辑的使用，重写编写第二处理逻辑的代码逻辑，发布并测试该代码逻辑，在测试通过后重启并加载重新编写的代码逻辑之后开始使用)。

步骤304，接收客户端发送的业务处理请求；

当客户端需要从服务器中获取服务时，客户端可以发送业务处理请求至服务器，相应的服务器可以接收客户端发送的业务处理请求。

步骤305，判断业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

服务器接收到客户端发送的业务处理请求之后，服务器可以判断接收到的该业务处理请求是否是预定类型的请求。其中，预定类型的请求是处理复杂度低于预设复杂度的请求。

具体的，服务器可以检测接收到的该业务处理请求是否是之前标记的预定类型的请求；如果是，则服务器可以判定该业务处理请求是预定类型的请求；反之，则服务器可以判定该业务处理请求不是预定类型的请求。

步骤306，如果业务处理请求是预定类型的请求，则将业务处理请求发送给第一处理逻辑进行处理；

如果服务器的判断结果为业务处理请求是预定类型的请求，则说明该业务处理请求所对应的处理逻辑较为简单，处理速度更快的第一处理逻辑可以处理该业务处理请求，此时服务器可以发送该业务处理请求至第一处理逻辑，由第一处理逻辑对该业务处理请求进行处理。

步骤307，如果业务处理请求不是预定类型的请求，则将业务处理请求发送给第二处理逻辑进行处理。

而如果服务器的判断结果为该业务处理请求不是预定类型的请求，则说明该业务处理请求所对应的处理逻辑较为复杂，处理速度更快的第一处理逻辑可能无法处理该业务处理请求，此时，服务器可以发送该业务处理请求至处理能力较强的第二处理逻辑，由第二处理逻辑对该业务处理请求进行处理。

综上所述，本实施例提供的请求处理方法，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

本实施例通过确定第二处理逻辑处理的各个业务处理请求中，处理逻辑较为简单(也即处理能力较弱但处理速度更快的第一处理逻辑能够处理)的业务处理请求，在第一处理逻辑中增加用于处理该业务处理请求的代码逻辑，提高了该业务处理请求被处理时的处理效率。同时，由于第一处理逻辑的处理速度优于第二处理逻辑的处理速度，所以这就在无形中增加了第一处理逻辑和第二处理逻辑能够并发处理的业务处理请求的数量，提高了系统对并发业务处理请求的处理能力。

请参考图4，其示出了本发明再一实施例提供的请求处理方法的方法流程图，本实施例以该请求处理方法用于图1所示的服务器120中来举例说明。如图4所示，该请求处理方法可以包括：

步骤401，对于第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括业务处理请求的平均处理时长和用于处理业务处理请求的代码逻辑的代码长度；

与上述实施例类似的是，对于第二处理逻辑中历史处理的各个业务处理请求，服务器仍然可以获取每一种业务处理请求的处理信息。只是在本实施例中，业务处理请求的处理信息可以同时包括业务处理请求的平均处理时长和用于处理该业务处理请求的代码逻辑的代码长度。

其中，服务器获取用于处理业务处理请求的代码逻辑的代码长度的获取方式与上述实施例的获取方式类似，详细技术细节请参考上述实施例，本实施例在此不再赘述。

本实施例对服务器获取业务处理请求的平均处理时长进行简单说明。具体的，服务器可以统计在单位时长内(比如一天)第二处理逻辑处理的各个业务处理请求的处理时长，计算同种类型的业务处理请求的处理时长的平均值，将计算得到的平均值作为业务处理请求的平均处理时长。

步骤402，检测处理信息是否满足预设条件，预设条件包括平均处理时长大于预定时长和代码长度小于预定长度；

在服务器获取到每种业务处理请求的处理信息之后，服务器可以检测处理信息是否满足预设条件。预设条件包括平均处理时长大于预定时长和代码长度小于预定长度。

其中，预定时长可以是根据该业务处理请求被及时处理时的处理时长设置的阈值。比如，业务处理请求被第二处理逻辑及时处理时的处理时长为10ms，则该预定时长可以设置为10ms；当业务处理请求被第二处理逻辑及时处理时的处理时长为15ms，则该预定时长即可设置为15ms，本实施例对此并不做限定。

预定长度是根据第一处理逻辑的处理能力预先设置的长度。这与上述实施例的设置方式类似，详细技术细节请参考上述实施例，本实施在此不再赘述。

具体的，服务器可以检测处理信息中的平均处理时长是否大于预定时长，且检测处理信息中的代码长度是否小于预定长度。如果服务器的检测结果为平均处理时长大于预定时长且代码长度小于预定长度，则服务器可以确定获取到的处理信息满足预设条件；而如果服务器的检测结果为平均处理时长小于预定时长或者代码长度小于预定长度，则服务器可以确定获取到的处理信息不满足预设条件。

在实际实现时，服务器可以同时检测平均处理时长是否大于预定时长以及代码长度是否小于预定时长，也可以先检测平均处理时长是否大于预定时长后检测代码长度是否小于预定长度；或者先检测代码长度是否小于预定长度后检测平均处理时长是否大于预定时长，本实施例对此并不做限定。

步骤403，如果处理信息满足预设条件，则将业务处理请求标记为预定类型的请求，并在第一处理逻辑中增加用于处理业务处理请求的代码逻辑；

如果服务器的检测结果为处理信息满足预设条件，则说明该业务处理请求的处理逻辑虽然简单，但是第二处理逻辑在处理该业务处理请求时需要耗用的时长已经超出正常需要时长，也即第二处理逻辑在处理业务处理请求时的压力可能比较大，此时，服务器可以将该业务处理请求标记为预定类型的请求，并在第一处理逻辑中增加用于处理业务处理请求的代码逻辑。

需要说明的是，服务器在第一处理逻辑中增加用于处理业务处理请的代码逻辑的步骤可以包括：服务器接收用户在目标网页中输入的对应于该业务处理请求的代码逻辑，在第一处理逻辑中增加接收到的该代码逻辑。这与上述实施例中在第一处理逻辑中增加用于处理业务处理请求的代码逻辑的增加方式类似，详细技术细节请参考上述实施例，本实施例在此不再赘述。

步骤404，接收客户端发送的业务处理请求；

步骤405，判断业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

步骤406，如果业务处理请求是预定类型的请求，则将业务处理请求发送给第一处理逻辑进行处理；

步骤407，如果业务处理请求不是预定类型的请求，则将业务处理请求发送给第二处理逻辑进行处理。

需要说明的是，步骤404至步骤407与上述实施例中的步骤304至步骤307类似，详细技术细节请参考上述实施例，本实施例在此不做赘述。

综上所述，本实施例提供的请求处理方法，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

本实施例在第二处理逻辑处理某业务处理请求有压力，且该业务处理请求为需要的处理逻辑较简单(也即处理能力较弱但处理速度更快的第一处理处理能够处理)的请求时，服务器可以在第一处理逻辑中增加用于处理该业务处理请求的代码逻辑，提高了对该业务处理请求的响应效率。同时，由于服务器将该业务处理请求从第二处理逻辑中迁出，也降低了第二处理逻辑的处理压力，提高了第二处理逻辑对非预定类型的请求的响应速度。

请参考图5A，其示出了本发明再一实施例提供的请求处理方法的方法流程图，本实施例以该请求处理方法用于图1所示的服务器120中来举例说明。如图5A所示，该请求处理方法包括：

步骤501，对于第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括：业务处理请求的平均处理时长、用于处理业务处理请求的代码逻辑中的子逻辑的数量和每个子逻辑的代码长度；

与上述实施例类似的是，在本实施例中，对于第二处理逻辑中历史处理的各种业务处理请求，服务器可以获取每一种业务处理请求的处理信息。但是在本实施例中，每一种业务处理请求的处理信息包括业务处理请求的平均处理时长、用于处理业务处理请求的代码逻辑中的子逻辑的数量和每个子逻辑的代码长度。

对于处理信息中的业务处理请求的平均处理时长，服务器采用的获取方式与上述实施例类似，详细技术细节请参考上述实施例，本实施例在此不再赘述。

对于处理信息中的代码逻辑中的子逻辑的数量以及每个子逻辑的代码长度，服务器可以采用与图3所对应的实施例中服务器获取业务处理请求的代码逻辑类似的获取方式进行获取。

比如，对于业务处理请求a，服务器可以读取保存的用于处理该业务处理请求的代码逻辑A，代码逻辑A中的子逻辑包括A1、A2和A3，每个子逻辑的代码长度为L1、L2和L3。

步骤502，检测处理信息是否满足预设条件，预设条件包括：平均处理时长大于预定时长、代码逻辑中的子逻辑的数量为两个或者两个以上和至少有一个子逻辑的代码长度小于预定长度；

对于服务器获取到的每种业务处理请求的处理信息，服务器可以检测该业务处理请求是否满足预设条件。在本实施例中，预设条件包括平均处理时长大于预定时长、代码逻辑中的子逻辑的数量为两个或者两个以上以及两个或者两个以上的子逻辑中至少有一个子逻辑的代码长度小于预定长度。

其中，预定时长可以是根据该业务处理请求被及时处理时的处理时长设置的阈值。这与上述实施例中的预定时长的设置方式类似，本实施例在此不再赘述。

具体的，服务器可以检测业务处理请求的处理时长是否大于预定时长，检测代码逻辑中的子逻辑的数量是否为两个或者两个以上，同时检测各个子逻辑张是否存在某一个子逻辑的代码长度小于预定长度。其中，预定长度是根据第一处理逻辑的处理能力预先设置的长度，这与上述实施例的设置方式类似，详细技术细节请参考上述实施例，本实施在此不再赘述。

在实际实现时，服务器对上述三者的检测步骤可以任意搭配，本实施例对此并不做限定。

步骤503，如果处理信息满足预设条件，则将用于处理业务处理请求的代码逻辑中，代码长度小于预定长度的子逻辑移植至第一处理逻辑，并将移植后的子逻辑所对应的业务处理请求标记为预定类型的请求；

如果服务器的检测结果为处理信息满足预设条件，则说明该业务处理请求所对应的处理逻辑中有一部分是第一处理逻辑所能处理的处理逻辑，此时，为了提高业务处理请求的被处理的效率，且提高系统处理并发业务处理请求的数量，服务器可以将代码逻辑中代码长度小于预定长度的子逻辑移植至第一处理逻辑，并将移植后的子逻辑所对应的业务处理请求标记为预定类型的请求。

而如果服务器的检测结果为处理信息不满足预设条件，则此时服务器可以结束本流程。

需要说明的是，服务器将用于处理业务处理请求的代码逻辑中，代码长度小于预定长度的子逻辑移植至第一处理逻辑的步骤可以包括：服务器接收用户在目标网页中输入的对应于该业务处理请求的代码逻辑，在第一处理逻辑中增加接收到的该代码逻辑。这与上述实施例中在第一处理逻辑中增加用于处理业务处理请求的代码逻辑的增加方式类似，详细技术细节请参考上述实施例，本实施例在此不再赘述。

步骤504，接收客户端发送的业务处理请求；

步骤505，判断业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

步骤506，如果业务处理请求是预定类型的请求，则将业务处理请求发送给第一处理逻辑进行处理；

步骤507，如果业务处理请求不是预定类型的请求，则将业务处理请求发送给第二处理逻辑进行处理。

需要说明的是，步骤504至步骤507与上述实施例中的步骤304至步骤307类似，详细技术细节请参考上述实施例，本实施例在此不做赘述。

综上所述，本实施例提供的请求处理方法，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

本实施例通过将第二处理逻辑处理的业务处理请求中处理时长较长，业务处理请求所对应的代码逻辑中有两个或者两个以上的子逻辑，且两个或者两个以上的子逻辑中至少有一个子逻辑的代码长度小于预定长度中所涉及的代码长度小于预定长度的子逻辑迁移至第一处理逻辑进行处理，提高了对该业务处理请求的响应效率。同时，由于服务器将该业务处理请求从第二处理逻辑中迁出，也降低了第二处理逻辑的处理压力，提高了第二处理逻辑对非预定类型的请求的响应速度。

需要说明的第一点是，在上述各个实施例中，处理信息除了可以包括各个实施例所提到的内容之外，处理信息还可以包括业务处理请求在单位时长内的并发量。

具体的，服务器可以统计在单位时长内接收到的业务处理请求的数量，将统计得到的数量作为该业务处理请求在单位时长内的并发量。比如，服务器统计得到某一业务处理请求在1天内并发量为1000W。

相应的，预设条件还包括业务处理请求在单位时长内的并发量是否超过预定阈值。

当处理信息还包括并发量时，服务器还可以检测业务处理请求在单位时长内的并发量1000W是否超过预定阈值如888W。其中，预定阈值可以是根据第二处理逻辑的处理能力设置的阈值。比如，第二处理逻辑能够并发处理的业务处理请求的个数为888W，则服务器可以将预定阈值设置为888W；而如果第二处理逻辑能够并发处理的业务处理请求的个数为500W，则服务器可以将预定阈值设置为500W。需要说明的是，在实际实现时，第二处理逻辑可以有两个或者两个以上，第二处理逻辑能够并发处理的业务处理请求的并发量是指所有第二处理逻辑所能处理的业务处理请求的总量。

如果检测结果为超过预定阈值，则说明第二处理请求在处理业务处理请求时的处理压力较大，此时可以将对应的业务处理请求迁移至第一处理逻辑进行处理，也即服务器可以执行将该业务处理请求标记为预定类型的请求，且在第一处理逻辑中增加用于处理该业务处理请求的代码逻辑的步骤，本实施例在此不再赘述。

而如果服务器的检测结果为未超过预定阈值，则此时，服务器可以不执行任何操作，本实施例对此并不做限定。

需要说明的第二点是，在上述各个方法实施例中，第一处理逻辑可以是基于Lua开发的处理逻辑，第二处理逻辑可以是基于Java开发的处理逻辑，但是，本实施例对两者的实际开发语言并不做限定，只需要保证第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力低于第二处理逻辑的处理能力即可。第二处理逻辑即为现有使用的处理逻辑。

当第一处理逻辑为基于Lua开发的处理逻辑，第二处理逻辑为Java开发的处理逻辑时，经过测试可知，对于空业务逻辑的请求，第一处理逻辑的并发量为4W，第二处理逻辑的并发量为1W。所以本申请提供的请求处理方法所能支持的并发处理能力较强，这样即使服务器同时接收到大量业务处理请求，业务处理请求也能被即时处理，避免了现有技术中当客户端同时发出大量业务处理请求时，业务处理请求可能无法被即时处理的问题。

需要说明的第三点是，在实际实现时，第一处理逻辑和第二处理逻辑均可以有两个或者两个以上，服务器在接收到客户端发送的业务处理请求，进而需要发送业务处理请求至第一处理逻辑或者第二处理逻辑时，服务器可以根据各个第一处理逻辑的负载配置或者根据各个第二处理逻辑的负载配置，转发该业务处理请求至对应的处理逻辑，本实施例对此并不做限定。

在实际实现时，服务器可以为nginx服务器或者apache服务器，本实施例对此并不做限定。第一处理逻辑可以是基于Lua开发的处理逻辑，第一处理逻辑可以单独实现在一个基于Lua开发的服务器中，也可以在通过Lua模块实现在服务器中，本实施例对此也不做限定。同时，每个第二处理逻辑可以单独实现在一台Web服务器中，该Web服务器可以是基于Java开发的resin或者tomcat服务器，本实施例对此也不做限定。

在本实施例的一个实际应用场景中，请参考图5B，以服务器为包括Lua模块的nginx服务器(也即第一处理逻辑实现在该服务器中)，第二处理逻辑实现在单独的Web服务器中，且第二处理逻辑有3个为例，在nginx服务器接收到客户端发送的业务处理请求时，nginx服务器可以检测该业务处理请求是否是预定类型的请求；如果该业务处理请求是预定类型的请求，则nginx服务器通过内部的Lua模块直接处理也业务处理请求；而如果该业务处理请求不是预定类型的请求，则nginx服务器可以根据各个Web服务器的负载配置发送该业务处理请求至对应的Web服务器，由Web服务器对接收到的业务处理请求进行处理。

请参考图6，其示出了本发明一个实施例提供的请求处理装置的结构方框图，本实施例以该请求处理装置用于图1所示的服务器120中来举例说明。如图6所示，该请求处理装置可以包括：请求接收模块610、请求判断模块620、第一发送模块630和第二发送模块640。

请求接收模块610，用于接收客户端发送的业务处理请求；

请求判断模块620，用于判断请求接收模块610接收到的业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

第一发送模块630，用于在请求判断模块620的判断结果为业务处理请求是预定类型的请求时，将业务处理请求发送给第一处理逻辑进行处理；

第二发送模块640，用于在请求判断模块620的判断结果为业务处理请求不是预定类型的请求时，将业务处理请求发送给第二处理逻辑进行处理；

其中，第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力。

综上所述，本实施例提供的请求处理装置，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

请参考图7，其示出了本发明另一实施例提供的请求处理装置的结构方框图，本实施例以该请求处理装置用于图1所示的服务器120中来举例说明。如图7所示，该请求处理装置可以包括：请求接收模块710、请求判断模块720、第一发送模块730和第二发送模块740。

请求接收模块710，用于接收客户端发送的业务处理请求；

请求判断模块720，用于判断请求接收模块710接收到的业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

第一发送模块730，用于在请求判断模块720的判断结果为业务处理请求是预定类型的请求时，将业务处理请求发送给第一处理逻辑进行处理；

第二发送模块740，用于在请求判断模块720的判断结果为业务处理请求不是预定类型的请求时，将业务处理请求发送给第二处理逻辑进行处理；

其中，第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力。

可选地，第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

第二处理逻辑是基于Java语言开发的处理逻辑。

可选地，装置还包括：

第一获取模块750，用于对于第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括用于处理业务处理请求的代码逻辑的代码长度；

第一检测模块760，用于检测第一获取模块750获取到的处理信息是否满足预设条件，预设条件包括代码长度小于预定长度；

第一结果模块770，用于在第一检测模块760的检测结果为处理信息满足预设条件时，将业务处理请求标记为预定类型的请求，并在第一处理逻辑中增加用于处理业务处理请求的代码逻辑。

可选地，处理信息还包括：业务处理请求在单位时长内的并发量；

相应的，预设条件还包括：业务处理请求在单位时长内的并发量是否超过预定阈值。

综上所述，本实施例提供的请求处理装置，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

本实施例通过确定第二处理逻辑处理的各个业务处理请求中，处理逻辑较为简单(也即处理能力较弱但处理速度更快的第一处理逻辑能够处理)的业务处理请求，在第一处理逻辑中增加用于处理该业务处理请求的代码逻辑，提高了该业务处理请求被处理时的处理效率。同时，由于第一处理逻辑的处理速度优于第二处理逻辑的处理速度，所以这就在无形中增加了第一处理逻辑和第二处理逻辑能够并发处理的业务处理请求的数量，提高了系统对并发业务处理请求的处理能力。

请参考图8，其示出了本发明另一实施例提供的请求处理装置的结构方框图，本实施例以该请求处理装置用于图1所示的服务器120中来举例说明。如图8所示，该请求处理装置可以包括：请求接收模块810、请求判断模块820、第一发送模块830和第二发送模块840。

请求接收模块810，用于接收客户端发送的业务处理请求；

请求判断模块820，用于判断请求接收模块810接收到的业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

第一发送模块830，用于在请求判断模块820的判断结果为业务处理请求是预定类型的请求时，将业务处理请求发送给第一处理逻辑进行处理；

第二发送模块840，用于在请求判断模块820的判断结果为业务处理请求不是预定类型的请求时，将业务处理请求发送给第二处理逻辑进行处理；

其中，第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力。

可选地，第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

第二处理逻辑是基于Java语言开发的处理逻辑。

可选地，装置还包括：

第二获取模块850，用于对于第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括业务处理请求的平均处理时长和用于处理业务处理请求的代码逻辑的代码长度；

第二检测模块860，用于检测第二获取模块850获取到的处理信息是否满足预设条件，预设条件包括平均处理时长大于预定时长和代码长度小于预定长度；

第二结果模块870，用于在第二检测模块860的检测结果为处理信息满足预设条件时，将业务处理请求标记为预定类型的请求，并在第一处理逻辑中增加用于处理业务处理请求的代码逻辑。

可选地，处理信息还包括：业务处理请求在单位时长内的并发量；

相应的，预设条件还包括：业务处理请求在单位时长内的并发量是否超过预定阈值。

综上所述，本实施例提供的请求处理装置，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

本实施例在第二处理逻辑处理某业务处理请求有压力，且该业务处理请求为需要的处理逻辑较简单(也即处理能力较弱但处理速度更快的第一处理处理能够处理)的请求时，服务器可以在第一处理逻辑中增加用于处理该业务处理请求的代码逻辑，提高了对该业务处理请求的响应效率。同时，由于服务器将该业务处理请求从第二处理逻辑中迁出，也降低了第二处理逻辑的处理压力，提高了第二处理逻辑对非预定类型的请求的响应速度。

请参考图9，其示出了本发明另一实施例提供的请求处理装置的结构方框图，本实施例以该请求处理装置用于图1所示的服务器120中来举例说明。如图9所示，该请求处理装置可以包括：请求接收模块910、请求判断模块920、第一发送模块930和第二发送模块940。

请求接收模块910，用于接收客户端发送的业务处理请求；

请求判断模块920，用于判断请求接收模块910接收到的业务处理请求是否是预定类型的请求，预定类型的请求是处理复杂度低于预设复杂度的请求；

第一发送模块930，用于在请求判断模块920的判断结果为业务处理请求是预定类型的请求时，将业务处理请求发送给第一处理逻辑进行处理；

第二发送模块940，用于在请求判断模块920的判断结果为业务处理请求不是预定类型的请求时，将业务处理请求发送给第二处理逻辑进行处理；

其中，第一处理逻辑的处理速度优于第二处理逻辑的处理速度，且第一处理逻辑的处理能力弱于第二处理逻辑的处理能力。

可选地，第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

第二处理逻辑是基于Java语言开发的处理逻辑。

可选地，装置还包括：

第三获取模块950，用于对于第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括：业务处理请求的平均处理时长、用于处理业务处理请求的代码逻辑中的子逻辑的数量和每个子逻辑的代码长度；

第三检测模块960，用于检测第三获取模块950获取到的处理信息是否满足预设条件，预设条件包括：平均处理时长大于预定时长、代码逻辑中的子逻辑的数量为两个或者两个以上和至少有一个子逻辑的代码长度小于预定长度；

第三结果模块970，用于在第三检测模块960的检测结果为处理信息满足预设条件时，将用于处理业务处理请求的代码逻辑中，代码长度小于预定长度的子逻辑移植至第一处理逻辑，并将移植后的子逻辑所对应的业务处理请求标记为预定类型的请求。

可选地，处理信息还包括：业务处理请求在单位时长内的并发量；

相应的，预设条件还包括：业务处理请求在单位时长内的并发量是否超过预定阈值。

综上所述，本实施例提供的请求处理装置，通过将客户端发送的业务处理请求中处理速度更快的第一处理逻辑所能处理的业务处理请求发送至第一处理逻辑进行处理，进而在保证这些业务处理请求能被第一处理逻辑及时处理的同时，也缓解了第二处理逻辑的处理压力，保证了第一处理逻辑不能处理的业务处理请求能被第二处理逻辑及时处理；解决了现有技术中客户端发出的业务处理请求可能不能被及时处理的问题；达到了客户端发出的业务处理请求能被及时处理的效果。

本实施例通过将第二处理逻辑处理的业务处理请求中处理时长较长，业务处理请求所对应的代码逻辑中有两个或者两个以上的子逻辑，且两个或者两个以上的子逻辑中至少有一个子逻辑的代码长度小于预定长度中所涉及的代码长度小于预定长度的子逻辑迁移至第一处理逻辑进行处理，提高了对该业务处理请求的响应效率。同时，由于服务器将该业务处理请求从第二处理逻辑中迁出，也降低了第二处理逻辑的处理压力，提高了第二处理逻辑对非预定类型的请求的响应速度。

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

请参考图10，其示出了本发明一个实施例提供的服务器的结构示意图。所述服务器1000包括中央处理单元(CPU)1001、包括随机存取存储器(RAM)1002和只读存储器(ROM)1003的存储器1004，以及连接存储器1004和中央处理单元1001的系统总线1005。

根据本发明的各种实施例，所述服务器1000还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器1000可以通过连接在所述系统总线1005上的网络接口单元1006连接到网络1007，或者说，也可以使用网络接口单元1006来连接到其他类型的网络或远程计算机系统(未示出)。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，所述一个或者一个以上程序包含用于进行本发明实施例提供的请求处理方法的指令。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

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

Claims (12)

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

接收客户端发送的业务处理请求；

判断所述业务处理请求是否是预定类型的请求，所述预定类型的请求是处理复杂度低于预设复杂度的请求；

如果所述业务处理请求是所述预定类型的请求，则将所述业务处理请求发送给第一处理逻辑进行处理；

如果所述业务处理请求不是所述预定类型的请求，则将所述业务处理请求发送给第二处理逻辑进行处理；

其中，所述第一处理逻辑的处理速度优于所述第二处理逻辑的处理速度，且所述第一处理逻辑的处理能力弱于所述第二处理逻辑的处理能力。

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

所述第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

所述第二处理逻辑是基于Java语言开发的处理逻辑。

3.根据权利要求1所述的方法，其特征在于，所述判断所述业务处理请求是否是预定类型的请求之前，还包括：

对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括用于处理所述业务处理请求的代码逻辑的代码长度；

检测所述处理信息是否满足预设条件，所述预设条件包括所述代码长度小于预定长度；

如果所述处理信息满足所述预设条件，则将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

4.根据权利要求1所述的方法，其特征在于，所述判断所述业务处理请求是否是预定类型的请求之前，还包括：

对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括所述业务处理请求的平均处理时长和用于处理所述业务处理请求的代码逻辑的代码长度；

检测所述处理信息是否满足预设条件，所述预设条件包括所述平均处理时长大于预定时长和所述代码长度小于预定长度；

如果所述处理信息满足所述预设条件，则将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

5.根据权利要求1所述的方法，其特征在于，所述判断所述业务处理请求是否是预定类型的请求之前，还包括：

对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括：所述业务处理请求的平均处理时长、用于处理所述业务处理请求的代码逻辑中的子逻辑的数量和每个所述子逻辑的代码长度；

检测所述处理信息是否满足预设条件，所述预设条件包括：所述平均处理时长大于预定时长、所述代码逻辑中的子逻辑的数量为两个或者两个以上和至少有一个所述子逻辑的代码长度小于预定长度；

如果所述处理信息满足所述预设条件，则将用于处理所述业务处理请求的代码逻辑中，所述代码长度小于所述预定长度的所述子逻辑移植至所述第一处理逻辑，并将移植后的所述子逻辑所对应的业务处理请求标记为所述预定类型的请求。

6.根据权利要求3至5任一所述的方法，其特征在于，

所述处理信息还包括：所述业务处理请求在单位时长内的并发量；

所述预设条件还包括：所述业务处理请求在所述单位时长内的并发量是否超过预定阈值。

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

请求接收模块，用于接收客户端发送的业务处理请求；

请求判断模块，用于判断所述请求接收模块接收到的所述业务处理请求是否是预定类型的请求，所述预定类型的请求是处理复杂度低于预设复杂度的请求；

第一发送模块，用于在所述请求判断模块的判断结果为所述业务处理请求是所述预定类型的请求时，将所述业务处理请求发送给第一处理逻辑进行处理；

第二发送模块，用于在所述请求判断模块的判断结果为所述业务处理请求不是所述预定类型的请求时，将所述业务处理请求发送给第二处理逻辑进行处理；

其中，所述第一处理逻辑的处理速度优于所述第二处理逻辑的处理速度，且所述第一处理逻辑的处理能力弱于所述第二处理逻辑的处理能力。

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

所述第一处理逻辑是基于脚本语言Lua开发的处理逻辑；

所述第二处理逻辑是基于Java语言开发的处理逻辑。

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

第一获取模块，用于对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括用于处理所述业务处理请求的代码逻辑的代码长度；

第一检测模块，用于检测所述第一获取模块获取到的所述处理信息是否满足预设条件，所述预设条件包括所述代码长度小于预定长度；

第一结果模块，用于在所述第一检测模块的检测结果为所述处理信息满足所述预设条件时，将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

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

第二获取模块，用于对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括所述业务处理请求的平均处理时长和用于处理所述业务处理请求的代码逻辑的代码长度；

第二检测模块，用于检测所述第二获取模块获取到的所述处理信息是否满足预设条件，所述预设条件包括所述平均处理时长大于预定时长和所述代码长度小于预定长度；

第二结果模块，用于在所述第二检测模块的检测结果为所述处理信息满足所述预设条件时，将所述业务处理请求标记为所述预定类型的请求，并在所述第一处理逻辑中增加用于处理所述业务处理请求的代码逻辑。

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

第三获取模块，用于对于所述第二处理逻辑中历史处理的各种业务处理请求，获取每一种业务处理请求的处理信息，每一种业务处理请求的处理信息包括：所述业务处理请求的平均处理时长、用于处理所述业务处理请求的代码逻辑中的子逻辑的数量和每个所述子逻辑的代码长度；

第三检测模块，用于检测所述第三获取模块获取到的所述处理信息是否满足预设条件，所述预设条件包括：所述平均处理时长大于预定时长、所述代码逻辑中的子逻辑的数量为两个或者两个以上和至少有一个所述子逻辑的代码长度小于预定长度；

第三结果模块，用于在所述第三检测模块的检测结果为所述处理信息满足所述预设条件时，将用于处理所述业务处理请求的代码逻辑中，所述代码长度小于所述预定长度的所述子逻辑移植至所述第一处理逻辑，并将移植后的所述子逻辑所对应的业务处理请求标记为所述预定类型的请求。

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

所述处理信息还包括：所述业务处理请求在单位时长内的并发量；

所述预设条件还包括：所述业务处理请求在所述单位时长内的并发量是否超过预定阈值。