一种网络请求处理方法、服务器和系统与流程

本发明涉及信息技术处理领域，尤其涉及一种网络请求处理方法、服务器和系统。

背景技术：

Nginx是一款优秀的HTTP服务器，采用异步非阻塞模型，在高并发下能保持低资源低消耗，具有轻量级，高并发等优点。它使用高度模块化设计，有许多官方和第三方的模块可供选择。这些模块极大地扩展了Nginx的功能，使它能够应付业务场景中的各种需求。Nginx提供了定义良好的插件接口，开发者可以根据自己的需要编写独立模块，插入到HTTP处理的某个流程中。作为一款以高性能著称的服务器，Nginx基于C语言开发，这就要求插件的开发也必须使用C语言。但是，在产品迭代频繁，业务需求复杂的今天，C语言开发效率较低，第三方库偏少的缺点决定了它不适合开发业务代码。

为了提升开发效率，人们想到可以用其他语言来进行开发，然后通过接口加载进Nginx。目前，最典型的方案就是OpenResty。OpenResty是一个全功能的Web应用服务器。它打包了标准的Nginx核心，很多的常用的第三方模块，以及它们的大多数依赖项。通过众多进行良好设计的Nginx模块，OpenResty有效地把Nginx服务器转变为一个强大的Web应用服务器，基于它开发人员可以使用Lua编程语言对Nginx核心以及现有的各种Nginx C模块进行脚本编程，构建出高性能的Web应用。

但是，OpenResty使用Lua作为Nginx的嵌入语言，它的许多模块都是用Lua开发的。Lua作为一门小巧的脚本语言，可以很容易的被C/C++代码调用，也可以反过来调用C/C++的函数，这使得Lua在应用程序中可以被广泛应用。但是，它的性能没有原生的C/C++高，而且需要熟悉Lua的人进行专门的模块开发和维护，增大了团队的开发和后续的维护成本。

因此，在产品迭代频繁，业务需求复杂的今天，如果能够高效地开发和管理这些插件成为一个亟需解决的问题。

技术实现要素：

为此，本发明提供一种网络请求处理方法、服务器和系统，以力图解决或至少缓解上面存在的问题。

根据本发明的一个方面，提供一种网络请求处理方法，适于在网络服务器中执行，该网络服务器中预先创建并加载了一个或多个请求处理单元，其中每个请求处理单元都与一个网络请求相对应，该方法包括：接收来自客户端的网络请求；确定该网络请求的类型；根据该网络请求的类型确定对应的请求处理接口和请求处理单元；由所确定的请求处理接口调用所确定的请求处理单元进行处理；生成该网络请求的处理结果并返回给客户端。

可选地，在根据本发明的方法中，网络服务器包括插件管理器，该方法还包括：插件管理器根据第一配置信息加载请求处理单元；以及根据该网络请求的类型确定对应的请求处理接口和请求处理单元的步骤包括：在确定了请求处理接口之后，由该请求处理接口根据第二配置信息确定该网络请求所对应的请求处理单元，其中请求处理接口包括第一模块接口、第二模块接口和第三模块接口。

可选地，在根据本发明的方法中，插件管理器根据第一配置信息加载请求处理单元的步骤包括：解析第一配置信息中的路径指令，得到请求处理单元的名称、路径和配置信息；获取该请求处理单元的符号表；以及创建全局实例和类的实例，并执行初始化操作。

可选地，在根据本发明的方法中，根据网络请求的类型确定对应的请求处理接口的步骤包括：如果网络请求的类型为无需访问后端服务器的网络请求，则确定对应的请求处理接口为第一模块接口；如果网络请求的类型为只需访问一个后端服务器的网络请求，则确定对应的请求处理接口为第二模块接口；如果网络请求的类型为需要访问多个后端服务器的网络请求，则确定对应的请求处理接口为第三模块接口。

