一种域名解析方法及装置与流程

本申请涉及计算机领域，尤其涉及一种域名解析方法及装置。

背景技术：

现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。

基于此，业界提出了负载均衡(loadbalance)，其可以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡策略包含轮询法、加权轮询法、最小连接数法、随机法、源地址哈希法等，在具体实现时，根据客户端的请求，采用轮询、最小连接数、随机或者源地址哈希法，分配后端服务器。

然而，当后端某个服务器出现故障时，客户端不能正常访问该节点，也即该服务器。例如，在域名解析场景下，若某一域名解析服务器发送故障，若仍按照原有的物理地址去查找虚拟地址，将会产生域名解析异常，返回错误等现象，影响用户体验。

技术实现要素：

有鉴于此，本申请提供了一种域名解析方法，服务端的主节点根据第一配置文件以及虚拟地址查询命令确定服务端所有节点的物理地址和虚拟地址，并通过与第二配置文件中的虚拟地址进行比较，以实现故障节点的物理地址过滤，避免按照原有的物理地址查找虚拟地址，从而避免了域名解析异常、返回错误的现象发生，提高了用户体验。对应地，本申请还提供了一种域名解析装置。

本申请第一方面提供了一种域名解析方法，服务端包括多个服务节点，所述服务节点配置有第一配置文件和第二配置文件，所述第一配置文件包括所述服务端所有服务节点的物理地址，所述第二配置文件包括客户端应访问的域名、访问所述域名时所述服务节点使用的负载均衡策略以及所述域名对应的虚拟地址，当任一服务节点发生故障，其虚拟地址被分配给其他服务节点，所述多个服务节点的主节点能够根据所述第一配置文件和虚拟地址查询命令确定所述服务端的各个服务节点的物理地址以及对应的虚拟地址，将所述主节点确定的所述服务端各个服务节点的虚拟地址与所述域名对应的虚拟地址进行比较，若匹配，则返回所述虚拟地址对应的物理地址并保存，以过滤故障节点的物理地址，所述方法包括：

接收客户端发送的访问请求；所述访问请求携带指定网站的域名和/或虚拟地址；

根据所述访问请求以及所述第二配置文件确定所述客户端访问所述指定网站时所述服务节点使用的负载均衡策略；

将各个服务节点的物理地址与所述主节点保存的物理地址进行比较，若相同，则确定所述服务节点是否与所述负载均衡策略相匹配；若匹配，则根据所述服务节点的物理地址确定对应的虚拟地址；

向所述客户端返回所述虚拟地址，以使所述客户端根据所述虚拟地址连接到对应的服务节点，访问所述指定网站。

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

接收所述多个服务节点中除主节点以外的其他服务节点发送的第一消息，所述第一消息包括所述服务节点自身的资源使用情况；

则所述确定所述服务节点是否与所述负载均衡策略相匹配包括：

根据所述服务节点自身的资源使用情况确定所述服务节点是否与所述负载均衡策略相匹配。

可选的，所述资源使用情况包括连接数、中央处理器cpu使用率和/或内存使用率；

则所述根据所述服务节点自身的资源使用情况确定所述服务节点是否与所述负载均衡策略相匹配包括:

若所述负载均衡策略为最小连接数策略，则确定连接数最小的服务节点与所述负载均衡策略相匹配；

若所述负载均衡策略为最小cpu策略，则确定cpu使用率最小的服务节点与所述负载均衡策略相匹配；

若所述负载均衡策略为最小内存策略，则确定所述内存最小的服务节点与所述负载均衡策略相匹配。

可选的，所述第一消息还包括所述服务节点自身的物理地址和对应的虚拟地址；

所述方法还包括：

记录所述服务节点的物理地址和对应的虚拟地址；

则返回所述虚拟地址对应的物理地址并保存包括：

返回所述虚拟地址对应的物理地址，并将所述物理地址在所述记录中进行更新。

可选的，若根据所述服务节点的物理地址确定的虚拟地址包括多个；

则向所述客户端返回所述虚拟地址包括：

通过轮询的方式向所述客户端返回所述多个虚拟地址中的一个。

本申请第二方面提供了一种域名解析装置，服务端包括多个服务节点，所述服务节点配置有第一配置文件和第二配置文件，所述第一配置文件包括所述服务端所有服务节点的物理地址，所述第二配置文件包括客户端应访问的域名、访问所述域名时所述服务节点使用的负载均衡策略以及所述域名对应的虚拟地址，当任一服务节点发生故障，其虚拟地址被分配给其他服务节点，所述多个服务节点的主节点能够根据所述第一配置文件和虚拟地址查询命令确定所述服务端的各个服务节点的物理地址以及对应的虚拟地址，将所述主节点确定的所述服务端各个服务节点的虚拟地址与所述域名对应的虚拟地址进行比较，若匹配，则返回所述虚拟地址对应的物理地址并保存，以过滤故障节点的物理地址，所述装置包括：

