CN102611735B - 一种应用服务的负载均衡方法及系统 - Google Patents

Abstract

本申请提供了一种应用服务的负载均衡方法及系统，以解决目前网络服务中的负载均衡问题。所述方法包括：不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；在每个获取周期内，依据所述当前负载信息重新计算后端服务器的权重；依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由。与传统的应用服务的负载均衡方法相比，本申请能够在完成同样功能的多个网络设备之间实现业务量的合理分配，而不至于出现一台设备过忙，其他设备未能充分发挥其作用的情况。

Description

一种应用服务的负载均衡方法及系统

技术领域

本申请涉及网络技术，特别是涉及一种应用服务的负载均衡方法及系统。

背景技术

负载均衡(又称为负载分担)，英文名称为LoadBalance，其意思就是将负载(工作任务)进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

通常，负载均衡会根据网络的不同层次(网络七层)来划分。其中，第二层的负载均衡指将多条物理链路当作一条单一的聚合逻辑链路使用，这就是链路聚合(Trunking)技术，它不是一种独立的设备，而是交换机等网络设备的常用技术。现代负载均衡技术通常操作于网络的第四层或第七层，这是针对网络应用的负载均衡技术，它完全脱离于交换机、服务器而成为独立的技术设备。这也是本文现在要讨论的对象。

负载均衡有两方面的含义：第一层含义是，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高，这就是我们常说的集群(clustering)技术。第二层含义是：大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，这主要针对Web服务器、FTP服务器、企业关键应用服务器等网络应用。这里主要讨论第二层含义所指的负载均衡。

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

基于此，目前需要解决的问题是：提供一种适用于网络服务的负载均衡方法，能够在完成同样功能的多个网络设备之间实现业务量的合理分配，而不至于出现一台设备过忙，其他设备未能充分发挥其作用的情况。

发明内容

本申请提供了一种应用服务的负载均衡方法及系统，以解决目前网络服务中的负载均衡问题。

为了解决上述问题，本申请公开了一种应用服务的负载均衡方法，包括：

不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；其中，所述应用程序运行数据是后端服务器的应用程序的运行数据，所述后端服务器为终端应用程序提供网络服务，所述终端应用程序与后端服务器的应用程序对应同一应用服务；

在每个获取周期内，依据所述当前负载信息重新计算后端服务器的权重；

依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由。

优选的，所述性能数据包括内存使用信息，和/或，CPU使用信息；所述应用程序运行数据包括实际在线人数，和/或正在下载的应用程序数，和/或正在下载的数据量，和/或实际连接数。

优选的，所述方法还包括：通过路由表维护所有可分配的后端服务器，所述路由表中记录了所有可分配的后端服务器的配置信息。

优选的，所述方法还包括：定时获取路由表中后端服务器的运行状态信息；依据所述运行状态信息检测相应的后端服务器是否异常或失效，并将异常或失效的后端服务器的配置信息从路由表中删除。

优选的，所述方法还包括：通过向所述路由表中添加后端服务器的配置信息，动态添加可分配的后端服务器。

优选的，所述方法还包括：预先配置后端服务器的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；在每个获取周期内，依据获取的当前负载信息和所配置的最大处理能力，检测后端服务器是否满载，并对满载的后端服务器进行访问控制。

优选的，所述方法还包括：每个后端服务器上预先配置了相应的最大处理能力，所述最大处理能力表示为最大在线人数、和/或最大内存使用信息、和/或最大CPU使用信息；每个后端服务器依据当前负载信息和所配置的最大处理能力，定时检测是否满载；定时获取后端服务器是否满载，并对满载的后端服务器进行访问控制。

优选的，所述定时获取后端服务器的当前负载信息之前，还包括：根据后端服务的类型，选择配置相适应的与后端服务器通信的交互协议；如果后端服务的类型调整，则重新配置相适应的与后端服务器通信的交互协议。

