CN109088764A - 访问请求处理方法及相关设备 - Google Patents

Abstract

本实施例提供了一种访问请求处理方法及相关设备，接收到客户端发送的访问请求，提取该访问请求携带的当前域名及访问路径，将其与数据库预存的域名‑后台路径数据进行比对，以使后端服务器根据比对结果，获取相应的页面数据发送至前端代理服务器，进而反馈至客户端进行页面展示。相对与传统触发每个配置文件进行查询，本实施例这种直接查询数据库的方式，提高了访问请求响应效率，且本实施例的前端代理服务器无需针对代理的每个域名，生成相应的配置文件，极大减少了配置文件的数量，当需要修改后台路径或增加域名时，只需要在数据库中写入相应数据，前端代理服务器需要人工编写配置文件，减少了人工干预，降低了维护成本。

Description

访问请求处理方法及相关设备

技术领域

本发明主要涉及反向代理应用技术领域，更具体地说是涉及一种访问请求处理方法及相关设备。

背景技术

反向代理是一种接收Internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求连接的客户端的一种方式。Nginx作为目前各大网站最常用的一种反向代理服务器，不仅能够用来将客户端发起的访问请求转发到真实的服务器，还能够用来作为负载均衡器，平衡集群中各个网页服务器的负载压力。

在实际应用中，大部分的网站开发中都会有前台页面和后台页面，且前台页面的地址和后台页面的地址通常处于同一域名下，路径也相对固定。若用户希望使用自定义的域名或后台访问路径，来访问后台页面的后台程序，通常是在Nginx代理配置中，针对代理的每一个域名，生成一个该域名对应的指定后台访问路径的配置文件。

可见，在传统Nginx反向代理服务器对访问请求处理应用中，存在多少个需要代理的域名，就需要生成多少个配置文件，且当用户希望通过别的域名访问后台程序，Nginx代理配置中将增加一新域名，此时需要生成相应的配置文件，这样就会造成配置文件越来越多，大大增加了大量配置文件的管理维护工作量，且降低了查询当前域名对应配置文件的效率，进而降低了访问请求响应效率。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种访问请求处理方法及相关设备。

为了实现上述目的，本实施例公开了以下技术方案：

本发明实施例提供了一种访问请求处理方法，应用于前端代理服务器，所述方法包括：

接收客户端发送的访问请求，并提取所述访问请求携带的当前域名及访问路径；

利用所述当前域名及所述当前访问路径，查询预存的访问域名-后台路径数据；

获取与得到的查询结果相匹配的页面数据，并将所述页面数据反馈至所述客户端。

可选的，所述利用所述当前域名及所述访问路径，查询预存的访问域名-后台路径数据，包括：

从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径；

将所述后台路径与提取的所述访问路径进行比对；

当所述后台路径与所述访问路径相同，确定所述访问请求是后台访问请求；

当获取的所述后台路径与所述访问路径不同，确定所述访问请求是前台访问请求。

可选的，所述利用所述当前域名及所述当前访问路径，查询预存的访问域名-后台路径数据，还包括：

从预存的域名-后台路径数据未查询到所述访问域名，检测所述访问路径是否包含指定后台地址；

如果是，确定所述访问请求是后台访问请求；

如果否，确定所述访问请求是前台访问请求。

可选的，所述从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径，包括：

将预存的各域名与所述当前域名进行一一比对；

当预存的一域名与所述当前域名相同，获取预存的该域名对应的后台路径。

可选的，所述页面数据是前台页面数据或后台页面数据，所述获取与所述查询结果相匹配的页面数据，包括：

将所述查询结果发送至后端服务器，以使网页服务器获取与所述查询结果相匹配的页面数据；

接收所述网页服务器反馈的所述页面数据。

可选的，所述方法还包括：

获取针对用户自定义后台页面数据设置的新域名和/或后台路径；

利用所述新域名和/或后台路径，更新预存的域名-后台路径数据。

本发明实施例还提供了一种访问请求处理装置，应用于前端代理服务器，所述装置包括：

访问请求接收模块，用于接收客户端发送的访问请求，并读取所述访问请求携带的访问域名及访问路径；

查询模块，用于利用所述当前域名及所述当前访问路径，查询预存的访问域名-后台路径数据；

页面数据获取模块，用于获取与得到的查询结果相匹配的页面数据，并将所述页面数据反馈至所述客户端。

可选的，所述查询模块包括：

获取单元，用于从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径；

