CN103997526A - 一种可扩展负载均衡系统和方法 - Google Patents

Abstract

本发明提供一种可扩展负载均衡系统，包括负载均衡服务器和与所述负载均衡服务器互联的多个应用服务器，所述负载均衡服务器用于接收业务请求并提取业务请求所对应的应用标识，根据当前的应用标识到应用服务器的映射表将业务请求转发到相应的应用服务器，同时接收应用服务器反馈的资源使用信息并更新所述应用标识到应用服务器的映射表；所述应用服务器则用于接收和处理从负载均衡服务器转发而来的业务请求，以及实时收集本应用服务器的资源使用信息，并将其反馈到负载均衡服务器。本发明能够支持细粒度的资源调度，有助于充分利用各服务器的处理能力。

Description

一种可扩展负载均衡系统和方法

技术领域

本发明涉及移动互联网和云计算平台技术领域，具体地说，本发明涉及一种可扩展负载均衡系统和方法。

背景技术

目前，随着业务量的提高，WEB访问量和数据流量的快速增长，移动互联网络和云计算网络的各个核心部分所需的处理能力和计算强度也相应地增大，使得单一的服务器设备难以承担这种不断增长的任务需求。在此情况下，如果扔掉现有设备去做大量的硬件升级，将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。而网络负载均衡技术提供了一种廉价、有效、和透明的方法来扩展网络设备和服务器的带宽、增加吞吐量和加强网络数据处理能力，从而提高整个网络的灵活性和可用性。

传统负载均衡技术包含两个方面的含义：一方面，是将单个重负载任务分担到多个节点设备上做并行处理，结束后，再将结果汇总，返回给用户；另一方面，是将大量的并发访问或数据流量分担到多台节点设备上分别处理，以减少用户等待响应的时间。后者主要针对Web服务器、FTP服务器、企业关键应用服务器等网络应用。

图1示出了一个典型的传统负载均衡方案的架构图。以常见的HTTP请求为例，业务处理的最前端是反向代理服务器。反向代理服务器将请求转发到适当的服务器，如邮件服务器、Web服务器以及流媒体服务器等。在这种方案中，每一台服务器只提供相对固定的服务，例如，图1中Web服务器1只负责处理站点1的请求，Web服务器2只负责处理站点B的请求。

在移动互联网或云计算环境下，前端系统往往需要响应海量的小应用请求，这些应用在不同时期的访问量不同，甚至在同一天的不同时间段也具有不同的访问量。而现有的负载均衡方案使用应用服务器为单元进行资源调度，且每台应用服务器只能运行相对固定的应用，这种负载均衡方案应用到移动互联网或云计算环境下时，显然无法充分利用各服务器的处理能力。

发明内容

因此，本发明的目的是克服现有技术的不足，提供一种能够充分利用各服务器的处理能力的负载均衡解决方案。

本发明提供了一种可扩展负载均衡系统，包括负载均衡服务器和与所述负载均衡服务器互联的多个应用服务器，所述负载均衡服务器用于接收业务请求并提取业务请求所对应的应用标识，根据当前的应用标识到应用服务器的映射表将业务请求转发到相应的应用服务器，同时接收应用服务器反馈的资源使用信息并更新所述应用标识到应用服务器的映射表；所述应用服务器则用于接收和处理从负载均衡服务器转发而来的业务请求，以及实时收集本应用服务器的资源使用信息，并将其反馈到负载均衡服务器。

其中，所述负载均衡服务器还用于根据各应用服务器的资源使用信息，向各应用服务器发出迁移应用的指令，所述应用服务器还用于接收负载均衡服务器的迁移应用的指令，终止正在运行的应用程序或者启动并初始化新的应用程序。

其中，所述业务请求为HTTP请求，所述负载均衡服务器从所述HTTP请求的独立域名、子域名或者子目录中提取相应的应用标识。

本发明还提供了一种基于上述可扩展负载均衡系统的负载均衡方法，包括下列步骤：

1)负载均衡服务器接收业务请求并提取业务请求所对应的应用标识，根据当前的应用标识到应用服务器的映射表将业务请求转发到相应的应用服务器；

2)应用服务器接收和处理从负载均衡服务器转发而来的业务请求；