优选的，所述定时获取后端服务器的当前负载信息，包括：后端服务器提供监控接口，通过所述监控接口定时获取后端服务器的当前负载信息。

优选的，所述依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由，包括：依据每次计算的权重调整后端服务器的分配概率；按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。

本申请还提供了一种应用服务的负载均衡系统，包括：

负载查询模块，用于不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；其中，所述应用程序运行数据是后端服务器的应用程序的运行数据，所述后端服务器为终端应用程序提供网络服务，所述终端应用程序与后端服务器的应用程序对应同一应用服务；

权重计算模块，用于在每个获取周期内，依据所述当前负载信息重新计算后端服务器的权重；

负载调整模块，用于依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由。

优选的，所述性能数据包括内存使用信息，和/或，CPU使用信息；所述应用程序运行数据包括实际在线人数，和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或正在下载的应用程序数，和/或正在下载的数据量，和/或实际连接数。

优选的，所述系统还包括：负载维护模块，用于通过路由表维护所有可分配的后端服务器，所述路由表中记录了所有可分配的后端服务器的配置信息。

优选的，所述系统还包括：动态删除模块，用于定时获取路由表中后端服务器的运行状态信息；依据所述运行状态信息检测相应的后端服务器是否异常或失效，并将异常或失效的后端服务器的配置信息从路由表中删除。

优选的，所述系统还包括：动态添加模块，用于通过向所述路由表中添加后端服务器的配置信息，动态添加可分配的后端服务器。

优选的，所述系统还包括：第一访问控制模块，用于预先配置后端服务器的最大处理能力，所述最大处理能力表示为最大在线人数、和/或最大内存使用信息、和/或最大CPU使用信息；在每个获取周期内，依据获取的当前负载信息和所配置的最大处理能力，检测后端服务器是否满载，并对满载的后端服务器进行访问控制。

优选的，所述系统还包括：第二访问控制模块，用于每个后端服务器上预先配置相应的最大处理能力，所述最大处理能力表示为最大在线人数、和/或最大内存使用信息、和/或最大CPU使用信息；每个后端服务器依据当前负载信息和所配置的最大处理能力，定时检测是否满载；定时获取后端服务器是否满载，并对满载的后端服务器进行访问控制。

优选的，所述系统还包括：通信配置模块，用于根据后端服务的类型，选择配置相适应的与后端服务器通信的交互协议；如果后端服务的类型调整，则重新配置相适应的与后端服务器通信的交互协议。

与现有技术相比，本申请包括以下优点：

首先，本申请针对高并发的客户端请求，通过不断获取后端服务器的当前负载信息，并依据所述当前负载信息计算后端服务器的权重，然后依据每次计算的权重调整后端服务器的分配。简而言之，本申请在客户端需要接入某个应用服务的时候，首先请求接入分发(dispatch)服务，该分发服务会根据后端服务器的负载情况(如实际在线人数等)，动态调整分发策略，动态地返回后端相对空闲的服务器给客户端接入。与传统的应用服务的负载均衡方法相比，本申请能够在完成同样功能的多个网络设备之间实现业务量的合理分配，而不至于出现一台设备过忙，其他设备未能充分发挥其作用的情况。

其次，本申请还能够定时从后端服务器获取其运行状态，如果发现某个后端服务器的状态异常或已经失效，可以实时地从路由表中移除，避免再将该后端服务器分配给客户端。相应的，也可以通过在路由表中添加后端服务器的配置信息，而动态加入后端服务器供分配。

再次，本申请由于能够定时获取后端服务器的负载情况，因此当某个后端服务器的负载接近最大处理能力时，可以对其进行访问控制，即不再将客户端请求路由给该服务器，从而有效地保护后端服务。

再次，本申请中的分发(dispatch)服务器基于Erlang框架创建，可以不局限后端服务的类型，通过动态配置分发(dispatch)服务器与后端服务器通信的交互协议，满足不同类型的后端服务。