比对单元，用于将所述后台路径与提取的所述访问路径进行比对；

第一确定单元，用于当所述后台路径与所述访问路径相同，确定所述访问请求是后台访问请求；

第二确定单元，用于当获取的所述后台路径与所述访问路径不同，确定所述访问请求是前台访问请求。

本发明实施例还提供了一种前端代理服务器，包括：

通信接口；

存储器，用于存储实现如上所述的访问请求处理方法的程序；

处理器，用于加载并执行所述存储器存储的程序，所述程序用于实现上所述的访问请求处理方法的各步骤。

本发明实施例还提供了一种访问请求处理系统，所述系统包括：

如上所述的前端代理服务器；

数据库，用于存储域名-后台路径数据；

后端服务器，用于根据前端代理服务器发送的对所述数据库的查询结果，获取相应的页面数据，并将所述页面数据通过所述前端代理服务器发送至客户端。

由此可见，与现有技术相比，本实施例提供了一种访问请求处理方法及相关设备，接收到客户端发送的访问请求，提取该访问请求携带的当前域名及访问路径，将其与数据库预存的域名-后台路径数据进行比对，以使后端服务器根据比对结果，获取相应的页面数据发送至前端代理服务器，由前端代理服务器将该页面数据反馈至客户端，以使客户端展示相应的页面。相对传统触发每个配置文件进行查询，本实施例这种直接查询数据库的方式，提高了访问请求响应效率，且本实施例的前端代理服务器无需针对代理的每个域名，生成相应的配置文件，极大减少了配置文件的数量，当需要修改后台路径或增加域名时，只需要在数据库中写入相应数据，前端代理服务器需要人工编写配置文件，减少了人工干预，降低了维护成本。

附图说明

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

图1为本发明实施例提供的一种访问请求处理系统的结构示意图；

图2为本发明实施例提供的一种访问请求处理方法的流程示意图；

图3为本发明实施例提供的一种访问请求处理方法的应用场景示意图；

图4为本发明实施例提供的另一种访问请求处理方法的流程示意图；

图5为本发明实施例提供的一种访问请求处理装置的结构示意图；

图6为本发明实施例提供的另一种访问请求处理装置的结构示意图；

图7为本发明实施例提供的又一种访问请求处理装置的结构示意图；

图8为本发明实施例提供的一种前端代理服务器的硬件结构示意图。

具体实施方式

针对背景技术描述的现有技术问题，本发明的发明人发现传统网站开发框架通常默认，后台页面的后台地址和前台页面的前台地址处于同一域名下，且路径也相对固定，如用户的前台展示页面的前台地址为：http://www.abc.com/，其对应的后台地址通常是http://www.abc.com/admin/，即在前台地址后增加“/admin”，这很容易被非法用户利用，威胁网站的安全性。

且在前端代理服务器配置后，每代理一个域名就需要一个配置文件，或一个server来监听通过该域名发起的访问请求，所生成的配置文件可以参照下文所示的程序代码：

#前端代理服务器配置文件

基于上述配置文件的内容可知，当用户想要使用自己指定的域名或指定的后台路径，来访问后台页面数据，通常需要新增配置文件或修改相应的配置文件，这样，随着访问该网站的后台页面数据的增加，将会导致该前端代理服务器生成的配置文件越来越多，使其管理维度困难，成本高，且会降低访问请求响应效率。

为了改善上述问题，本发明的发明人提出前后台页面的程序进行分离，保证访问的独立性、稳定性、可靠性及安全性，并对使用不同域名的多种后台访问方式(包括已存在的后台路径及用户自定义的后台路径)进行预先存储，即在数据库中预先存储域名-后台路径数据，并在前端代理服务器的配置文件中嵌入lua脚本文件，使得本发明实施例利用这一个配置文件，对预存的域名-后台路径数据进行查询，确定当前访问的页面数据是后台页面数据还是前台页面数据，从而使得后端服务器获取相应的页面数据反馈至发起访问请求的用户客户端。

可见，本发明实施例提出的这种方案在增加新的域名时，只需要在数据库中存储该域名与其对应的后台路径，不需要为其专门生成相应的配置文件，极大减少配置文件数量，简化了配置文件的管理，降低了成本，且提高了访问请求响应效率。

下面将结合本实施例中的附图，对本实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

基于上文描述的访问请求处理的核心思路，图1示出了实现该访问请求处理方法的系统架构示意图，如图1所示，该系统可以包括前端代理服务器11、数据库12及后端服务器13，其中：