接收模块，用于接收客户端发送的访问请求；所述访问请求携带指定网站的域名和/或虚拟地址；

确定模块，用于根据所述访问请求以及所述第二配置文件确定所述客户端访问所述指定网站时所述服务节点使用的负载均衡策略；

比较模块，用于将各个服务节点的物理地址与所述主节点保存的物理地址进行比较，若相同，则确定所述服务节点是否与所述负载均衡策略相匹配；若匹配，则根据所述服务节点的物理地址确定对应的虚拟地址；

返回模块，用于向所述客户端返回所述虚拟地址，以使所述客户端根据所述虚拟地址连接到对应的服务节点，访问所述指定网站。

可选的，所述接收模块还用于：

接收所述多个服务节点中除主节点以外的其他服务节点发送的第一消息，所述第一消息包括所述服务节点自身的资源使用情况；

则所述比较模块在确定所述服务节点是否与所述负载均衡策略相匹配时，具体用于：

根据所述服务节点自身的资源使用情况确定所述服务节点是否与所述负载均衡策略相匹配。

可选的，所述资源使用情况包括连接数、中央处理器cpu使用率和/或内存使用率；

则所述比较模块在所述根据所述服务节点自身的资源使用情况确定所述服务节点是否与所述负载均衡策略相匹配时，具体用于:

若所述负载均衡策略为最小连接数策略，则确定连接数最小的服务节点与所述负载均衡策略相匹配；

若所述负载均衡策略为最小cpu策略，则确定cpu使用率最小的服务节点与所述负载均衡策略相匹配；

若所述负载均衡策略为最小内存策略，则确定所述内存最小的服务节点与所述负载均衡策略相匹配。

可选的，所述第一消息还包括所述服务节点自身的物理地址和对应的虚拟地址；

所述装置还包括：

记录模块，用于记录所述服务节点的物理地址和对应的虚拟地址；

则所述返回模块具体用于：

返回所述虚拟地址对应的物理地址，并将所述物理地址在所述记录中进行更新。

可选的，若根据所述服务节点的物理地址确定的虚拟地址包括多个；

则所述返回模块具体用于：

通过轮询的方式向所述客户端返回所述多个虚拟地址中的一个。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中提供了一种域名解析方法，在该方法中，服务端包括多个服务节点，所述服务节点配置有第一配置文件和第二配置文件，所述第一配置文件包括所述服务端所有服务节点的物理地址，所述第二配置文件包括客户端应访问的域名、访问所述域名时所述服务节点使用的负载均衡策略以及所述域名对应的虚拟地址，当任一服务节点发生故障，其虚拟地址被分配给其他服务节点，所述多个服务节点的主节点能够根据所述第一配置文件和虚拟地址查询命令确定所述服务端的各个服务节点的物理地址以及对应的虚拟地址，将所述主节点确定的所述服务端各个服务节点的虚拟地址与所述域名对应的虚拟地址进行比较，若匹配，则返回所述虚拟地址对应的物理地址并保存。

通过该方法，可以充分考虑到后端服务节点的使用情况，当某个服务节点出现故障时，该服务节点占有的虚拟地址被分配给其他服务节点接管，主节点定期通过第一配置文件和虚拟地址查询命令，更新每个物理地址及其对应的虚拟地址，通过第二配置文件中的虚拟地址与保存的物理地址和虚拟地址对应关系，查找有效的物理地址，从而可以过滤掉有故障节点的物理地址。如此，客户端在访问时不会按照故障节点的物理地址查找虚拟地址，而是从过滤后的物理地址中查找与所述负载均衡策略相匹配的服务节点的物理地址，并根据所述物理地址确定对应的虚拟地址，并向客户端返回，使得客户端根据该虚拟地址连接到对应的服务节点，访问所述指定网站，一方面减少资源浪费，另一方面避免了域名解析异常、返回错误等现象发生，造成网络中断的情况，提高了后端服务节点处理客户端请求的效率，进一步加强网络数据处理能力、提高网络的灵活性和可用性。

附图说明

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

图1为本申请实施例中一种第一配置文件的示意图；

图2为本申请实施例中一种第二配置文件的示意图；