3)应用服务器实时收集本应用服务器的资源使用信息并将其反馈到负载均衡服务器；

4)负载均衡服务器接收应用服务器反馈的资源使用信息并更新所述应用标识到应用服务器的映射表。

其中，所述步骤1)还包括：负载均衡服务器根据当前的应用标识到应用服务器的映射表中的各应用服务器对于相应应用标识的权重值，利用加权轮询算法将业务请求转发到应用服务器；所述步骤4)还包括，负载均衡服务器根据应用服务器反馈的资源使用信息，在应用标识到应用服务器的映射表中赋予或更新各应用服务器对于相应应用标识的权重值。

其中，所述负载均衡方法还包括步骤：

5)当一个应用服务器A的资源使用率超过预先设定的上限时，负载均衡服务器将该应用服务器A正在运行的一个或多个应用迁移到其它空闲的应用服务器上，以使各应用服务器负载的资源使用率保持在预先设定的平衡值附近。

其中，所述步骤5)中，所述空闲的应用服务器是当前负载值小于平衡值的应用服务器。

其中，所述负载均衡方法还包括步骤：

6)当一个应用服务器B的资源使用率低于预先设定的下限时，负载均衡服务器将该应用服务器B正在运行的所有应用迁移到其它空闲的应用服务器上，然后使所述应用服务器B休眠。

其中，对于某一待迁移应用，优选已运行该应用且服务器负载小于平衡值的其它应用服务器作为迁移目标，当已运行该应用的其它应用服务器的负载均超过平衡值时，选择未运行该待迁移应用、且其服务器负载小于平衡值的应用服务器作为迁移目标。

与现有技术相比，本发明具有下列技术效果：

1、本发明能够支持细粒度的资源调度，有助于充分利用各服务器的处理能力。

2、本发明能够在不降低服务质量的前提下，最大化利用应用服务器的处理能力。

3、本发明能够在不降低服务质量的前提下，自动调整活跃的应用服务器的数量,使得活跃的应用服务器的数量最少。

4、本发明特别适合于支持移动互联网或云计算环境下的海量应用部署。

附图说明

以下，结合附图来详细说明本发明的实施例，其中：

图1示出了一种典型的传统负载均衡方案的架构图；

图2示出了本发明一个实施例的负载均衡系统的构架图；

图3示出了本发明一个实施例中从HTTP请求中提取应用ID的流程图；

图4示出了本发明一个实施例的负载均衡系统的一个前端处理时序图；

图5示出了本发明一个实施例的负载均衡系统的另一个前端处理时序图；

图6示出了本发明一个实施例中的资源分裂操作的流程图；

图7示出了本发明一个实施例中的资源合并操作的流程图。

具体实施方式

图2示出了本发明一个实施例的负载均衡系统的构架图，该负载均衡系统包括负载均衡服务器和与所述负载均衡服务器互联的多个应用服务器(应用服务器可以为大于1的任意数目),应用服务器还可以与数据库服务器连接，以用于处理某些需要数据库支持的业务请求。其中，负载均衡服务器主要负责提取出业务请求所对应的应用ID，并将业务请求转发到相应的应用服务器，同时接收应用服务器提交的资源使用反馈信息，根据应用服务器的资源使用反馈信息，动态调整转发策略；资源使用反馈信息包括：处理器、内存的使用率。应用服务器则负责接收从负载均衡服务器转发而来的业务请求，将业务请求转发到相应的应用进程或者线程，并将响应信息直接返回到客户端，同时，实时收集本应用服务器的资源使用信息，并将资源使用信息反馈到负载均衡服务器以便进行资源调度，应用服务器还可接收负载均衡服务器的指令，终止正在运行的应用程序或者启动并初始化新的应用程序。

为叙述方便，下文以HTTP请求为例进行说明，但本领域技术人员易于理解，相应处理步骤和策略均不限于该实例中所描述的网络协议。本实施例的负载均衡系统不仅可应用于基于HTTP协议的WEB服务，也适用于FTP、流媒体、Email等网络业务。只要业务请求当中包含主机、域名信息，且应用服务器支持负载信息反馈和进程管理，原则上便可加入本实施例的负载均衡系统，因此本发明具有很强的可扩展性。

