网关代理场景中的微服务访问方法、装置、设备及介质

技术领域

本申请属于互联网技术领域，具体涉及一种网关代理场景中的微服务访问方法、装置、设备及介质。

背景技术

微服务架构使由多个微服务共同构成的一个大型系统，每个微服务负责处理特定的业务逻辑。而API网关担任整个系统的入口，用于接收客户端的请求，并根据请求的目标路径或其他条件将请求分发给相应的微服务。

目前，网关代理分流架构请求经过网关转发至后端服务是通过公网进行的。但是随着访问请求量增长，在公网环境下转发会增加网络带宽开销，环境稳定性也容易受公网质量影响。

因此，如何能对现有的网关转发架构进行调整，避免因为公网网络环境影响微服务的访问质量，以及，因为微服务的访问对公网造成额外开销的问题，是本领域技术人员亟待解决的技术问题。

发明内容

本申请实施例的目的是提供一种网关代理场景中的微服务访问方法、装置、设备及介质，可以将用户通过公网发出的访问请求中的公网域名转换为内网域名，对内网域名进行内网DNS解析，确定内网地址并向目标微服务接口发送访问请求，降低网络开销的同时减弱了公网稳定性的影响。

第一方面，本申请实施例提供了一种网关代理场景中的微服务访问方法，所述方法包括：

接收用户通过公网发出的访问请求；

基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

进一步的，在基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名之前，所述方法还包括：

通过预先构建的配置文件停止基于所述公网域名对目标微服务的公网地址的访问。

进一步的，在基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名之前，所述方法还包括：

根据当前API网关管理的所有下游微服务，确定各微服务的公网域名对应的内网域名，并存储于配置文件中。

进一步的，所述配置文件包括：upstream配置文件。

进一步的，所述方法还包括：

若识别到内网域名的解析地址发生变更，则对DNS服务器中的内网DNS解析进行同步变更。

进一步的，在基于所述API网关根据所述访问请求确定的目标微服务的公网域名之前，所述方法还包括：

基于所述API网关根据下游微服务的负载量以及预设负载权重确定所述访问请求的目标微服务。

第二方面，本申请实施例提供了一种网关代理场景中的微服务访问装置，所述装置包括：

访问请求接收模块，用于接收用户通过公网发出的访问请求；

公网域名确定模块，用于基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

内网域名确定模块，用于基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

请求发送模块，用于根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

进一步的，所述装置还包括：

停止访问模块，用于通过预先构建的配置文件停止基于所述公网域名对目标微服务的公网地址的访问。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。

第五方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法。

在本申请实施例中，接收用户通过公网发出的访问请求；基于所述API网关根据所述访问请求确定的目标微服务的公网域名；基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。通过上述网关代理场景中的微服务访问方法，可以将用户通过公网发出的访问请求中的公网域名转换为内网域名，对内网域名进行内网DNS解析，确定内网地址并向目标微服务接口发送访问请求，降低网络开销的同时减弱了公网稳定性的影响。

附图说明

图1是本申请实施例一提供的网关代理场景中的微服务访问方法的流程示意图；

图2是本申请实施例二提供的网关代理场景中的微服务访问方法的流程示意图；

图3是本申请实施例三提供的网关代理场景中的微服务访问方法的流程示意图；

图4是本申请实施例四提供的网关代理场景中的微服务访问方法的流程示意图；

图5是本申请实施例五提供的网关代理场景中的微服务访问方法的流程示意图；

图6是本申请实施例六提供的网关代理场景中的微服务访问装置的结构示意图；

图7是本申请实施例七提供的电子设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的网关代理场景中的微服务访问方法、装置、设备及介质进行详细地说明。

实施例一

图1是本申请实施例一提供的网关代理场景中的微服务访问方法的流程示意图。如图1所示，具体包括如下步骤：

S101、接收用户通过公网发出的访问请求；

本方案的应用场景，可以是用户在请求访问网络时，API网关接收用户的访问请求，根据转换规则获取目标微服务的内网域名，通过内网DNS解析确定目标微服务的内网地址，并向目标微服务的接口发出请求的场景。

基于上述使用场景，可以理解的，本申请的执行主体可以是该API网关，或者可以是运行API网关的台式电脑、笔记本电脑、平板电脑以及交互式多媒体设备等，此处不做过多的限定。