当然，实施本申请的任一产品不一定需要同时达到以上所述的所有优点。

附图说明

图1是本申请实施例所述一种应用服务的负载均衡系统的网络架构图；

图2是本申请实施例所述一种应用服务的负载均衡方法流程图；

图3是本申请实施例所述一种应用服务的负载均衡系统的结构图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请所述的负载均衡主要指：大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，这主要针对Web服务器、FTP服务器、企业关键应用服务器等网络应用。

本申请在客户端需要接入某个应用服务的时候，首先请求接入分发(dispatch)服务，该分发服务会根据后端服务器的负载情况(如实际在线人数等)，动态调整分发策略，动态地返回后端相对空闲的服务器给客户端接入。

下面通过实施例首先介绍本申请的网络架构。

参照图1所示，是本申请实施例所述一种应用服务的负载均衡系统的网络架构图。

本申请实施例所述的负载均衡主要通过分发(dispatch)服务器实现，多个客户端与所述分发(dispatch)服务器连接，分发(dispatch)服务器与多台后端服务器连接，其中每台后端服务器能够完成同样的业务功能。

当某客户端发起接入应用服务的请求时，该接入请求首先路由到所述分发服务器，分发服务器根据后端服务器的负载情况动态调整分配策略，并根据当前的分配策略选择一台服务器，将该接入请求路由到该服务器上处理。

图1所示的负载均衡网络架构适用于各种网络服务，例如IM(InstantMessenger，即时通讯)服务、云查杀服务、云盘服务、PushService服务等等。

基于图1，下面通过图2所示实施例对本申请所述方法的实现流程进行详细说明。

参照图2所示，是本申请实施例所述一种应用服务的负载均衡方法流程图。

以IM业务为例，针对大量IM客户端的高并发业务请求，分发(dispatch)服务器将按照以下步骤进行负载均衡处理：

步骤201，不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；

其中，所述应用程序运行数据是后端服务器的应用程序的运行数据，所述后端服务器为终端应用程序提供网络服务，所述终端应用程序与后端服务器的应用程序对应同一应用服务；

简而言之，提供应用服务的应用程序可分为客户端程序和服务器端的后台程序，所述终端应用程序即是指客户端程序，所述后端服务器的应用程序即是指后台程序，两者配合运行提供应用服务。

所述定时获取可以是分发服务器主动查询获取，也可以是被动获取，即后端服务器定时上报自己的负载情况。

本申请实施例将采用主动获取的方式，具体如下：

每台后端服务器可以提供自己的监控接口，分发服务器可以自己编写插件，该插件可以通过所述监控接口定期获取每台后端服务器的负载情况。

所述当前负载信息表示后端服务器在每个获取周期的实时负载情况，负载信息可包括应用程序运行数据，或者包括应用程序运行数据和性能数据，或者包括其他可反映应用程序运行情况的数据。

其中，所述性能数据是指能够反映后端服务器软硬件性能的数据，可包括内存使用信息，和/或，CPU使用信息等。所述应用程序运行数据是指能够反映后端服务器中应用程序的运行情况的数据，可包括实际在线人数，和/或正在下载的应用程序数，和/或正在下载的数据量，和/或实际连接数等。这些负载信息都是动态变量数据，都会随着时间而实时改变。

其中，在IM应用中，实际在线人数能够很合理地衡量后端服务器的实际负载情况，通过统计实际在线人数，可以剔除从统计开始到当前时刻所有统计出来的在线人数中，当前时刻实际在线的人数，而不是从开始到现在的统计数据，因为在这个过程中有些客户端可能已经下线。例如，从t时刻到t1时刻的一段时间内，总共有100个客户端连接上后端服务器，但是相继有30人下线，因此在t1时刻的实际在线人数是70，而不是曾经与服务器建立过连接的100人。