参考图2，负载均衡系统包括负载均衡服务器S₀、应用服务器Sv1～Sv4，应用服务器Sv1～Sv4与两台数据库服务器连接。每一台应用服务器上各个应用的资源使用信息可反馈到负载均衡服务器S₀，负载均衡服务器S₀根据应用服务器的反馈信息维护应用ID到应用服务器的映射表，映射表中记录应用ID及其对应的应用服务器的MAC地址，表1是一个具体的应用ID到应用服务器的映射表的示例。需要说明的是，一个应用ID可以对应多个应用服务器。当收到用户的业务请求时，负载均衡服务器S₀当前的应用ID到应用服务器的映射表调整转发策略，从而将业务请求转发至合适的应用服务器。进一步地，负载均衡服务器S₀还可以根据应用ID到应用服务器的映射表，动态调整各应用服务器上所运行的应用，将应用在不同的应用服务器上迁移，从而实现负载均衡。更进一步地，负载均衡服务器S₀还可以根据应用ID到应用服务器的映射表，将资源使用率低于预定下限值的应用服务器休眠，从而节省资源和能耗。

表1

根据本发明的一个实施例，负载均衡系统对业务请求的前端处理流程包括：当负载均衡服务器S₀接收到客户端的业务请求时，从业务请求中提取应用ID，然后在应用ID到应用服务器的映射表中查找相应的MAC地址。由于一个应用可以在多台应用服务器上运行多个实例，所以，可能查到多个MAC地址。如果S₀查找到至少一个MAC地址，则在查找到的MAC地址中，使用加权轮询算法，选择目的MAC地址，并将业务请求转发到相应的应用服务器。相应的应用服务器将业务请求转发到该服务器内部相应的应用进程或线程。应用进程或者线程处理该业务请求，将业务响应信息直接返回到客户端。图4示出本实施例中HTTP请求的标准处理流程(即非初次处理流程)。如果应用ID到应用服务器的映射表中未查找到所提取的应用ID，则当前业务请求为初次业务请求，负载均衡服务器S₀选择一台空闲的应用服务器，运行该应用ID所对应的应用程序。同时发送启动和初始化应用并包含应用ID的指令到应用服务器，应用服务器根据应用ID，启动和初始化相应的应用程序后返回MAC地址。负载均衡服务器将应用ID映射到返回的MAC地址。应用服务器则处理该业务请求，将业务响应信息直接返回到客户端。图5示出了本实施例中HTTP请求的初次处理流程。

上述实施例的负载均衡系统对应于网络平台层次结构中的应用层负载均衡，通过使用应用请求的URL、应用会话等信息来路由用户请求，以提升系统的可用性和可扩展性，通过重用现有运行环境和已存在的会话来避免初始化执行所带来的开销，提高系统的响应速度。

根据本发明的一个实施例，对于HTTP请求，其应用ID信息通过该HTTP请求的Host头部或者请求路径携带。具体地，HTTP请求可通过以下3种方式来携带应用ID信息：

1)独立域名方式，即该应用对应的域名与系统的域名无关。系统保存独立域名到应用ID的映射，如表2所示，直接根据独立域名查找对应的应用ID。如果HTTP请求采用独立域名，则需在HTTP请求头部Host中指出该独立域名。

表2

2)子域名方式，如果将系统的域名记为www.xxx.com，那么应用对应的子域名是{appId}.xxx.com。根据子域名，可以直接获得该应用对应的应用ID。如果HTTP请求采用子域名，则需在HTTP请求头部Host中指出该子域名。

3)子目录方式，如果将系统的域名记为www.xxx.com，将系统的根目录记为/，那么应用对应的子目录是www.xxx.com/{appId}。根据子目录，可以直接获得该应用对应的应用ID。如果HTTP请求采用子目录，则无需指定HTTP请求头部Host。

图3示出了在HTTP请求中提取应用ID的流程，包括下列步骤：

1、检查该HTTP请求包含的请求头部。

2、判断是否包含有Host头部，如果是，进入步骤3，如果否，进入步骤10。

3、判断是否包含主机域名信息，如果是，进入步骤4，如果否，进入步骤10。

4、提取该Host头部中的域名信息，继续执行步骤5。