前端代理服务器11可以是任一网站的前端代理服务器，具体可以是Nginx反向代理服务器，用来将用户使用客户端发起的访问请求转发到真实的服务器，如后端服务器。

其中，本实施例的前端代理服务器Nginx与传统的Nginx不同的是，本实施例在前端代理服务器Nginx默认的配置文件中嵌入lua脚本文件，Nginx执行lua脚本文件，能够高并发、非阻塞的处理各种请求。

由于Lua脚本文件内建协程，能够很好的将异步回调转换成顺序调用的形式，且ngx_lua在Lua脚本文件中进行的IO操作，通常都会委托给Nginx的事件模型(如epoll、kqueue等)，从而实现非阻塞调用。

开发者可以采用串行的方式编写程序，ngx_lua会自动的在进行阻塞的IO操作时中断，保存上下文；然后将IO操作委托给Nginx事件处理机制，在IO操作完成后，ngx_lua会恢复上下文，程序继续执行，且这些操作都是对用户程序透明的。

基于上述对Lua脚本文件的分析，本实施例前端代理服务器Nginx的每个Worker进程可以在如epoll、kqueue等事件模型之上，封装成协程，每个访问请求可以有一个协程进行处理，与Lua脚本文件内建协程的模型一致，这样，即使ngx_lua执行Lua脚本文件，相对系统有一定开销，前端代理服务器依然能够保持高并发能力，提高了访问请求处理效率。

数据库12可以用来存储域名-后台路径数据，也就是说，开发者可以将为用户提供的多种后台访问方式对应的后台路径，以及用户可以使用的多个域名，甚至是用户自定义的访问自己网站后台页面数据的后台路径等数据，预选存储至数据库中，这些后台路径和域名之间往往存在一定的对应关系，即域名-后台路径对应关系，本实施例对该对应关系的表现方式不作限定，如对应关系表等。

这样，前端代理服务器接收到用户发起的访问请求后，可以对该数据库进行查询，以判定该数据库中是否存储有该访问请求携带的当前域名及当前地址，从而根据查询结果，确定该访问请求是要访问后台页面数据还是前台页面数据。

可选的，本实施例的数据库12可以是键值数据，如redis数据库，本实施例对该数据库12的存储结构不作限定，以键值数据库为例，其存储的域名-后台路径数据库中，域名可以是键key，相应的后台路径可以是值valua，关于对数据库的查询方法，可以参照下文方法实施例相应部分的描述。

其中，redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，本实施例对redis数据库组成结构不做详述。

后端服务器13可以包括一个或多个服务器，用来响应访问请求，获取前台页面数据或后台页面数据，并反馈至用户的客户端，以使客户端展示前台页面或后台页面等，本实施例对网站的后端服务器13的具体组成结果不作限定。

基于上述系统组成结构的分析，前端代理服务器接收到客户端发起的访问请求后，前端代理服务器可以将其接入默认配置文件，执行其嵌入的Lua脚本，从而由Lua脚本截取访问请求中的片段，得到当前域名及访问路径，据此查询数据库中存储的各域名及对应的后台路径，确定该访问请求是要访问前台页面数据还是后台页面数据，进而使后端服务器依据该查询结果，获取相应的页面数据，通过前端代理服务器反馈至发起访问请求的客户端，以使客户端展示相应的页面。

可见，本发明的前端代理服务器只需其默认的配置文件，不需要针对代理的每个域名生成对应的配置文件，极大减少了配置文件的数量，简化了配置文件的管理维护，提高了访问请求响应效率，且当需要新增域名或修改某后台路径，只需要对数据库进行增加或修改操作即可，操作简单方便。

结合上图1所示的系统架构图，参照图2，本发明实施例提供了一种访问请求处理方法的流程示意图，该方法可以应用于任一网站的前端代理服务器，本实施例提供的方法可以包括但并不局限于以下步骤：

步骤S11，接收客户端发送的访问请求，并提取该访问请求携带的当前域名及访问路径；

结合上述系统实施例部分对前端代理服务器的描述，该前端代理服务器采用多进程模型，即单Master—多Worker，由Master处理外部信号、配置文件的读取及Worker的初始化，Worker进程采用单线程、非阻塞的事件模型(Event Loop，事件循环)来实现端口的监听及客户端请求的处理和响应，同时Worker还要处理来自Master的信号。