在多媒体下载应用，如音乐、视频、电影电视等网络下载中，正在下载的应用程序数是指统计下载列表中当前正在下载的应用程序数，不包括已经下载完毕和下载列表中未开始下载的应用程序数，因此正在下载的应用程序数也能够合理地衡量后端服务器的实际负载情况。

进一步的，在应用程序的下载过程中，每个应用程序下载的数据量多少也会影响后端服务器的负载，因此也可以统计出每个正在下载的应用程序的下载数据量，然后累加，就可以得到正在下载的所有应用程序的数据量，该数据量也能够合理地衡量后端服务器的实际负载情况。

此外，在其他连接多个客户端的应用中，通过统计实际连接数也可以反映出后端服务器的实际负载情况。所述实际连接数是指与后端服务器保持连接并进行交互的客户端数，不包含曾经连接过服务器但已经暂时或永久断开连接的客户端，也不包含任务队列中等待与服务器建立连接的客户端。

内存使用信息和CPU使用信息可从服务器的性能方面衡量了后端服务器的负载情况，服务器处理的业务不同，所耗费的内存和CPU也是不同的，因此无论业务量的大小如何，通过服务器的内存和/或CPU使用信息可以反映出一台服务器在当前的实际负载情况。具体的，所述内存或CPU的使用信息可以表示为内存或CPU的使用率，或者表示为已经使用的内存或CPU大小等。

此外，负载信息除以上列举的三种之外，还可以包含磁盘的读写、网卡的读写等参数信息。

步骤202，在每个获取周期内，依据所述当前负载信息重新计算后端服务器的权重；

即在每个获取周期内，每次获取到负载信息后，都会依据负载情况对每台服务器的权重进行计算。当然，如果一台后端服务器的负载情况没有变化，为了节省计算，也可以直接使用最近一次的权重计算结果。

在计算权重时，可采用下述的计算方法：

设定实际在线人数以x1表示，其权值为a；内存使用信息以x2表示，其权值为b；CPU使用信息以x3表示，其权值为c；按照以下公式计算得到一台后端服务器的总权重Y；

Y＝1-(x1×a+x2×b+x3×c)

其中，“1-”表示权重高的服务器优先分配。

当然，上述计算方法仅是举例说明，可以采用其他的权重计算，本申请对此不做限定。

步骤203，依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由。

在每个获取周期内，与上一周期相比，如果后端服务器的权重有变化，就需要重新调整服务器的分配，因为每次的分配是依据权重而完成。例如，总共有A、B、C三台后端服务器，在上一获取周期中，按照权重由高到低的排序是B、A、C，权重高的服务器比权重低的服务器处理更多的业务请求，因此服务器B分配的业务请求较多，服务器A其次，服务器C最少。在下一获取周期中，按照权重由高到低的排序变更为C、A、B，因此此时服务器C分配的业务请求较多，服务器A其次，服务器B最少。

具体的，步骤203可以包含以下两个子步骤：

子步骤1，依据每次计算的权重调整后端服务器的分配概率；

按照权重高的服务器比权重低的服务器处理更多业务请求的原则，权重高的服务器得到的分配机会较多，权重低得服务器得到的分配机会相对较少。如果后端服务器的权重有调整，就需要相应调整分配概率。

例如，按照权重由高到低，服务器A的权重为0.5，服务器B的权重为0.3，服务器C的权重为0.2，则相应的分配概率依次是50％、30％和20％。如果权重从高到低调整为服务器B是0.4、服务器C是0.3、服务器A是0.3，则相应的分配概率依次调整为40％、30％、30％。

子步骤2，按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。

在负载均衡过程中，每次分配服务器是依据上述的分配概率随机进行，即每次随机选择一台后端服务器，但总体保持各服务器的随机分配概率。例如，在某一获取周期内，服务器A、B、C的分配概率是50％、30％和20％，则总共分配10次请求，其中5次请求分配给服务器A处理，3次请求分配给服务器B处理，2次请求分配给服务器C处理。