可选地，在根据本发明的方法中，当根据网络请求的类型所确定的请求处理接口为第一模块接口时，由所确定的请求处理接口调用所确定的请求处理单元进行处理的步骤包括：获取网络请求中的第一请求结构体，将其转换成请求类后发送给所确定的请求处理单元进行处理。生成网络请求的处理结果并返回给客户端的步骤包括：将请求处理单元处理后的结果转化为第二请求结构体，并根据该第二请求结构体生成网络请求的处理结果返回给客户端。

可选地，在根据本发明的方法中，当根据网络请求的类型所确定的请求处理接口为第二模块接口时，由所确定的请求处理接口调用所确定的请求处理单元进行处理的步骤包括：由所确定的请求处理单元生成请求缓冲发送到后端服务器进行处理。生成网络请求的处理结果并返回给客户端的步骤包括：接收后端服务器处理请求缓冲后所返回的响应正文，并根据该响应正文生成网络请求的处理结果返回给客户端。

可选地，在根据本发明的方法中，当根据网络请求的类型所确定的请求处理接口为第三模块接口时，由所确定的请求处理接口调用所确定的请求处理单元进行处理的步骤包括：将网络请求解析为多个子请求，分别调用每个子请求所对应的请求处理单元；各请求处理单元分别生成对应的请求缓冲发送到后端服务器进行处理。生成网络请求的处理结果并返回给客户端的步骤包括：各子请求所对应的请求处理单元分别接收对应的后端服务器所返回的响应正文，并根据接收到的所有响应正文生成网络请求的处理结果返回给客户端。

根据本发明的另一个方面，提供网络服务器，该网络服务器中预先创建并加载了一个或多个请求处理单元，其中每个请求处理单元都与一个网络请求相对应，该服务器包括：分配单元，适于接收来自客户端的网络请求，并确定该网络请求的类型，以及根据该网络请求的类型确定对应的请求处理接口和请求处理单元；请求处理接口接收分配单元所分配的网络请求，并根据该网络请求的类型调用对应的请求处理单元进行处理；以及结果返回单元，适于生成网络请求的处理结果并返回到客户端。

可选地，在根据本发明的网络服务器中，网络服务器包括插件管理器，适于根据第一配置信息加载请求处理单元；请求处理接口包括第一模块接口、第二模块接口和第三模块接口，并适于根据第二配置信息确定网络请求所对应的请求处理单元。

可选地，在根据本发明的网络服务器中，插件管理器适于解析第一配置信息中的路径指令，得到请求处理单元的名称、路径和配置信息；获取该请求处理单元的符号表；以及创建全局实例和类的实例，并执行初始化操作，从而加载请求处理单元。

可选地，在根据本发明的网络服务器中，分配单元适于：在网络请求的类型为无需访问后端服务器的网络请求时，确定对应的请求处理接口为第一模块接口；在网络请求的类型为只需访问一个后端服务器的网络请求时，确定对应的请求处理接口为第二模块接口；在网络请求的类型为需要访问多个后端服务器的网络请求时，确定对应的请求处理接口为第三模块接口。

可选地，在根据本发明的网络服务器中，第一模块接口适于：将网络请求中的第一请求结构体转换成请求类；将请求类发送给该网络请求所对应的请求处理单元进行处理；将请求处理单元处理后的结果转化为第二请求结构体；以及根据第二请求结构体生成处理结果并返回给结果返回单元。

可选地，在根据本发明的网络服务器中，第二模块接口适于：由已确定的请求处理单元生成请求缓冲发送到后端服务器进行处理；接收后端服务器处理请求缓冲后所返回的响应正文；根据响应正文生成处理结果并返回给结果返回单元。

可选地，在根据本发明的网络服务器中，第三模块接口适于：将网络请求解析为多个子请求；分别调用每个子请求所对应的请求处理单元；各请求处理单元分别生成对应的请求缓冲发送到后端服务器进行处理，并分别接收后端服务器所返回的响应正文；以及根据接收到的所有响应正文生成处理结果并返回给结果返回单元。

根据本发明的另一个方面，提供一种网络请求处理系统，包括如上所述的网络服务器和至少一个终端设备。