因此，本实施例的Nginx前端代理服务器接收到访问请求后，可以创建一Worker进程来处理该访问请求，且为了避免降低Worker的响应能力，需要保证其主循环是非阻塞的，具体实现方式不作限定。

而对于客户端发起的访问请求，为了确定其是由谁访问哪个服务器的什么文件，该访问请求中通常包含有域名和URL(Uniform Resource Locator，统一资源定位符)，该域名相当于一个家庭的门牌号码，即上网单位的名称；URL是互联网上标准资源的地址，互联网上每个文件都有一个唯一的URL。

基于此，Nginx前端代理服务器接收到客户端发送的访问请求后，可以根据该访问请求的请求头的host、ip和port等内容，来确定该访问请求应该由哪个服务器(本实施例可以指后端服务器)处理，之后，可以根据访问请求中的URI(UniformResourceIdentifier，统一资源标识符)找到对应的被访问的文件的位置。在实际应用中，前端代理服务器对访问请求的处理可以分为若干个不同阶段，按照顺序依次执行，通常NGX_HTTP_POST_READ_PHASE在第一个，NGX_HTTP_LOG_PHASE在最后一个，本实施例对访问请求的处理过程不作详述。

另外，前端代理服务器Nginx的每个Worker进程可以将接收到的访问请求封装成一个协程进行处理，相对于传统多线程并发处理方式，本实施例将利用嵌入的Lua脚本，实现高并发、非阻塞的处理。

具体的，本实施例可以利用ngx_lua将Lua嵌入Nginx前端代理服务器的配置文件，使其每个Worker进程可以持有一个Lua解释器或LuaJIT实例，被该Worker进程处理的访问请求共享这个LuaJIT实例。且对于接入的每个访问请求，可以被Lua脚本文件轻量级的协程分割，以保证各个访问请求是独立的，所以说，对于接入的每个访问请求，可以由Lua脚本截取该访问请求携带的当前域名及访问路径，具体实现过程本实施例不作限定。

需要说明，本实施例涉及到的Lua是一个小巧脚本语言，LuaJIT即采用C语言写的Lua代码的解释器，本实施例对LuaJIT的具体应用不做详述。可选的，关于在前端代理服务器中嵌入Lua脚本的实现，可以通过在前端代理服务器中配置模块嵌套扩展模块，即lua-nginx-module，利用该扩展模块支持该前端代理服务器Nginx通过LuaJIT解释Lua代码，本实施例对该过程的具体实现不做详述。

步骤S12，利用该当前域名及访问路径，查询预存的访问域名-后台路径数据；

结合上述系统实施例对数据库部分的描述，可以由redis数据库，预先存储多个访问域名及其对应的后台路径，即针对某后台页面数据的多种后台访问方式，本实施例将预存的访问域名及其对应的后台路径记为访问域名-后台路径数据。

其中，用户配置独立的后台域名或后台路径时，可以采用key-value(键值，简称kv)形式存在至redis数据库，并由key表示后台域名，value表示后台路径。在得到当前访问请求包含的当前域名及访问路径后，可以通过查询redis数据存储的key和value，来判断当前访问请求是要访问后台页面数据，还是前台页面数据。

本发明实施例提供了前端代理服务器中的Lua脚本查询redi s数据库的一示例，包含了如何连接red is数据及对redi s数据的查询过程，但并不局限于该示例，可以根据实际情况进行适应性调整，本发明仅以该示例对说明步骤S12的一种实现方法。

首先，Lua代码domain.lua，可以先对访问请求的域名进行分流，可以采用下文描述的程序代码实现，但并不局限于此：

localredis＝require"resty.redis"

localcache＝redis.new()

localok,err＝cache.connect(cache,"127.0.0.1","6379")

cache:set_timeout(60000)

可见，对域名进行分流可以包括定义链接redis数据库所需要的Lua扩展库，初始化，连接redis数据库所需要的地址(如127.0.0.1)及端口(如6379)，设置的连接redis数据库的超时时间(如60秒)，根据实际需要，本实施例可以调整上述连接地址、端口及超时时间等参数。

可选的，在查询预存的访问域名-后台路径数据过程中，可以采用先遍历存储的所有域名，再比对当前域名对应的访问路径及后台路径是否一致，以确定当前访问请求是否是要访问后台页面数据。需要说明，查询访问域名-后台路径数据的具体实现方式并不局限于这一种实现方式，也可以采用直接比对路径和域名等等，本实施例在此不再一一详述。

步骤S13，获取与得到的查询结果相匹配的页面数据，并将所述页面数据反馈至客户端。