图3为本申请实施例中一种在主节点查询虚拟地址的示意图；

图4为本申请实施例中一种域名解析方法的流程图；

图5为本申请实施例中一种向主节点发送第一消息的示意图；

图6为本申请实施例中一种域名解析装置的结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

针对现有技术中后端某个服务器出现故障时导致域名解析异常，进而使得客户端不能正常访问该节点的技术问题，本申请提供了一种域名解析方法，在该方法中，当某个服务节点出现故障时，该服务节点占有的虚拟地址被分配给其他服务节点接管，服务节点中的主节点通过第一配置文件和虚拟地址查询命令，更新每个物理地址及其对应的虚拟地址，然后将第二配置文件中的虚拟地址与主节点更新的虚拟地址进行比较，以获得有效的物理地址，从而可以过滤掉有故障节点的物理地址。基于过滤后的物理地址与虚拟地址的对应关系，根据负载均衡策略，返回有效物理地址对应的虚拟地址，供客户端建立连接，从而减少资源的浪费，又防止了域名解析错误，造成网络中断的情况，提高后端服务节点处理客户端请求的效率，进一步加强网络数据处理能力、提高网络的灵活性和可用性。

可以理解，该方法应用于服务端，其可以应用程序的形式存储于服务端，服务端通过执行应用程序，以实现本申请的域名解析方法。需要说明的是，本申请的应用程序可以是独立的应用程序，也可以是集成于其他应用程序上的功能模块，本申请实施例对此不作限定。

接下来，结合附图，对本申请实施例的域名解析方法进行详细说明。

在该方法中，服务端包括多个服务节点，所述服务节点配置有第一配置文件(记作nodes)和第二配置文件(记作loadbalance.xml)，所述第一配置文件nodes包括所述服务端所有服务节点的物理地址，也即物理ip。其中，物理地址是服务节点的固定地址，对于每个服务节点而言，其物理地址是不可变的。在具体实现时，物理地址可以是服务节点的介质访问控制(mediaaccesscontrol，mac)地址。图1示出了第一配置文件的示意图，如图1所示，该第一配置文件保存了3个物理ip，这3个物理ip对应的服务节点是一个集群。

所述第二配置文件loadbalance.xml包括客户端应访问的域名、访问所述域名时所述服务节点使用的负载均衡策略以及所述域名对应的虚拟地址。其中，虚拟地址也称虚拟ip，虚拟地址是服务节点的可变地址，对于每个服务节点而言，其虚拟地址是可变的。图2示出了第二配置文件loadbalance.xml的示意图，如图2所示，该第二配置文件保存有域名配置项<domainnamename＝www.test1.com>，负载均衡策略配置项<policyvalue＝“memory”>，表示服务节点使用的负载均衡策略为最小内存策略，虚拟地址配置项<addresspooladdress＝“100.7.44.106”weight＝“1”/>，其包括该域名下的虚拟地址以及对应的权重。

当任一服务节点发生故障，其虚拟地址被分配给其他服务节点，所述多个服务节点的主节点能够根据所述第一配置文件nodes和虚拟地址查询命令确定所述服务端的各个服务节点的物理地址以及对应的虚拟地址，其中，虚拟地址查询命令具体可以为ctdbip，如图3所示，其为在主节点(节点1)查询虚拟地址的示意图，其中，虚拟地址100.7.44.106和100.7.44.108对应同一个服务节点，该服务节点具有两个虚拟地址。在具体实现时，第一配置文件nodes保存的各服务节点的物理地址对应数组的下标，由零开始编号，如图1，100.7.44.56对应数组下标为0，100.7.44.57对应数组下标为1，100.7.44.58对应数组下标为2；在通过ctdbip查询虚拟地址时，虚拟地址之后标注有对应的数组下标，如此，可以通过该数组下标确定各个物理地址对应的虚拟地址。然后，主节点可以将所述主节点确定的所述服务端各个服务节点的虚拟地址与所述域名对应的虚拟地址进行比较，若匹配，则返回所述虚拟地址对应的物理地址并保存，以过滤故障节点的物理地址。

接着，请参见图4所示的域名解析方法的流程图，该方法包括：

s401：接收客户端发送的访问请求。

所述访问请求携带指定网站的域名和/或虚拟地址，如此，可以通过对指定网站的域名解析得到指定网站的服务端对应的虚拟地址，或者根据携带的虚拟地址确定服务端过滤后的虚拟地址，然后基于该虚拟地址建立网络连接，从而实现访问指定网站。

s402：根据所述访问请求以及所述第二配置文件确定所述客户端访问所述指定网站时所述服务节点使用的负载均衡策略。