根据本发明的技术方案，根据不同的请求访问类型，将与Nginx交互的通用处理过程分离出来作为三个模块，同时提供对外的接口基类，并定义了HTTP处理的相关字段和回调函数。业务逻辑的开发基于这些定义好的接口，不同的访问请求直接分配到对应的模块接口，由该模块接口调用对应的请求处理单元进行处理，从而实现了业务逻辑和接口的分离。这样，开发人员不需要了解Nginx的实现细节，只需要实现相应的回调函数即可对访问请求进行处理，避免处理复杂的HTTP协议、网络IO事件等所引起的响应速度缓慢问题。这种基于动态库的插件化框架降低了系统的耦合度，框架和动态库的开发和维护由不同的操作者进行，明显提高了开发效率。

附图说明

为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

图1示出了根据本发明一个实施例的网络请求处理系统100的示意图；

图2示出了根据本发明一个实施例的网络服务器200的结构示意图；

图3A-3D分别示出了不同网络请求类型的示意图；

图4示出了根据本发明另一个实施例的网络服务器400的结构示意图；

图5示出了根据本发明一个实施例的网络请求处理方法500的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的网络请求处理系统100的示意图。如图1所示，该系统100包括一个网络服务器110和至少一个智能终端(如图1中的132、134、136和138)，其中网络服务器110和智能终端之间通过互联网120通信连接。网络服务器110可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者是一个云计算服务中心。此外，用于组成服务器集群或云计算服务中心的多个服务器可以驻留在多个地理位置中，本发明对网络服务器110的部署方式不做限制。智能终端(132、134、136和138)可以是可连网的车载导航，手机、平板电脑等移动设备，也可以是智能手表、智能眼镜等可以连网的可穿戴设备。虽然图1中仅示例性地示出了4个智能终端(如图1中的132、134、136和138)，但是本领域技术人员可以意识到，该系统中还可以包括多个智能终端，本发明对网络请求处理系统100中的智能终端的数目并无限制。智能终端(132、134、136和138)可以以有线或无线的方式与网络服务器建立连接。当然，在大多数访问情境中，智能终端(132、134、136和138)与网络服务器110建立的是无线连接，例如，采用3G、4G、WiFi、个人热点、IEEE802.11x、蓝牙等技术建立无线连接。

网络服务器110向智能终端132、134、136和138提供相关网络服务，如响应于用户在网站上提交的查询某一品牌的车型的请求，向用户返回查询结果。根据本发明的一个实施例，该网络服务器110可以是Nginx服务器，Nginx是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器，作为一个系统最前端的接入层，负责接收用户HTTP请求，解析信息和预处理等工作，其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。

图2示出了根据本发明一个实施例的网络服务器200的结构示意图。该网络服务器200中预先创建并加载了一个或多个请求处理单元260，该网络服务器200包括分配单元220、请求处理接口240、请求处理单元260和结果返回单元280。其中，请求处理接口240如图2中的第一模块接口2402、第二模块接口2404和第三模块接口2406所示，请求处理单元260如图2中的请求处理单元2602、2604和2606所示，当然其数量并不如图2中所示，本发明对这两者的数量不作限制。

分配单元220接收来自客户端的网络请求并确定该网络请求的类型，以及根据该网络请求的类型确定对应的请求处理接口240和请求处理单元260。如图2中所示，分配单元220可以将来自客户端的网络请求分为类型1、类型2和类型3这三类，并将属于类型1的网络请求分配到第一模块接口2402中，将属于类型2的网络请求分配到第二模块接口2404中，将属于类型3的网络请求分配到第三模块接口2406中。当然，在实际操作中，分配单元220在进行请求分类时可能不止分为3类，本发明对其分类标准及类型数量不作限制，图3中只是示例性的进行说明。

分配单元220在确定请求处理接口240和请求处理单元260时主要根据配置信息确认，以Nginx服务器为例，其配置文件中某个URL路径的使用配置如下，分配单元220根据该配置信息即可获取对应的请求处理接口240为第一模块接口2402，即Handler模块接口，请求处理单元260用于实现具体业务逻辑，其可以是动态库，确定的请求处理单元260例如为以下配置信息中所显示的动态库名称"$so_name"。