5、判断该域名后缀是否为系统域名，如果是，进入步骤6，如果否，进入步骤8。

6、提取该域名的前缀，该前缀为应用ID，继续执行步骤7。

7、返回应用ID。

8、该域名为独立域名，从独立域名到应用ID的映射表中查找；继续执行步骤9。

9、判断是否查找到应用ID。

10、提取该HTTP请求中的路径信息，该路径的第一层子目录为应用ID，然后执行步骤7。

根据本发明的另一个实施例，还提供了一种上述负载均衡系统的负载均衡方法，以使各应用服务器负载保持在平衡值附近。该负载均衡方法包括：资源分裂和资源合并。表3示出了资源属性与操作方法定义。

表3

容量(Capacity)	应用服务器资源使用率的最大值
		上限(Ceiling)	上限小于容量，当应用服务器资源使用率达到上限时，会触发分裂的操作
下限(Floor)	下限大于0，当应用服务器资源使用率达到下限时，会触发合并的操作
		负载(Load)	应用服务器资源的当前使用率
平衡值(Balance Value)	应用服务器资源的最佳使用率
		分配操作	在具有空闲资源的应用服务器上启动并初始化新的应用
释放操作	停止应用服务器上的一个应用，释放该应用占用的资源

当某一应用服务器负载超过上限时，系统进行资源分裂操作调度。分裂操作的处理流程如图6所示，如果服务器中所有应用的负载均小于服务器负载与平衡值之差，则选取负载最小的应用，并将该应用转移到其他应用服务器上，然后重新执行资源分裂算法。参考图2的构架，假定Sv1的资源使用超过了上限Ceiling，如果Sv1中所有应用的负载均小于其负载与最佳平衡值BV之差，则选取负载最小的应用，并将其转移到其他应用服务器如Sv2上。

如果应用服务器中存在负载大于应用服务器负载与平衡值之差的应用，那么执行以下的步骤：

1)选择该应用服务器上负载最大的应用，记该应用的负载为L_a1，该应用服务器的负载为L₁；

2)查看该应用在其他应用服务器上的负载，记为L_a1，L_a1，……L_an，相应的应用服务器的负载为L₁，L₂，……L_n；

3)计算超额的负载，计算公式为其中BV表示应用服务器的平衡值；

4)如果超额的负载L_diff小于0，则直接执行步骤7)，否则，执行步骤5)；

5)选取负载小于平衡值的应用服务器，使得其空闲资源(指相对于平衡值的空闲资源)的总和不小于L_diff，记这些应用服务器的负载为K₁，K₂，……K_m，则 ${\mathrm{\&Sigma;}}_{i=1}^{m-1}{K}_i<L_{\mathrm{diff}}\&le;{\mathrm{\&Sigma;}}_{i=1}^m{K}_i;$

6)在新选取的应用服务器中，启动并初始化该应用的新的实例，并将MAC地址返回到负载均衡服务器中；

7)在负载均衡服务器中加入应用ID和新选取的应用服务器MAC地址的映射，并修改这些应用服务器针对该应用ID的权重值，使得这些权重值的比值等于：

(BV-L₁+L_al):(BV-L₂+L_a2)：......：(BV-L_n+L_an):(BV-K₁):(BV-K₂):......(BV-K_m)

其中，BV-L_i+L_ai代表第i个正在运行所述应用(即执行分裂操作应用服务器中的负载最大的应用，亦即本次被迁移的应用)的权重值，i＝1、2、…、n；BV-K_j代表第j个未运行所述应用(即执行分裂操作应用服务器中的负载最大的应用，亦即本次被迁移的应用)的应用服务器的权重值，j＝1、2、…、m。这些权重值记录在负载均衡服务器的应用ID到应用服务器的映射表中，以便于负载均衡服务器根据应用ID来执行加权负载均衡算法，从而使各应用服务器的任务保持均衡。

为更加便于理解，下面对照图2的系统构架做进一步描述。如果Sv1中存在负载大于Sv1负载与BV之差的应用，那么选择Sv1中负载最大的应用，记为L_a1，Sv1的负载为L₁，并查看该应用在Sv2～Sv4上的负载，其中Sv2～Sv3上已运行该应用，该应用的负载分别记为L_a2，L_a3，相应的服务器负载为L₂，L₃，Sv4上未运行该应用，相应的服务器负载为K₁。