本实施例中，通过上述步骤S12的查询，得到的查询结果可以包括在redis数据库中未查询到当前域名、查询到当前域名但其对应的后台路径与访问路径不一致、查询到当前域名且其对应的后台路径与访问路径一致等三种查询结果，当得到的查询结果是第三种时，表明当前访问请求是要访问后台页面数据，前两种查询结果均表明当前访问请求是要访问前台页面数据。

基于此，Lua脚本可以将得到的查询结果告知后端服务器，以使后端服务器获取相应的前台页面数据或后台页面数据，并反馈至前端代理服务器，以使前端代理服务器将接收到的页面数据发送至发起访问请求的客户端。

其中，前台页面数据和后台页面数据可以是实现相应页面展示的程序代码，本实施例将实现前后台页面的程序分离开，可以通过不同端口即不同路径获取，具体可以参照下文给出的前台程序及后台程序的一示例配置文件：

#后端服务器前台程序配置文件

对比上文给出的传统访问请求处理方法中的前后台程序配置文件示例，很明显，其与本实施例给出的前后台程序配置文件的内容存在区别，如实现后端服务器监听端口的程序代码不同，传统方案中是要监听固定域名www.abc.com，即每个域名对应一个配置文件，而本实施例的配置文件不需要监听固定域名，因此，其监听端口的程序代码仅包含对端口地址的监听，并不存在任一域名地址，也就是说，本实施例提出的该配置文件能够监听通过该端口接收到的各域名服务器发送的访问请求。

综上所述，参照图3所示的应用场景示意图，本发明实施例的前端代理服务器不再针对代理的每个域名，生成一个对应的配置文件，而是预先在数据库中存储多个用户访问后台页面数据的域名，及其对应的后台路径，其包含了网站已存在的后台路径和域名，也可以包含用户自定义的域名或指定的后台路径等，当前端代理服务器接收到客户端发送的访问请求后，不需要一个配置文件一个配置文件查询，直接由默认配置文件嵌入的Lua脚本，对数据库预存的域名-后台路径进行查询，即可确定该访问请求是要访问后台页面数据还是前台页面数据，直接通知后端服务器获取相应的页面数据反馈至客户端，极大提高了访问请求响应效率，且当需要增加新的域名时，本实施例不需要再生成一个配置文件，只需要在数据库中增加该新的域名及对应的后台路径即可，简单方便，降低了配置文件维护成本。

基于上述实施例对本发明提出的访问请求处理方法的核心思想，本发明提出另一可选实施例，主要说明如何实现对数据库的查询，参照图4所示的该可选实施例的访问请求处理方法的流程示意图，该方法可以包括但并不局限于以下步骤：

步骤S21，接收客户端发送的访问请求，并提取该访问请求携带的当前域名及访问路径；

结合上文对前端代理服务器的描述，本实施例在该前端代理服务器Nginx配置文件中嵌入了Lua脚本，为了使Lua脚本能够实现对redis数据库的查询，可以在该配置文件中设置以下程序代码：

#引用lua连接redis的库

需要说明，上述程度代码表达的步骤，可以在前端代理服务器接收到客户端发送的访问请求，但未传递至其嵌入的扩展模块的lua代码之前实现，在执行完成上述程序代码后，可以执行嵌入的lua代码，以提取该访问请求携带的当前域名及访问路径。

其中，本实施例引用lua代码执行，是为了确定用户是否自定义了管理后台，如果是，将访问管理后台地址，获取后台页面数据，否则，将获取前台页面数据，以使客户端前往前台页面。Lua脚本执行完毕，得到上述结果(即查询结果)后，前端代理服务器将基于该结果，将访问请求发送至后端服务器，以使后端服务器响应该访问请求，获取相应的页面数据反馈至用户客户端，具体实现过程可以参照下文相应部分的描述。

步骤S22，查询数据库存储的域名-后台路径数据是否包含当前域名，如果是，进入步骤S24；如果否，进入步骤S23；

可选的，由于数据库存储有多个域名及对应的多个后台路径，在前端代理服务器从当前接收到的访问请求中，提取处当前域名及访问路径后，可以先利用该当前域名，查询数据库存储的所有域名，以判断该数据库中是否已存储有当前域名。