请求处理接口240接收分配单元220所分配的网络请求后，根据该网络请求的类型调用对应的请求处理单元260进行处理。如图2中所示，第一模块接口2402接收到分配单元220所分配的类型1的网络请求，调用请求处理单元2602进行处理；第二模块接口2402接收到分配单元220所分配的类型2的网络请求后，调用请求处理单元2604进行处理；第三模块接口2406接收到分配单元220所分配的类型3的网络请求后，调用请求处理单元2606进行处理。

实际上，每一个网络请求都与一个请求处理单元260相对应，针对不同的网络请求，分配单元220确定其请求类型后，即可确定与该请求类型相对应的请求处理接口240和请求处理单元260。应当理解，不同的网络请求可能都属于类型1，分配单元220将这类的网络请求都分配到第一模块接口2402中，但第一模块接口2402调用的请求处理单元2602并不是同一个，图2中只是作为一个示例性的统称进行说明。

结果返回单元280适于生成所述网络请求的处理结果并返回到客户端。

进一步地，请求处理接口240包括第一模块接口2402、第二模块接口2404和第三模块接口2406，并适于根据第二配置信息确定网络请求所对应的请求处理单元260。

进一步地，分配单元220确定的网络请求的类型如图3A-3D所示，其通常包括：

(1)类型1：无需访问后端服务器的网络请求

如图3A中第一种场景所示，网络服务器110接收来自客户端的访问请求，获取其中的请求参数，进行一些简单的处理后，记录访问信息并返回结果。

对于这类网络请求，分配单元220可以将其分配到第一模块接口2402进行处理。第一模块接口2402每接收到一个用户请求时，首先获取处理该请求的请求处理单元260的名称，即根据对应路径中配置的动态库名称plugin_name选择某个动态库处理用户请求，如图2中所确定的请求处理单元260具体为请求处理单元2602。通常，网络请求中会携带有第一请求结构体ngx_http_request_t，第一模块接口2402将该第一请求结构体转换成请求类CRequest，并将该请求类CRequest发送给该网络请求所对应的请求处理单元2602进行处理。随后，再将请求处理单元2602处理后的结果转化为第二请求结构体ngx_http_request_t，并根据所述第二请求结构体生成处理结果并返回到结果返回单元280。

以Nginx服务器为例，第一模块接口2402可以是Handler模块接口，其配置文件nginx.conf中某个URL路径的使用配置，即第二配置信息如下:

(2)类型2：只需访问一个后端服务器的网络请求：

如图3B中第二种场景所示，网络服务器110接收来自客户端的访问请求，获取其中的请求参数，经过预处理后，访问后端服务器112。之后，接收后端服务器112的返回内容，记录访问信息并返回最终结果。

对于这类网络请求，分配单元220可以将其分配到图2中的第二模块接口2404进行处理。之后，第二模块接口2404进一步调用后端服务器112进行处理。具体地，在请求处理过程中，第二模块接口2404调用该网络请求所对应的请求处理单元260，如图2中其具体为请求处理单元2604，由已确定的请求处理单元2604生成请求缓冲发送到后端服务器112进行处理，并接收后端服务器112处理所述请求缓冲后所返回的响应正文。之后，根据接收到的响应正文生成处理结果并返回到结果返回单元280。

以Nginx服务器为例，该第二模块接口2404可以是Upstream模块接口。Upstream模块是纯异步的后端服务，具备负载均衡、一致性hash、灾备等功能，其业务层需实现七步接口：

1)create_request生成发送到后端服务器的请求缓冲(缓冲链)，在初始化upstream时使用。

2)reinit_request在某台后端服务器出错的情况，nginx会尝试另一台后端服务器。

3)process_header处理后端服务器返回的信息头部。

4)abort_request在客户端放弃请求时被调用。

5)finalize_request正常完成与后端服务器的请求后调用该函数，与abort_request相同，一般也不会进行任何具体工作。

6)input_filter处理后端服务器返回的响应正文，nginx默认的input_filter会将收到的内容封装成为缓冲区链ngx_chain。

7)input_filter_init初始化input filter的上下文，nginx默认input_filter_init直接返回。