在选定某台后端服务器后，可以将当前的客户端的接入请求路由给所选定的这台服务器。

综上所述，由上述流程可以看出，上述的适用于各种应用服务的负载均衡方法能够根据后端服务器的负载情况，动态调整分发策略，动态地返回后端相对空闲的服务器给客户端接入。与传统的应用服务的负载均衡方法相比，上述方法能够在完成同样功能的多个网络设备之间实现业务量的合理分配，而不至于出现一台设备过忙，其他设备未能充分发挥其作用的情况。

此外，分发服务器除了可以采用图2所示的负载均衡方法外，也可以采用以下几种负载均衡方法中的任意一种：

(1)轮询法

在一个任务队列里，队列的每个成员(节点)都具有相同的地位，轮询法简单地在这组成员中顺序轮转选择。在负载均衡环境中，分发服务器将新的请求轮流发给任务队列中的下一节点，如此连续、周而复始，每个集群的节点都在相等的地位下被轮流选择。

轮询法的活动是可预知的，每个节点被选择的机会是1/N，因此很容易计算出节点的负载分布。轮询法典型的适用于集群中所有节点的处理能力和性能均相同的情况。

(2)最少连接法

在最少连接法中，分发服务器纪录目前所有的活跃连接，把下一个新的请求发给当前含有最少连接数的节点。

这种方法比较适合后端业务相同，机器配置相同，并且每个连接负载基本类似的服务，比如IM业务。

(3)加权轮询调度法

加权轮询调度(WeightedRound-RobinScheduling)方法用相应的权值表示节点的处理性能，根据权值的高低顺序并按照轮询的方式将任务请求分配到各节点。权值高的结点比权值低的结点处理更多的任务请求，相同权值的结点处理相同份额的请求。

在整个业务处理过程中，这种加权轮询调度法对节点处理性能的权值设置是固定的，不会随着节点实际性能的变化而修改权值，但是图2所示的方法可以根据节点的实际负载情况动态修改权值，动态进行请求的分配。

基于以上内容，下面通过另一个实施例进行说明。在该实施例中，分发服务器除可以采用图2所示的负载均衡方法外，还具有动态添加、动态删除与其连接的后端服务器，以及根据后端服务器的负载情况进行后端访问控制等功能。下面分别详细说明。

分发服务器采用路由表维护所有可分配的后端服务器，所述路由表中记录了所有可分配的后端服务器的配置信息，所述配置信息包括服务器的IP地址、端口配置等信息。在每个获取周期内，分发服务器按照所述路由表获取路由表中记录的后端服务器的负载情况，并动态地进行负载调整。

基于所述路由表的维护，分发服务器还具有以下特点：

1、动态删除后端服务器

具体包含以下两个子步骤：

子步骤1，定时获取路由表中后端服务器的运行状态信息；

子步骤2，依据所述运行状态信息检测相应的后端服务器是否异常或失效，并将异常或失效的后端服务器的配置信息从路由表中删除。

所述运行状态信息可以检测出后端服务器是否与分发服务器保持通信，通信状态是否正常，等等。如果某台后端服务器由于各种原因而发生故障(即异常)或完全宕机(即失效)，通过这种定期的检测，就可以立即发现并自动从路由表中删除，避免再将该后端服务器分配给客户端。

上述轮询法虽然也可以通过修改配置的方法删除失效的后端服务器，但是这种修改之后，扩散需要时间，比如后端的一台服务器停机，修改配置使其生效需要一定时间，这段时间可能会把这台失效的服务器继续路由给用户。但是分发服务器采用的这种定期检测、实时删除的方法，可以动态地处理失效的机器。

2、动态添加后端服务器

通过向所述路由表中添加后端服务器的配置信息，可以动态添加可分配的后端服务器。