公网，可以是连接不同地区局域网或计算机通信的远程网。承接很大的物理范围，能够连接多个地区、城市和国家，为其提供远距离通信。访问请求，可以是用户向浏览器输入网址后，浏览器将域名解析成对应的IP地址，并在互联网上找到对应的服务器，由客户端向服务器发送协议请求包，以请求服务器里的资源文档。

接收用户的访问请求的方式，可以是由用户向浏览器输入想要访问的网址，浏览器将该网址解析为对应到的IP地址，从客户端发送到API网关，由API网关进行接收。

S102、基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

API网关，可以看做系统与外界联通的入口，可以通过网关进行处理一些非业务逻辑的逻辑，比如权限验证、监控、缓存以及请求路由等等。微服务，可以是微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。在微服务中，每个服务都是自我包含的，并且实现了单一的业务功能。目标微服务，可以是用户需要访问的微服务。公网域名，可以是主机在公网环境中的标识，由一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时标识计算机的电子方位(有时也指地理位置)。

确定目标微服务的公网域名，可以是API在接收到用户发出的访问请求后，对访问请求进行分析解读，提取其中的需求功能等信息，筛选接入API网关的所有微服务中符合需求功能条件、满足用户请求的微服务作为目标微服务。向目标微服务发送域名请求，待目标微服务响应后，从返回的信息中提取该目标微服务的公网域名。

S103、基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

预先定义的转换规则，可以是预先收集所有微服务的公网域名以及内网域名，将同一微服务的公网域名与内网域名对应存储在API网关的指定位置。内网域名，可以是仅在关联VPC内生效的虚拟域名，具有随意创建使用的特点，内网域名不能再域名注册商购买，同时也无法通过备案。

确定目标微服务的内网域名的方式，可以是在获取到目标微服务的公网域名之后，调取预先存储在API网关的转换规则，根据公网域名以及内网域名的映射关系，确定目标微服务的公网域名对应的内网域名。

S104、根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

内网DNS解析，可以是将目标微服务的内网域名解析为内网地址的方法。公网域名请求头，可以是在HTTP协议中用于传递关于请求的额外信息的部分。请求头包含了客户端(通常是浏览器或应用程序)与服务器之间进行通信所需的元数据。在访问微服务器过程中，只有内网地址无法对微服务器进行访问，需要同时携带内网域名请求头才可以正常访问微服务器。

对内网域名进行内网DNS解析的方式，可以是采用递归查询的方式。具体的，可以是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，也就是代替主机继续查询，直到查询到知道被查询域名的IP地址的服务器为止。

向微服务的接口发出请求的方式，可以是对获取到的内网域名进行内网DNS解析，通过服务器返回的信息获取内网域名对应的内网地址，将内网地址以及公网域名的请求头一起写入访问请求指令，发送到对应微服务的接口。

例如，用户想要访问某下游微服务，可以先通过公网请求进行API网关，向API网关发送访问请求。API网关根据用户请求反向代理转发至下游的微服务接口公网域名www.baidu.com，通过将www.baidu.com输入upstream配置文件完成该公网域名的捕获，upstream配置文件输入的将公网域名转换为内网域名，并由内网DNS解析将内网域名解析为内网地址，最终通过内网地址携带公网域名的请求头文件向下游微服务内网入口发出访问请求。在本示例中，相比于访问下游微服务的公网入口，向下游微服务内网入口发出访问请求会使整个平台业务公网请求带宽下降20％，成本得到了大幅优化。

并且，通过内网入口向下游微服务发出访问请求还可以在一定程度上减小故障的损害范围，例如，如果由于腾讯云某机房故障导致NAT出口网关出现异常，服务器出口网络部分IP地址不可用。而通过网关内网转发改造用户进来的请求下游微服务不会再经过公网转发，因此可以大幅减小故障面。

在本申请实施例中，接收用户通过公网发出的访问请求；基于所述API网关根据所述访问请求确定的目标微服务的公网域名；基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。通过上述网关代理场景中的微服务访问方法，可以将用户通过公网发出的访问请求中的公网域名转换为内网域名，对内网域名进行内网DNS解析，确定内网地址并向目标微服务接口发送访问请求，降低网络开销的同时减弱了公网稳定性的影响。