下文给出了实现步骤S22的程序代码的一示例，但并不局限于本实施例给出的程序代码，在本实施例中，redis数据库采用键值存储方式，实现对后台域名和后台路径的存储，且可以将后台域名存储为work_domainde的形式，其中，domain表示域名，将遍历的所有key存储于变量all_keys中，以便将获取的当前域名与all_keys中的内容进行匹配，具体实现过程如下：

--将所有的key遍历出来存储

localall_keys＝cache:keys("*")

--获取用户访问的host

localdomain＝ngx.var.host

--获取用户访问的uri

localuri＝ngx.var.request_uri

--用来判定访问的域名是否有key值存储于redis

localdomain_keys＝0

由该程序代码可知，通过便利redis数据库存储的所有key(即预存的所有域名)，即将获取的当前域名与redis数据库存储的各域名进行一一比对，若预存有与该当前域名相同的域名，将执行步骤S24；反之，执行步骤S23。其中，关于当前域名的获取，可以通过获取访问请求的host、uri的方式确定。

步骤S23，检测该访问路径是否包含指定后台地址，如果是，执行步骤S26；如果否，执行步骤S28；

如上文分析，如用户没有自定义管理后台，访问路径包含“/admin”，可以认为其是要访问后台页面数据，基于此，在确定数据库未存储有当前域名的情况下，还可以进一步判断访问路径是否包含该指定后台地址(即/admin)，来确定用户是要去后台项目还是前台项目，具体实现程序代码如下：

步骤S24，获取该数据库存储的与当前域名对应的后台路径；

继上文给出的配置文件示例，本实施例可以采用如下程度代码所示的方式，获取后台路径，即获取域名对应的值：

可见，本实施例在确定数据库存储有当前域名的情况下，先判断该域名是否存储有对应的后台路径。

步骤S25，判断提取的访问路径与该后台路径是否一致，如果是，进入步骤S26；如果否，执行步骤S28；

步骤S26，向后端服务器发送后台访问指令，由后端服务器获取后台页面数据；

本实施例中，若从数据库存储的数据中查询到访问路径，可以确定当前获取的访问请求是后台访问请求，反之，确定该访问请求可以是前台访问请求，前端代理服务器可以基于步骤S25的判断结果，通知后端代理服务器获取相应的页面数据，并通过该前端代理服务器反馈至客户端，以使客户端进入相应的页面。

步骤S27，接收后端服务器发送的后台页面数据，并将该后台页面数据反馈至客户端；

步骤S28，向后端服务器发送前台访问指令，由后端服务器获取前台页面数据；

步骤S29，接收后端服务器发送的前台页面数据，并将该前台页面数据反馈至客户端。

如上述分析，数据库中存储的各域名及对应的后台路径，是访问后台页面数据的实现方式，因此，本实施例通过将从当前访问请求中提取的当前域名和访问路径，与数据库中存储数据进行比对，根据比对结果是否相同，能够直接判断当前访问请求是否要访问后台页面数据。

可选的，本实施例可以直接基于步骤S24的判断结果，确定本次访问是访问后台地址还是前台地址，具体可以采用如下程度代码实现：

由此可见，若用“1”表示在数据库中找到与访问路径对应的后台路径，即数据库中与当前域名对应的后台路径中包含有访问路径，可以认为本次访问请求是请求访问后台页面数据，反之，请求访问的是前台页面数据。

综上，本实施例的前端代理服务器接收到用户客户端发起的访问请求后，可以利用lua脚本提取该访问请求携带的当前域名及访问路径，并将其与数据库预存的域名-后台路径数据进行比对，若从数据库中查询到该当前域名及访问路径，将获取后台页面数据；否则，可以通过检测访问路径是否包含指定后台地址，来进一步判断当前访问请求是否要获取后台页面数据，相对传统方案由多个配置文件一一查询相应的域名及后台路径相比，极大提高了访问请求响应效率，且当新增访问后台的域名，本实施例只需要在数据库中增加该域名即可，不需要生成相应的配置文件，简单方便。

基于上述各实施例的描述，本实施例不需要针对代理的每个域名，生成相应的配置文件，极大减少了前端代理服务器包含的文件数量，当访问网站的用户增加、访问域名增加或后台路径修改时，基于本发明上述核心构思，本发明只需要将这些新增数据或修改后的数据，写入数据库中，不需要增加或修改配置文件，无需管理大量的配置文件，减少了人工干预，降低了维护成本。

因此，在上述各实施例的基础上，本发明提供的访问请求处理方法还可以包括获取针对用户自定义后台页面数据设置的新域名和/或后台路径，利用该新域名和/或后台路径，更新数据库预存的域名-后台路径数据。