在后端现有的服务器不能满足处理需要的情况下，可以按照上述方式动态添加新的服务器。这种动态添加的方式也可以立即生效，无需等待一定时间。

3、后端访问控制

可以根据后端机器的实际在线人数、应用程序的下载情况、CPU、内存等负载信息，动态计算并决定是否路由请求给后端服务器，从而有效地保护后端的服务。

这种对后端的访问控制可采用以下两种实现方式：

一种方式是：预先配置后端服务器的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；在每个获取周期内，依据获取的当前负载信息和所配置的最大处理能力，检测后端服务器是否满载，并对满载的后端服务器进行访问控制。

这种方式下，分发服务器每次获取到后端服务器的负载信息后，比较当前的实际在线人数是否超过最大在线人数，如果超过，则表示满载需要进行控制保护，不再给该服务器分配请求。

和/或，比较当前正在下载的应用程序的个数是否超过最大下载个数，如果超过，则需要控制保护。

和/或，比较当前正在下载的应用程序的总下载量是否超过最大下载数据量，如果超过，则需要控制保护。

和/或，比较当前的内存使用信息是否接近或超过最大内存使用信息，如4G的内存当已占用3.7G时表示满载，需要控制保护。

和/或，比较当前的CPU使用信息是否接近或超过最大CPU使用信息，如最大CPU使用率是85％，如果当前CPU使用率为83％则表示满载，需要控制保护。

另一种方式是：每个后端服务器上预先配置了相应的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；每个后端服务器依据当前负载信息和所配置的最大处理能力，定时检测是否满载；分发服务器定时获取后端服务器是否满载，并对满载的后端服务器进行访问控制。

所述第二种方式下，是否满载的判断由后端各台服务器完成，并将判断结果反馈给分发服务器，分发服务器依据是否满载的结果调整访问控制策略。

4、不局限后端服务的类型

分发服务器可以基于Erlang框架创建，Erlang是一种面向并发(ConcurrencyOriented)、面向消息(MessageOriented)的函数式(Functional)编程语言。面向并发说明Erlang支持大规模的并发应用，可以在应用中处理成千上万的并发，而不相互影响。面向消息，是为并发服务。在Erlang的世界里，每个处理都是独立的个体，他们之间的交互仅仅靠消息，因此不会有死锁。

基于Erlang框架特有的灵活性，可以通过编写组件的形式进行扩展，后端可以是任意类型的服务，不局限服务的类型，只要提供负载查询的相关接口，就可以使用该框架做负载均衡。

因此，在分发服务器定时获取后端服务器的当前负载信息之前，还包括以下步骤：

根据后端服务的类型，选择配置相适应的与后端服务器通信的交互协议；

如果后端服务的类型调整，则重新配置相适应的与后端服务器通信的交互协议。

总之，通过动态配置分发(dispatch)服务器与后端服务器通信的交互协议，满足不同类型的后端服务。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请所必需的。

基于上述方法实施例的说明，本申请还提供了相应的应用服务的负载均衡系统实施例。

参照图3所示，是本申请实施例所述一种应用服务的负载均衡系统的结构图。

所述负载均衡系统可设置在分发服务器上实现应用服务的负载均衡，所述负载均衡系统可包含以下模块：

负载查询模块10，用于不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；其中，所述应用程序运行数据是后端服务器的应用程序的运行数据，所述后端服务器为终端应用程序提供网络服务，所述终端应用程序与后端服务器的应用程序对应同一应用服务；

权重计算模块20，用于在每个获取周期内，依据所述当前负载信息重新计算后端服务器的权重；

负载调整模块30，用于依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由。

其中，所述性能数据可包括内存使用信息，和/或，CPU使用信息；所述应用程序运行数据包括实际在线人数，和/或正在下载的应用程序数，和/或正在下载的数据量，和/或实际连接数。

其中，各后端服务器提供监控接口，负载查询模块10可通过所述监控接口定时获取后端服务器的当前负载信息。