Nginx服务器中，其配置文件nginx.conf中某个URL路径的使用配置，即第二配置信息如下:

(3)类型3：需要访问多个后端服务器的网络请求，包括两种：

a.如图3C中第三种场景所示，在第二种场景的基础上，网络服务器110根据后端服务器114的返回内容，再次访问其他后端服务器116。经过连续多次访问后端服务器后，最终将结果返回给客户端。如负载均衡处理过程，通常一台机器处理速度有限，可以把请求用选择算法分发给不同的机器进行处理。

b.如图3D中第四种场景所示，网络服务器110将请求分为多个子请求，如请求1、请求2和请求3并同时访问多个后端服务器，如图3D中的后端服务器117、118和119，这种情况还有可能根据后端服务器的返回结果进一步访问其他的后端服务器。

对于这类网络请求，分配单元220可以将其分配到图2中的第三模块接口2606进行处理。具体地，在请求处理过程中，第三模块接口2406将该网络请求解析为多个子请求，并分别调用每个子请求所对应的请求处理单元260。随后，各请求处理单元分别生成对应的请求缓冲发送到后端服务器进行处理，并分别接收后端服务器(如114、116、118等)所返回的响应正文。最后，根据接收到的所有响应正文生成处理结果并返回给结果返回单元280。虽然图2中仅示出了一个请求处理单元2606，但应当理解，它只是第三模块接口2606所调用的所有请求处理单元的统称，其还可以包括多个子请求处理单元，其中每个子请求处理单元都可以访问后端服务器。

例如，针对类型3中的情况a，请求处理单元2606先访问后端服务器114，根据该返回内容再访问后端服务器116。当然，还可以根据实际需要继续访问其他服务器。针对类型3中的情况b，请求处理单元2606应该包括多个子请求处理单元，如子请求处理单元1访问后端服务器117、子请求处理单元2访问后端服务器118、子请求处理单元3访问后端服务器118，并最终将这三个子请求的返回结果进行汇总，并判断是否需要进一步访问其他的后端服务器。

以Nginx服务器为例，第三模块接口2406可以是Subrequest模块接口。Subrequest模块同样也会选择某个请求处理单元(动态库)，并且会访问Nginx的其他URI路径，即一个请求可能经过请求处理单元(动态库)的多次处理才最终返回给用户。为了标识请求的不同阶段，将请求划分为8个状态，并用状态机来表示状态之间的转换。

Init：初始状态，创建请求上下文；

Post Body：post请求，正在接收包体；

Process：get请求或post请求包体接收完毕，调用相应业务模块(动态库)处理；

Wait Subrequest：有子请求正在处理，检查子请求是否完成；

Post Subrequest：所有子请求完成，调用相应业务模块(动态库)处理；

Final：业务模块处理完毕，构造发送HTTP响应头，响应体；

Done：发送剩余的HTTP响应头，响应体；

Error：错误，清理上下文，释放资源。

Subrequest模块中，每个状态对应一个处理函数，根据函数的返回值改变请求状态。当返回NGX_DONE时，Nginx将控制权交还给epoll时间框架，等待下一次IO时间再调度ngx_http_adfront_handler。当返回NGX_OK时，表示模块处理结束，Nginx将执行正常的清理操作，释放请求。当返回NGX_ERROR时，Nginx将执行异常清理操作，强制关闭连接，释放请求。

图4示出了根据本发明的另一个实施例的网络服务器400的结构示意图。如图4所示，该网络服务器400包括分配单元420、请求处理接口440、请求处理单元460、结果返回单元480和插件管理器490。其中，分配单元420、请求处理接口440、请求处理单元460和结果返回单元480分别为与图2中的分配单元220、请求处理接口240、请求处理单元260和结果返回单元280相对应，这里不再赘述。

插件管理器490(PluginManager)可以根据第一配置信息加载请求处理单元。具体地，插件管理器490在网络服务器400启动时，解析第一配置信息中的路径指令，得到其中所含的请求处理单元460的名称、路径和配置信息；获取该请求处理单元460的符号表；创建全局实例和类的实例，并执行初始化操作，从而完成请求处理单元460的加载过程。其中，获取该请求处理单元460的符号表可以采用dlopen和dlsym等常规方法。