参照图5，本发明本实施例提供的一种访问请求处理装置的结构示意图，该装置可以应用于前端代理服务器，具体可以包括以下功能模块：

访问请求接收模块51，用于接收客户端发送的访问请求，并读取所述访问请求携带的访问域名及访问路径；

查询模块52，用于利用当前域名及当前访问路径，查询预存的访问域名-后台路径数据；

可选的，参照图6，该查询模块52可以包括：

获取单元521，用于从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径；

在本实施例实际应用中，该获取单元521具体可以包括：

比对子单元，用于将预存的各域名与所述当前域名进行一一比对；

获取子单元，用于当预存的一域名与所述当前域名相同，获取预存的该域名对应的后台路径。

比对单元522，用于将所述后台路径与提取的所述访问路径进行比对；

第一确定单元523，用于当所述后台路径与所述访问路径相同，确定所述访问请求是后台访问请求；

第二确定单元524，用于当获取的所述后台路径与所述访问路径不同，确定所述访问请求是前台访问请求；

作为另一可选实施例，如图6所示，该查询模块52还可以包括。

检测单元525，用于从预存的域名-后台路径数据未查询到所述访问域名，检测所述访问路径是否包含指定后台地址；

第三确定单元526，用于当监测单元的检测结果为是，确定所述访问请求是后台访问请求；

第四确定单元527，用于当监测单元的检测结果为否，确定所述访问请求是前台访问请求。

页面数据获取模块53，用于获取与得到的查询结果相匹配的页面数据，并将该页面数据反馈至客户端。

可选的，本实施例涉及到的页面数据可以是前台页面数据或后台页面数据，页面数据获取模块53可以包括：

发送单元，用于将所述查询结果发送至后端服务器，以使网页服务器获取与所述查询结果相匹配的页面数据；

关于发送单元的具体实现方法，可以参照上述方法实施例相应部分的描述，本实施例在此不再赘述。

页面数据接收单元，用于接收所述网页服务器反馈的该页面数据；

页面数据发送单元，用于将该页面数据反馈至客户端。

作为本发明又一实施例，如图7所示，在上述各实施例的基础上，该装置还可以包括：

获取模块54，用于获取针对用户自定义后台页面数据设置的新域名和/或后台路径；

更新模块55，用于利用所述新域名和/或后台路径，更新预存的域名-后台路径数据。

综上所述，本实施例将访问后台页面数据的多个域名及后来路径存储到数据库中，并在前端代理服务器的配置文件中嵌入Lua脚本，在其接入访问请求后，直接根据该访问请求携带的当前域名及访问路径，查询数据库存储的数据，以确定该访问请求是访问后台项目还是前台项目，之后，后端服务器可以根据得到的查询结果，快速且准确获取相应的页面数据，反馈至客户端，前端代理服务器不需要针对代理的每个域名，生成相应的多个配置文件，且用户自定义的后台路径及新增的域名，可以直接录入数据库，前端代理服务器无需再进行人工干预，即可实现自动化管理，减少了维度成本，提高了访问请求响应效率。

可选的，本实施例提供的访问请求处理装置可以包括存储器和处理器，上述访问请求接收模块、查询模块、页面数据获取模块、获取单元、比对单元、检测单元、获取模块及更新模块等均可以作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来提取接入的访问请求的当前域名及访问路径，以及将其与数据库存储的数据的比对，并通知后端服务器来获取相应的页面数据反馈至客户端，简化配置文件数量及管理，降低维护成本，提高访问请求响应效率。

存储器可以包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本发明实施例提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述访问请求处理方法的各个步骤，本实施例在此不再赘述。

参照8，本发明实施例提供了一种前端代理服务器的硬件结构示意图，其可以包括：

通信接口81；

其中，该通信接口可以是无线或有线通信接口，用来接收内部其他部件传输的数据，或用户客户端发送的访问请求等等，本实施例对该通信接口81的类型不作限定。

存储器82，用于存储实现如上所述的访问请求处理方法的程序；

处理器83，用于加载并执行存储器存储的程序，实现如上所述的访问请求处理方法的各个步骤。

其中，关于处理器执行程序，实现上述访问请求处理方法的过程可以参照上述方法实施例的描述，本实施例在此不再赘述。

在本实施例中，该前端代理服务器具体可以是Nginx反向代理服务器，其包含的硬件组成并不局限于上文列举的各部件，具体可以根据实际需要确定，本实施例不再一一列举。