所述负载调整模块30可依据每次计算的权重调整后端服务器的分配概率；然后，按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。

上述应用服务的负载均衡系统能够在完成同样功能的多个网络设备之间实现业务量的合理分配，而不至于出现一台设备过忙，其他设备未能充分发挥其作用的情况。

基于图3的实施例，在另一系统实施例中，所述负载均衡系统还可以包括其他模块，具体如下：

可选地，所述负载均衡系统还可以包括以下模块：

负载维护模块，用于通过路由表维护所有可分配的后端服务器，所述路由表中记录了所有可分配的后端服务器的配置信息。

可选地，所述负载均衡系统还可以包括以下模块：

动态删除模块，用于定时获取路由表中后端服务器的运行状态信息；依据所述运行状态信息检测相应的后端服务器是否异常或失效，并将异常或失效的后端服务器的配置信息从路由表中删除。

可选地，所述负载均衡系统还可以包括以下模块：

动态添加模块，用于通过向所述路由表中添加后端服务器的配置信息，动态添加可分配的后端服务器。

可选地，所述负载均衡系统还可以包括以下模块：

第一访问控制模块，用于预先配置后端服务器的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；在每个获取周期内，依据获取的当前负载信息和所配置的最大处理能力，检测后端服务器是否满载，并对满载的后端服务器进行访问控制。

可选地，所述负载均衡系统还可以包括以下模块：

第二访问控制模块，用于每个后端服务器上预先配置相应的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；每个后端服务器依据当前负载信息和所配置的最大处理能力，定时检测是否满载；定时获取后端服务器是否满载，并对满载的后端服务器进行访问控制。

可选地，所述负载均衡系统还可以包括以下模块：

通信配置模块，用于根据后端服务的类型，选择配置相适应的与后端服务器通信的交互协议；如果后端服务的类型调整，则重新配置相适应的与后端服务器通信的交互协议。

对于上述负载均衡系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

而且，上文中的“和/或”表示本文既包含了“和”的关系，也包含了“或”的关系，其中：如果方案A与方案B是“和”的关系，则表示某实施例中可以同时包括方案A和方案B；如果方案A与方案B是“或”的关系，则表示某实施例中可以单独包括方案A，或者单独包括方案B。

以上对本申请所提供的一种应用服务的负载均衡方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

1.一种应用服务的负载均衡方法，其特征在于，包括：

分发服务器不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；其中，所述应用程序运行数据是后端服务器的应用程序的运行数据，所述后端服务器为终端应用程序提供网络服务，所述终端应用程序与后端服务器的应用程序对应同一应用服务；

所述应用程序运行数据包括实际在线人数，和/或正在下载的应用程序数，和/或正在下载的数据量，和/或实际连接数，其中，正在下载的应用程序数包括统计下载列表中当前正在下载的应用程序数，不包括已经下载完毕和下载列表中未开始下载的应用程序数；统计每个正在下载的应用程序的下载数据量，将所述下载数据量累加，得到正在下载的数据量；

在每个获取周期内，依据所述当前负载信息重新计算每台后端服务器的权重；

依据每次计算的每台后端服务器的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由；

通过路由表维护所有可分配的后端服务器，所述路由表中记录了所有可分配的后端服务器的配置信息，其中，配置信息包括服务器的IP地址和端口配置信息；

定时获取路由表中后端服务器的运行状态信息，其中，所述运行状态信息是指检测出后端服务器是否与分发服务器保持通信且通信状态是否正常；

依据所述运行状态信息检测相应的后端服务器是否异常或失效，并将异常或失效的后端服务器的配置信息从路由表中删除；

通过向所述路由表中添加后端服务器的配置信息，动态添加可分配的后端服务器。

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

所述性能数据包括内存使用信息，和/或，CPU使用信息。

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

预先配置后端服务器的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；