第二配置文件loadbalance.xml包括客户端应访问的域名、访问域名时服务节点使用的负载均衡策略以及域名对应的虚拟地址，而访问请求中携带有域名和/或虚拟地址，因此，可以将访问请求与第二配置文件进行匹配，从而确定客户端访问指定网站时，服务节点使用的负载均衡策略。

s403：将各个服务节点的物理地址与所述主节点保存的物理地址进行比较，若相同，则确定所述服务节点是否与所述负载均衡策略相匹配；若匹配，则根据所述服务节点的物理地址确定对应的虚拟地址。

在本实施例中，主节点保存的物理地址是经过过滤的物理地址，其物理地址均为处于正常工作状态的物理地址，因此，将各个服务节点的物理地址与主节点保存的物理地址进行比较，可以确定各个服务节点的物理地址是否发生故障。具体地，若服务节点的物理地址与主节点保存的物理地址相同，则表明该服务节点处于正常工作状态，并未发生故障，若服务节点的物理地址与主节点保存的物理地址中的任意一个均不相同，则表明该服务节点发生故障，无法正常工作。

在确定出处于正常工作状态的服务节点后，主节点可以确定各个服务节点是否与负载均衡策略相匹配，若匹配，则可以根据主节点保存的物理地址以及虚拟地址的对应关系，确定与负载均衡策略相匹配的服务节点的物理地址所对应的虚拟地址。

其中，确定各个服务节点是否与负载均衡策略相匹配，是通过各个服务节点的资源使用情况而确定的。在一些可能的实现方式中，服务端多个服务节点中除主节点以外的其他服务节点定时向主节点发送第一消息，如图5所示，该第一消息包括服务节点自身的资源使用情况，如连接数、内存使用率、和/或中央处理器(centralprocessingunit，cpu)使用率等。主节点接收多个服务节点中除主节点以外的其他服务节点发送的第一消息，可以根据服务节点自身的资源使用情况确定服务节点是否与负载均衡策略相匹配。其中，其他服务节点在向主节点发送第一消息时，可以通过简单网络管理协议(simplenetworkmanagementprotocol，snmp)将自身的资源使用情况发送给主节点，即节点1。

具体地，若所述负载均衡策略为最小连接数策略，则确定连接数最小的服务节点与所述负载均衡策略相匹配；若所述负载均衡策略为最小cpu策略，则确定cpu使用率最小的服务节点与所述负载均衡策略相匹配；若所述负载均衡策略为最小内存策略，则确定所述内存最小的服务节点与所述负载均衡策略相匹配。

s404：向所述客户端返回所述虚拟地址，以使所述客户端根据所述虚拟地址连接到对应的服务节点，访问所述指定网站。

主节点向客户端返回s403中确定的虚拟地址，以使客户端根据所述虚拟地址连接到对应的服务节点，访问所述指定网站。还需要说明的是，若根据所述服务节点的物理地址确定的虚拟地址包括多个；则在向所述客户端返回所述虚拟地址时，可以通过轮询的方式向所述客户端返回所述多个虚拟地址中的一个。

由上可知，本申请实施例提供了一种域名解析方法，在该方法中，当某个服务节点出现故障时，该服务节点占有的虚拟地址被分配给其他服务节点接管，服务节点中的主节点通过第一配置文件和虚拟地址查询命令，更新每个物理地址及其对应的虚拟地址，然后将第二配置文件中的虚拟地址与主节点更新的虚拟地址进行比较，以获得有效的物理地址，从而可以过滤掉有故障节点的物理地址。基于过滤后的物理地址与虚拟地址的对应关系，根据负载均衡策略，返回有效物理地址对应的虚拟地址，供客户端建立连接，从而减少资源的浪费，又防止了域名解析错误，造成网络中断的情况，提高后端服务节点处理客户端请求的效率，进一步加强网络数据处理能力、提高网络的灵活性和可用性。

在上述实施例中，主节点是通过第一配置文件和虚拟地址查询命令确定服务端的各个服务节点的物理地址以及对应的虚拟地址，在一些可能的实现方式中，第一消息还包括服务节点自身的物理地址和对应的虚拟地址，主节点接收到第一消息，记录服务节点的物理地址和对应的虚拟地址，如此，当有服务节点故障时，其虚拟地址被分配给其他服务节点，主节点能够根据所述第一配置文件和虚拟地址查询命令确定所述服务端的各个服务节点的物理地址以及对应的虚拟地址，主节点将其确定的各个服务节点的虚拟地址与域名对应的虚拟地址进行比较，若匹配，则返回虚拟地址对应的物理地址，然后将物理地址在记录中进行更新。如此，主节点通过查找记录即可确定服务节点的物理地址和对应的虚拟地址。