参照图1，本发明实施例还提供了一种访问请求处理系统，该系统可以包括前端代理服务器11、数据库12及后端服务器13；

关于前端代理服务器11的功能可以参照上述方法实施例的描述，本实施例不再赘述。

数据库12，用于存储域名-后台路径数据；

后端服务器13，用于根据前端代理服务器发送的对所述数据库的查询结果，获取相应的页面数据，并将所述页面数据通过所述前端代理服务器发送至客户端。

其中，关于数据库12以及后端服务器13在访问请求处理方法中的具体功能实现，可以参照上述方法实施例相应部分的描述，本实施例在此不再赘述。

本领域内的技术人员应明白，本发明提供的方法、装置、存储介质、前端代理服务器及系统实施例，可以是采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还有，需要说明的是，关于上述各实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、装置、前端代理服务器或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者系统中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、前端代理服务器、系统而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种访问请求处理方法，其特征在于，应用于前端代理服务器，所述方法包括：

接收客户端发送的访问请求，并提取所述访问请求携带的当前域名及访问路径；

利用所述当前域名及所述访问路径，查询预存的访问域名-后台路径数据；

获取与得到的查询结果相匹配的页面数据，并将所述页面数据反馈至所述客户端。

2.根据权利要求1所述的方法，其特征在于，所述利用所述当前域名及所述访问路径，查询预存的访问域名-后台路径数据，包括：

从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径；

将所述后台路径与提取的所述访问路径进行比对；

当所述后台路径与所述访问路径相同，确定所述访问请求是后台访问请求；

当获取的所述后台路径与所述访问路径不同，确定所述访问请求是前台访问请求。

3.根据权利要求2所述的方法，其特征在于，所述利用所述当前域名及所述当前访问路径，查询预存的访问域名-后台路径数据，还包括：

从预存的域名-后台路径数据未查询到所述访问域名，检测所述访问路径是否包含指定后台地址；

如果是，确定所述访问请求是后台访问请求；

如果否，确定所述访问请求是前台访问请求。

4.根据权利要求2或3所述的方法，其特征在于，所述从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径，包括：

将预存的各域名与所述当前域名进行一一比对；

当预存的一域名与所述当前域名相同，获取预存的该域名对应的后台路径。

5.根据权利要求1～3任一项所述的方法，其特征在于，所述页面数据是前台页面数据或后台页面数据，所述获取与所述查询结果相匹配的页面数据，包括：

将所述查询结果发送至后端服务器，以使网页服务器获取与所述查询结果相匹配的页面数据；

接收所述网页服务器反馈的所述页面数据。

6.根据权利要求1～3任一项所述的方法，其特征在于，所述方法还包括：

获取针对用户自定义后台页面数据设置的新域名和/或后台路径；

利用所述新域名和/或后台路径，更新预存的域名-后台路径数据。

7.一种访问请求处理装置，其特征在于，应用于前端代理服务器，所述装置包括：

访问请求接收模块，用于接收客户端发送的访问请求，并读取所述访问请求携带的访问域名及访问路径；

查询模块，用于利用所述当前域名及所述当前访问路径，查询预存的访问域名-后台路径数据；

页面数据获取模块，用于获取与得到的查询结果相匹配的页面数据，并将所述页面数据反馈至所述客户端。

8.根据权利要求7所述的装置，其特征在于，所述查询模块包括：

获取单元，用于从预存的域名-后台路径数据中查询到所述访问域名，获取所述访问域名对应的后台路径；

比对单元，用于将所述后台路径与提取的所述访问路径进行比对；

第一确定单元，用于当所述后台路径与所述访问路径相同，确定所述访问请求是后台访问请求；

第二确定单元，用于当获取的所述后台路径与所述访问路径不同，确定所述访问请求是前台访问请求。

9.一种前端代理服务器，其特征在于，包括：

通信接口；

存储器，用于存储实现如权利要求1～6任一项所述的访问请求处理方法的程序；

处理器，用于加载并执行所述存储器存储的程序，所述程序用于实现如权利要求1～6任一项所述的访问请求处理方法的各步骤。

10.一种访问请求处理系统，其特征在于，所述系统包括：

如权利要求9所述的前端代理服务器；

数据库，用于存储域名-后台路径数据；

后端服务器，用于根据前端代理服务器发送的对所述数据库的查询结果，获取相应的页面数据，并将所述页面数据通过所述前端代理服务器发送至客户端。