计算的值，如果该值小于0，则在S₀中加入应用ID和新选取的应用服务器MAC地址的映射，并修改这些应用服务器的权重值，使得这些权重值的比值等于：

(BV-L₁+L_a1):(BV-L₂+L_a2):(BV-L₃+L_a3):(BV-K₁)     (a)

它们依次代表所述应用(本次被迁移的应用)对于Sv1、Sv2、Sv3、Sv4的权重值。

如果的值大于等于0，则选取负载小于BV的应用服务器如Sv2、Sv3，使得其空闲资源的总和不小于记这两个服务器的负载为K2、K3，在Sv2和Sv3中，启动并初始化该应用的新的实例，同时将MAC地址返回S₀中，并按前述(a)式修改这些应用服务器的权重值。

另一方面，当应用服务器的负载低于下限时，系统触发资源合并操作，如果该应用服务器上的应用数目大于0，则将这些应用迁移到其它应用服务器上，对于某一待迁移应用，优选已运行该应用且服务器负载小于平衡值BV的其它应用服务器作为迁移目标，当已运行该应用的其它应用服务器的负载均超过平衡值BV时，选择一个未运行该待迁移应用，并且其服务器负载小于平衡值BV的应用服务器作为迁移目标。负载低于下限的应用服务器上所有的应用均被迁移后，使该应用服务器进而休眠状态。

进一步地，在一个优选实施例中，资源合并操作的处理流程如图7所示，包括下列步骤：

1)将应用服务器的负载低于下限的应用服务器作为需要启动资源合并操作的当前应用服务器，任意选择当前应用服务器上的一个应用作为待迁移应用，记该待迁移应用在当前应用服务器的负载为L_r0。

2)查看该待迁移应用在编号为i的其它应用服务器上的负载，记为L_r[i]，相应地，编号为i的应用服务器的总负载为L[i]，i＝1,2,…,n。

3)对数组L_r从小到大排序，基于数组L_r的排序，调整数组L中相应元素的位置，使数组L_r和数组L中，应用服务器编号i所对应元素所处的位置完全一致，下文中将i称为数组中元素的下标，将数组L_r和数组L中位置相同的元素称为互相对应的元素。

4)如果数组L中的元素L[i]大于BV，则将相应的编号为i的应用服务器的待迁移应用的负载暂时转移到当前应用服务器，此时进行如下赋值：L_r0＝L_r0+L_r[i]，L[i]＝L[i]-L_r[i]，L_r[i]＝0，i为相应元素下标。

本步骤可以将负载超过BV的应用服务器上的待迁移应用的负载分摊到其它服务器上。

5)如果数组L中存在小于BV的元素且L_r0大于0，执行步骤6)；否则，跳至步骤8)。

6)取数组L_r中最小的元素，且该元素对应的数组L中的元素小于BV，记元素大小为mv，假设有m个这样的元素，记下标集合为S；取数组L_r中第二小的元素，且该元素对应的数组L中的元素小于BV，记元素大小为smv；记inc＝min(smv-mv,L_r0/m)；

7)对于S中的每一个下标i，执行如下操作：

L_r0＝L_r0－inc；

L[i]＝L[i]+inc；

L_r[i]＝L_r[i]+inc；

如果L[i]>BV则：

L_r0＝L_r0+(L[i]－BV)；

L_r[i]＝L_r[i]－(L[i]－BV)；

L[i]＝BV。

跳转到步骤5)。

8)如果L_r0大于0，则执行步骤9)；否则，直接执行步骤11)。

9)选取负载小于平衡值的其它未运行待迁移应用的应用服务器，使得这些应用服务器空闲资源的总和不小于L_r0。记这些应用服务器的负载为K₁，K₂，……K_m，则

10)在新选取的应用服务器中，初始化该应用的新的实例，并将MAC地址返回到负载均衡服务器，停止数组L_r中值为0的元素对应的应用。

11)在负载均衡服务器中加入应用ID和新选取的应用服务器MAC地址的映射，删除应用ID到停止的应用所在的应用服务器的MAC地址的映射，并修改运行待迁移应用的所有应用服务器的权重值，使得这些权重值的比值等于：