以上为本申请实施例提供的域名解析方法的具体实现方式，基于此，本申请实施例还提供了对应的域名解析装置，接下来，从功能模块化的角度对本申请实施例提供的域名解析装置进行介绍。

服务端包括多个服务节点，所述服务节点配置有第一配置文件和第二配置文件，所述第一配置文件包括所述服务端所有服务节点的物理地址，所述第二配置文件包括客户端应访问的域名、访问所述域名时所述服务节点使用的负载均衡策略以及所述域名对应的虚拟地址，当任一服务节点发生故障，其虚拟地址被分配给其他服务节点，所述多个服务节点的主节点能够根据所述第一配置文件和虚拟地址查询命令确定所述服务端的各个服务节点的物理地址以及对应的虚拟地址，将所述主节点确定的所述服务端各个服务节点的虚拟地址与所述域名对应的虚拟地址进行比较，若匹配，则返回所述虚拟地址对应的物理地址并保存，以过滤故障节点的物理地址，参见图6所示的域名解析装置的结构示意图，所述装置包括：

接收模块610，用于接收客户端发送的访问请求；所述访问请求携带指定网站的域名和/或虚拟地址；

确定模块620，用于根据所述访问请求以及所述第二配置文件确定所述客户端访问所述指定网站时所述服务节点使用的负载均衡策略；

比较模块630，用于将各个服务节点的物理地址与所述主节点保存的物理地址进行比较，若相同，则确定所述服务节点是否与所述负载均衡策略相匹配；若匹配，则根据所述服务节点的物理地址确定对应的虚拟地址；

返回模块640，用于向所述客户端返回所述虚拟地址，以使所述客户端根据所述虚拟地址连接到对应的服务节点，访问所述指定网站。

可选的，所述接收模块610还用于：

接收所述多个服务节点中除主节点以外的其他服务节点发送的第一消息，所述第一消息包括所述服务节点自身的资源使用情况；

则所述比较模块630在确定所述服务节点是否与所述负载均衡策略相匹配时，具体用于：

根据所述服务节点自身的资源使用情况确定所述服务节点是否与所述负载均衡策略相匹配。

可选的，所述资源使用情况包括连接数、中央处理器cpu使用率和/或内存使用率；

则所述比较模块630在所述根据所述服务节点自身的资源使用情况确定所述服务节点是否与所述负载均衡策略相匹配时，具体用于:

若所述负载均衡策略为最小连接数策略，则确定连接数最小的服务节点与所述负载均衡策略相匹配；

若所述负载均衡策略为最小cpu策略，则确定cpu使用率最小的服务节点与所述负载均衡策略相匹配；

若所述负载均衡策略为最小内存策略，则确定所述内存最小的服务节点与所述负载均衡策略相匹配。

可选的，所述第一消息还包括所述服务节点自身的物理地址和对应的虚拟地址；

所述装置还包括：

记录模块，用于记录所述服务节点的物理地址和对应的虚拟地址；

则所述返回模块640具体用于：

返回所述虚拟地址对应的物理地址，并将所述物理地址在所述记录中进行更新。

可选的，若根据所述服务节点的物理地址确定的虚拟地址包括多个；

则所述返回模块640具体用于：

通过轮询的方式向所述客户端返回所述多个虚拟地址中的一个。

由上可知，本申请实施例提供了一种域名解析装置，在该装置中，当某个服务节点出现故障时，该服务节点占有的虚拟地址被分配给其他服务节点接管，服务节点中的主节点通过第一配置文件和虚拟地址查询命令，更新每个物理地址及其对应的虚拟地址，然后将第二配置文件中的虚拟地址与主节点更新的虚拟地址进行比较，以获得有效的物理地址，从而可以过滤掉有故障节点的物理地址。基于过滤后的物理地址与虚拟地址的对应关系，根据负载均衡策略，返回有效物理地址对应的虚拟地址，供客户端建立连接，从而减少资源的浪费，又防止了域名解析错误，造成网络中断的情况，提高后端服务节点处理客户端请求的效率，进一步加强网络数据处理能力、提高网络的灵活性和可用性。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(英文全称：read-onlymemory，英文缩写：rom)、随机存取存储器(英文全称：randomaccessmemory，英文缩写：ram)、磁碟或者光盘等各种可以存储程序代码的介质。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。