实施例二

图2是本申请实施例二提供的网关代理场景中的微服务访问方法的流程示意图。本方案对上述实施例做出了更优的改进，具体改进为：在基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名之前，所述方法还包括：通过预先构建的配置文件停止基于所述公网域名对目标微服务的公网地址的访问。

如图2所示，具体包括如下：

S201、接收用户通过公网发出的访问请求；

S202、基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

S203、通过预先构建的配置文件停止基于所述公网域名对目标微服务的公网地址的访问；

预先构建的配置文件，可以是能够提供跨越单机的横向处理能力，实现网络数据的接收、处理和转发的配置文件。公网地址，可以称为全球唯一IP地址，是指可以直接在Internet上访问的IP地址。公网地址由互联网注册机构分配，具有全球唯一性和全球可达性，可以直接访问Internet上的其他设备，并且通过Internet进行通信和数据传输。

停止对目标微服务的访问的方式，可以是在获取到目标问服务的公网域名后，API网关会自动通过公网域名向目标微服务的公网地址进行访问，占用公网资源。通过预先构建的配置文件，可以增大对内网地址访问的权重，从而使API网关不再优先向公网地址进行访问。

S204、基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

S205、根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

可选的，所述配置文件包括：upstream配置文件。

upstream配置文件，可以是用于使反向代理服务器跨越单机的限制，摆脱只能为终端节点提供单一功能的限制，完成网络数据的接收、处理和转发，实现由公网解析转换成内网解析的模块。upstream配置文件可以提供四种将负载均衡算法，包括：

round robin：默认的负载均衡算法。如果服务器组未定义负载均衡算法，将会用轮询的方式将请求路由到服务器组中的主机。

least_conn：该算法会把新请求路由到具有最少活动连接的后端主机中，同时考虑服务器的权重。如果有多个这样的服务器，则会尝试使用加权轮询平衡算法。

ip_hash：根据客户端IP在服务器组中分配请求。该算法保证来自统一客户端的请求将始终传递到同一服务器，除非该服务器不可用。

hash：为client-server映射一个基于散列值的服务器组，可以包含文本、变量或者他们的组合。

本方案这样设置的好处是，可以通过配置文件停止公网域名对目标微服务的公网地址的访问，减少网络宽带开销，避免占用公网资源，为后续通过内网访问目标微服务做准备。

实施例三

图3是本申请实施例三提供的网关代理场景中的微服务访问方法的流程示意图。本方案对上述实施例做出了更优的改进，具体改进为：在基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名之前，所述方法还包括：根据当前API网关管理的所有下游微服务，确定各微服务的公网域名对应的内网域名，并存储于配置文件中。

如图3所示，具体包括如下：

S301、接收用户通过公网发出的访问请求；

S302、基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

S303、根据当前API网关管理的所有下游微服务，确定各微服务的公网域名对应的内网域名，并存储于配置文件中；

确定各微服务的公网域名对应的内网域名的方式，可以是由API网关向管理的下游微服务发送公网域名以及获取对应内网域名的请求，接收各微服务的响应后，提取返回信息中的内网域名，并将该内网域名与相应微服务的公网域名进行关联存储。

将各微服务的公网域名以及对应的内网域名存储于配置文件中的方式，可以是将微服务的公网域名与相对应的内网域名进行关联，并写入检索表格，以表格的形式存储在配置文件的相应位置。

S304、基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

S305、根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

本方案这样设置的好处是，可以预先将各微服务的公网域名对应的内网域名存储在配置文件中，以便在对目标微服务的域名进行转换时，可以迅速准确的获取对应的内网域名。

实施例四

图4是本申请实施例四提供的网关代理场景中的微服务访问方法的流程示意图。本方案对上述实施例做出了更优的改进，具体改进为：所述方法还包括：若识别到内网域名的解析地址发生变更，则对DNS服务器中的内网DNS解析进行同步变更。

如图4所示，具体包括如下：

S401、接收用户通过公网发出的访问请求；

S402、基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

S403、基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

S404、根据所述内网域名进行内网DNS解析，若识别到内网域名的解析地址发生变更，则对DNS服务器中的内网DNS解析进行同步变更；

DNS服务器，可以是域名服务器，用于进行域名和与之相对应的IP地址进行转换的服务器。DNS服务器中保存了一张域名和与之相对应的IP地址的表，以解析消息的域名。