L_r[1]:L_r[2]:......:L_r[n]:(BV-K₁):(BV-K₂):......(BV-K_m)；

12)在当前应用服务器上停止待迁移应用，按照前面所计算的分摊待迁移应用后的负载，将待迁移应用迁移至各个相关的应用服务器。

如果执行上述步骤1)至12)后，当前应用服务器上的应用数目仍然大于0，则选择下一个待迁移应用，重新执行步骤1)至12)，直到当前应用服务器上所有的应用均迁移完毕。

最后应说明的是，以上实施例仅用以描述本发明的技术方案而不是对本技术方法进行限制，本发明在应用上可以延伸为其它的修改、变化、应用和实施例，并且因此认为所有这样的修改、变化、应用、实施例都在本发明的精神和教导范围内。

Claims (9)

1.一种可扩展负载均衡系统，包括负载均衡服务器和与所述负载均衡服务器互联的多个应用服务器，所述负载均衡服务器用于接收业务请求并提取业务请求所对应的应用标识，根据当前的应用标识到应用服务器的映射表将业务请求转发到相应的应用服务器，同时接收应用服务器反馈的资源使用信息并更新所述应用标识到应用服务器的映射表；所述应用服务器则用于接收和处理从负载均衡服务器转发而来的业务请求，以及实时收集本应用服务器的资源使用信息，并将其反馈到负载均衡服务器。

2.根据权利要求1所述的可扩展负载均衡系统，其特征在于，所述负载均衡服务器还用于根据各应用服务器的资源使用信息，向各应用服务器发出迁移应用的指令，所述应用服务器还用于接收负载均衡服务器的迁移应用的指令，终止正在运行的应用程序或者启动并初始化新的应用程序。

3.根据权利要求1或2所述的可扩展负载均衡系统，其特征在于，所述业务请求为HTTP请求，所述负载均衡服务器从所述HTTP请求的独立域名、子域名或者子目录中提取相应的应用标识。

4.一种基于权利要求1所述的可扩展负载均衡系统的负载均衡方法，包括下列步骤：

1)负载均衡服务器接收业务请求并提取业务请求所对应的应用标识，根据当前的应用标识到应用服务器的映射表将业务请求转发到相应的应用服务器；

2)应用服务器接收和处理从负载均衡服务器转发而来的业务请求；

3)应用服务器实时收集本应用服务器的资源使用信息并将其反馈到负载均衡服务器；

4)负载均衡服务器接收应用服务器反馈的资源使用信息并更新所述应用标识到应用服务器的映射表。

5.根据权利要求4所述的负载均衡方法，其特征在于，所述步骤1)还包括：负载均衡服务器根据当前的应用标识到应用服务器的映射表中的各应用服务器对于相应应用标识的权重值，利用加权轮询算法将业务请求转发到应用服务器；所述步骤4)还包括，负载均衡服务器根据应用服务器反馈的资源使用信息，在应用标识到应用服务器的映射表中赋予或更新各应用服务器对于相应应用标识的权重值。

6.根据权利要求4所述的负载均衡方法，其特征在于，还包括步骤：

5)当一个应用服务器A的资源使用率超过预先设定的上限时，负载均衡服务器将该应用服务器A正在运行的一个或多个应用迁移到其它空闲的应用服务器上，以使各应用服务器负载的资源使用率保持在预先设定的平衡值附近。

7.根据权利要求5所述的负载均衡方法，其特征在于，所述步骤5)中，所述空闲的应用服务器是当前负载值小于平衡值的应用服务器。

8.根据权利要求6或7所述的负载均衡方法，其特征在于，还包括步骤：

6)当一个应用服务器B的资源使用率低于预先设定的下限时，负载均衡服务器将该应用服务器B正在运行的所有应用迁移到其它空闲的应用服务器上，然后使所述应用服务器B休眠。

9.根据权利要求8所述的负载均衡方法，其特征在于，对于某一待迁移应用，优选已运行该应用且服务器负载小于平衡值的其它应用服务器作为迁移目标，当已运行该应用的其它应用服务器的负载均超过平衡值时，选择未运行该待迁移应用、且其服务器负载小于平衡值的应用服务器作为迁移目标。