进一步地，在插件管理器490创建的类中至少包括CPluginInfo、CPluginManager、CPlugin、CPluginInfo、CHeadersIn、CHeadersOut和CSubrequest中的一个或多个。其中，CPluginInfo定义了一个插件的信息，如插件名称、路径、配置文件路径、对象指针等。CPluginManager定义了插件管理器490的方法及属性，用来具体管理各个插件(动态库)的加载、运行与资源释放。CPlugin定义了一个具体插件的基类，各个插件需要实现CPlugin的接口，通过基类对象进行管理。CHeadersIn定义了http接收消息头；CHeadersOut定义了http发送消息头；CSubrequest定义了subrequest的一个子请求。

以Nginx服务器为例，其配置文件nginx.conf中插件管理器490的第一配置信息如下：

进一步地，本发明除了将与Nginx交互的通用处理过程分离出来作为三个插件，并提供对外的接口基类之外，同时还定义了HTTP处理的相关字段和回调函数。

回调函数的例子如：

相关字段的例子如：

根据本发明的技术方案，预先创建并加载了针对不同网络请求的请求处理单元260，并提供了处理不同请求的请求处理接口240，来自客户端的网络请求，只需要确定其请求类型，即可分配到对应的请求处理接口240和请求处理单元260。之后，请求处理单元260根据需要进一步调用后端服务器进行处理，从而实现了业务逻辑和接口的分离。而且，根据归纳好的访问模式，业务逻辑的开发只基于这些请求处理接口240，因此开发人员不需要了解Nginx的具体实现细节，只需要实现相应的回调函数即可，避免处理复杂的HTTP协议，网络IO事件等速度过慢的问题。另外，本发明还降低了系统的耦合度，框架和动态库的开发、维护由不同人进行，从而提高了开发效率。总之，这种通过动态可配置的方案简化了传统模块化开发的过程，较其他方案有性能的提升。

将传统的Nginx服务框架和本发明的Nginx服务框架在相同的条件下做了多组性能测试，如表1所示。从表1中可知，本发明的技术方案在每秒服务的吞吐量和最大响应时间等指标上都是远远优于传统的技术方案。在生产环境中，通过将这套框架用于引擎的adfront模块，使得广告引擎的整体响应时间实现了大幅下降，尤其在每天的流量高峰时期效果更为显著。

表1.Nginx服务框架的性能测试对比

图5示出了根据本发明一个实施例的网络请求处理方法500的流程图，该方法适于在网络服务器中执行，所述网络服务器中预先创建并加载了一个或多个请求处理单元，其中每个请求处理单元都与一个网络请求相对应。

如图5所示，该方法始于步骤S510，在步骤S510中，接收来自客户端的网络请求。

随后，在步骤S520中，确定该网络请求的类型，包括：无需访问后端服务器的网络请求、只需访问一个后端服务器的网络请求，以及需要访问多个后端服务器的网络请求。

随后，在步骤S530中，根据该网络请求的类型确定对应的请求处理接口和请求处理单元。具体地，在确定了请求处理接口之后，由请求处理接口根据第二配置信息确定该网络请求所对应的请求处理单元。其中，所述请求处理接口包括第一模块接口、第二模块接口和第三模块接口。其中，如果网络请求的类型为无需访问后端服务器的网络请求，则确定对应的请求处理接口为第一模块接口。如果网络请求的类型为只需访问一个后端服务器的网络请求，则确定对应的请求处理接口为第二模块接口。如果网络请求的类型为需要访问多个后端服务器的网络请求，则确定对应的请求处理接口为第三模块接口。

随后，在步骤S540中，由所确定的请求处理接口调用所确定的请求处理单元进行处理，并在步骤S550中，生成网络请求的处理结果并返回给客户端。