识别到内网域名的解析地址发生变更的方式，可以是将当前解析到的内网地址与历史内网地址进行比较，若当前的内网地址与历史内网地址不一致，则确认内网域名的解析地址发生变更。

对DNS服务器中的内网DNS解析进行同步变更的方式，可以是当识别到内网域名的解析地址发生变更后，从内网DNS解析的域名和对应IP地址的表中提取发生变更的内网域名，将其对于的地址清除并写入更改后的新地址。

S405、确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

本方案这样设置的好处是，可以在识别到内网域名的解析地址发生变更时，对DNS服务器中的内网DNS解析进行同步变更，从而实现对解析地址的监测以及内网DNS解析的及时更新，保障了内网地址的准确性。

实施例五

图5是本申请实施例五提供的网关代理场景中的微服务访问方法的流程示意图。本方案对上述实施例做出了更优的改进，具体改进为：在基于所述API网关根据所述访问请求确定的目标微服务的公网域名之前，所述方法还包括：基于所述API网关根据下游微服务的负载量以及预设负载权重确定所述访问请求的目标微服务。

如图5所示，具体包括如下：

S501、接收用户通过公网发出的访问请求；

S502、基于所述API网关根据下游微服务的负载量以及预设负载权重确定所述访问请求的目标微服务；

负载量，可以是下游微服务正在处理的任务数量以及待处理的任务数量。预设负载权重，可以是预先设定的微服务需要处理的总任务的占比。当API弯管根据下游的微服务性能分布不均衡时，性能较高、效率较快的微服务应设置较大的权重，以减轻性能较低的微服务的负担，防止任务处理缓慢。

确定访问请求的目标微服务的方式，可以是提取访问请求中的需求功能，按照需求功能筛选对应的微服务，在筛选出的微服务中，预先选择预设负载权重大且负载量小的微服务作为目标微服务，若预设负载权重大的微服务中的负载量已超过微服务的承载量，则选择预设负载权重较小且负载量小的微服务作为目标微服务。

S503、基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

S504、基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

S505、根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

本方案这样设置的好处，可以是根据下游微服务的负载量以及预设负载权重确定目标微服务，有利于缓解微服务接收访问请求过多的压力，在一定程度上保障了目标微服务的响应效率。

实施例六

图6是本申请实施例六提供的网关代理场景中的微服务访问装置的结构示意图。

如图6所示，具体包括如下：

访问请求接收模块601，用于接收用户通过公网发出的访问请求；

公网域名确定模块602，用于基于所述API网关根据所述访问请求确定的目标微服务的公网域名；

内网域名确定模块603，用于基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；

请求发送模块604，用于根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。

相应的，所述装置还包括：

停止访问模块，用于通过预先构建的配置文件停止基于所述公网域名对目标微服务的公网地址的访问。

在本申请实施例中，访问请求接收模块，用于接收用户通过公网发出的访问请求；公网域名确定模块，用于基于所述API网关根据所述访问请求确定的目标微服务的公网域名；内网域名确定模块，用于基于预先定义的转换规则，确定所述目标微服务的公网域名对应的内网域名；请求发送模块，用于根据所述内网域名进行内网DNS解析，确定所述目标微服务的内网地址，并携带公网域名请求头向所述目标微服务的接口发出请求。通过上述网关代理场景中的微服务访问装置，可以将用户通过公网发出的访问请求中的公网域名转换为内网域名，对内网域名进行内网DNS解析，确定内网地址并向目标微服务接口发送访问请求，降低网络开销的同时减弱了公网稳定性的影响。

本申请实施例中的网关代理场景中的微服务访问装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，非移动电子设备可以微服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的网关代理场景中的微服务访问装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的网关代理场景中的微服务访问装置能够实现上述各方法实施例实现的各个过程，为避免重复，这里不再赘述。

实施例七

如图7所示，本申请实施例还提供一种电子设备700，包括处理器701，存储器702，存储在存储器702上并可在所述处理器701上运行的程序或指令，该程序或指令被处理器701执行时实现上述网关代理场景中的微服务访问装置实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

实施例八

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述网关代理场景中的微服务访问装置实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

实施例九

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述网关代理场景中的微服务访问装置实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。