在每个获取周期内，依据获取的当前负载信息和所配置的最大处理能力，检测后端服务器是否满载，并对满载的后端服务器进行访问控制。

4.根据权利要求1至2任一所述的方法，其特征在于，还包括：

每个后端服务器上预先配置了相应的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；

每个后端服务器依据当前负载信息和所配置的最大处理能力，定时检测是否满载；

定时获取后端服务器是否满载，并对满载的后端服务器进行访问控制。

5.根据权利要求1至2任一所述的方法，其特征在于，所述定时获取后端服务器的当前负载信息之前，还包括：

根据后端服务的类型，选择配置相适应的与后端服务器通信的交互协议；

如果后端服务的类型调整，则重新配置相适应的与后端服务器通信的交互协议。

6.根据权利要求1所述的方法，其特征在于，所述定时获取后端服务器的当前负载信息，包括：

后端服务器提供监控接口，通过所述监控接口定时获取后端服务器的当前负载信息。

7.根据权利要求1所述的方法，其特征在于，所述依据每次计算的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由，包括：

依据每次计算的权重调整后端服务器的分配概率；

按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。

8.一种应用服务的负载均衡系统，其特征在于，包括：

负载查询模块，用于分发服务器不断获取后端服务器的当前负载信息，所述当前负载信息包括后端服务器的应用程序运行数据，或者包括后端服务器的应用程序运行数据和性能数据；其中，所述应用程序运行数据是后端服务器的应用程序的运行数据，所述后端服务器为终端应用程序提供网络服务，所述终端应用程序与后端服务器的应用程序对应同一应用服务；所述应用程序运行数据包括实际在线人数，和/或正在下载的应用程序数，和/或正在下载的数据量，和/或实际连接数，其中，正在下载的应用程序数包括统计下载列表中正在下载的应用程序数，不包括已经下载完毕和下载列表中未开始下载的应用程序数；统计每个正在下载的应用程序的下载数据量，将所述下载数据量累加，得到正在下载的数据量；

权重计算模块，用于在每个获取周期内，依据所述当前负载信息重新计算每台后端服务器的权重；

负载调整模块，用于依据每次计算的每台后端服务器的权重调整后端服务器的分配，并选择后端服务器将客户端的接入请求进行路由；

负载维护模块，用于通过路由表维护所有可分配的后端服务器，所述路由表中记录了所有可分配的后端服务器的配置信息，其中，配置信息包括服务器的IP地址和端口配置信息；

动态删除模块，用于定时获取路由表中后端服务器的运行状态信息，其中，所述运行状态信息是指检测出后端服务器是否与分发服务器保持通信且通信状态是否正常；依据所述运行状态信息检测相应的后端服务器是否异常或失效，并将异常或失效的后端服务器的配置信息从路由表中删除；

动态添加模块，用于通过向所述路由表中添加后端服务器的配置信息，动态添加可分配的后端服务器。

9.根据权利要求8所述的系统，其特征在于：

所述性能数据包括内存使用信息，和/或，CPU使用信息。

10.根据权利要求8至9任一所述的系统，其特征在于，还包括：

第一访问控制模块，用于预先配置后端服务器的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；在每个获取周期内，依据获取的当前负载信息和所配置的最大处理能力，检测后端服务器是否满载，并对满载的后端服务器进行访问控制。

11.根据权利要求8至9任一所述的系统，其特征在于，还包括：

第二访问控制模块，用于每个后端服务器上预先配置相应的最大处理能力，所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息；每个后端服务器依据当前负载信息和所配置的最大处理能力，定时检测是否满载；定时获取后端服务器是否满载，并对满载的后端服务器进行访问控制。

12.根据权利要求8至9任一所述的系统，其特征在于，还包括：

通信配置模块，用于根据后端服务的类型，选择配置相适应的与后端服务器通信的交互协议；如果后端服务的类型调整，则重新配置相适应的与后端服务器通信的交互协议。