具体地，当根据网络请求的类型所确定的请求处理接口为第一模块接口时，则先获取所述网络请求中的第一请求结构体ngx_http_request_t，并将其转换成请求类CRequest；以及将所述CRequest发送给该网络请求所对应的请求处理单元进行处理。之后，将请求处理单元处理后的结果转化为第二请求结构体ngx_http_request_t，并根据该第二请求结构体生成所述网络请求的处理结果返回给客户端。

当根据网络请求的类型所确定的请求处理接口为第二模块接口时，则由已确定的请求处理单元生成请求缓冲发送到后端服务器进行处理，并接收后端服务器处理所述请求缓冲后所返回的响应正文。最后，根据该响应正文生成所述网络请求的处理结果返回给客户端。

当根据网络请求的类型所确定的请求处理接口为第三模块接口时，则将该网络请求解析为多个子请求，并分别调用每个子请求所对应的请求处理单元。之后，各子请求所对应的请求处理单元分别生成对应的请求缓冲发送到后端服务器进行处理，并分别接收对应的后端服务器所返回的响应正文，并根据接收到的所有响应正文生成所述网络请求的处理结果返回给客户端。

根据一个实施例，网络服务器可以是Nginx服务器，第一模块接口可以是Handler模块接口，第二模块接口可以是Upstream模块接口，第三模块接口可以是Subrequest模块接口。

根据另一个实施例，网络服务器还可以包括插件管理器，方法500还可以包括步骤：插件管理器根据第一配置信息加载请求处理单元。其具体步骤为：解析第一配置信息中的路径指令，得到请求处理单元的名称、路径和配置信息；获取该请求处理单元的符号表；以及创建全局实例和类的实例，并执行初始化操作。其中，可以利用dlopen和dlsym等常规的现有方法获取该请求处理单元的符号表。

根据本发明的网络请求处理方法，其具体细节已在基于图1-4的描述中详细公开，在此不再进行赘述。

根据本发明的技术方案，提出了一种适用于各业务场景的Nginx服务框架，将各个业务线的业务逻辑封装成动态库，并使用包管理器进行统一管理，包管理器通过配置文件使插件管理器动态加载各个动态库，只需要在开发动态库时实现定义的接口就可以实现管理。业务逻辑的开发与Nginx框架开发分离，降低了系统耦合度。另外，三种Nginx模块适用于Web开发中可能面对的各种场景，具有广泛的适用性；对每个模块都提供了良好的接口，具有良好的可扩展性，实现了高度可配置化。

B10、如B9所述的网络服务器，所述插件管理器适于解析第一配置信息中的路径指令，得到请求处理单元的名称、路径和配置信息；获取该请求处理单元的符号表；创建全局实例和类的实例，并执行初始化操作，从而加载请求处理单元。

B11、如B8-B10中任一个所述的网络服务器，所述分配单元适于：在网络请求的类型为无需访问后端服务器的网络请求时，确定对应的请求处理接口为第一模块接口；在网络请求的类型为只需访问一个后端服务器的网络请求时，确定对应的请求处理接口为第二模块接口；以及在网络请求的类型为需要访问多个后端服务器的网络请求时，确定对应的请求处理接口为第三模块接口。

B12、如B11所述的网络服务器，所述第一模块接口适于：将所述网络请求中的第一请求结构体转换成请求类；将所述请求类发送给该网络请求所对应的请求处理单元进行处理；将所述请求处理单元处理后的结果转化为第二请求结构体；以及根据所述第二请求结构体生成处理结果并返回给结果返回单元。

B13、如B11所述的网络服务器，所述第二模块接口适于：由已确定的请求处理单元生成请求缓冲发送到后端服务器进行处理；接收后端服务器处理所述请求缓冲后所返回的响应正文；以及根据所述响应正文生成处理结果并返回给结果返回单元。

B14、如B11所述的网络服务器，所述第三模块接口适于：将所述网络请求解析为多个子请求；分别调用每个子请求所对应的请求处理单元；各请求处理单元分别生成对应的请求缓冲发送到后端服务器进行处理，并分别接收后端服务器所返回的响应正文；以及根据接收到的所有响应正文生成处理结果并返回给结果返回单元。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。

尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的而非限制性的，本发明的范围由所附权利要求书限定。