分布环境下不同层次的负载平衡

基于网络层的负载平衡

基于网络的负载平衡根据站点接收请求的频率作负载决策。 IP 路由器 ^[5] 和域名服务可以为一组主机提供这种类型的负载平衡服务，如图 1.7 所示。

早期的基于网络层的负载平衡技术 利用 DNS 域名服务器作为负载平衡器。在 DNS 中为多个地址配置同一个名字，查询这个名字的客户机将得到其中一个地址，从而使不同的客户可以访问不同的服务器，达到负载平衡的目的。很多知名的 Web 站点都使用了这个技术：包括早期的 yahoo 站点、 163 等。具有代表性的产品是 Cisco 公司的 Distributed Director 。当一个客户解析一台主机时， DNS 可以基于当前的负载情况对每个请求动态地分配一个不同的 IP 地址。客户然后与所分配的后端服务器联系，它并不清楚下次解析是否会选择一个不同的服务器。路由器也可以基于当前负载情况将一个 TCP 流与任意一台后端服务器绑定，在该流的持续期内将一直使用此绑定。这种负载平衡方法虽然实现简单，易于管理，但却不易区分服务器的差异，也不便于反映服务器的当前运行状态。

图 1.7 网络级的负载平衡

现代基于网络的负载平衡技术通常操作于网络的第 4 层或第 7 层。第 4 层负载平衡将一个在 Internet 上合法注册的 IP 地址映射为多个内部服务器的 IP 地址，对每次 TCP 连接请求动态使用其中一个内部 IP 地址，达到负载平衡的目的。在第 4 层交换机中，此种均衡技术得到广泛的应用，很多硬件厂商都将这种技术集成在自己的交换机中 ^[91] 。一个数据包流经这种交换机时，交换机将根据连接请求中的源端 IP 地址和目的端 IP 地址、 TCP 或 UDP 端口号等信息，按照一定的负载平衡算法 ( 随机、轮转、加权轮转、最小连接数、最小响应时间、基于负载的策略等 ) ，在服务器群虚拟 IP 和某个具体的服务器 IP 间进行映射，从而将流量分配到该服务器上。对于用户来说服务器群是透明的，用户并不知道服务器群的存在，对应的服务器群虚拟 IP 即是该站点的接入地址。这种方法通常叫做 NAT （ Network  Address Translation ，网络地址转换 ) 负载平衡。这种技术的典型实现是 Cisco 公司的 Local Director^[6] 。第 7 层负载平衡则控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对 HTTP 服务器群的应用。第 7 层负载平衡技术通过检查流经的 HTTP 报头，根据流经的数据类型 ( 如图像文件、压缩文件或多媒体文件格式等 ) ，把数据流量引向相应内容的服务器来处理，从而提高系统的性能。第 7 层负载平衡一般只支持 HTTP 协议，这样就限制了它的广泛性，并且检查 HTTP 报头会占用大量的系统资源，势必会影响到系统的性能，在大量连接请求的情况下，负载平衡设备自身容易成为网络整体性能的瓶颈。

尽管基于网络的负载平衡在很多的实际工程中都得到了成功的应用 ^， 但是这一方法仍然主要应用于传统的 Web 应用架构中。也就是说，它更加适用于显示静态页面或者是处理简单的逻辑和脚本的 Web 应用。基于网络的负载平衡技术的另一不足在于它主要依赖于请求的目标来进行指派，从而在一定程度上限制了它的灵活性。

基于操作系统层的负载平衡

图 1.8 操作系统级的负载平衡

如图 1.8 ，分布式操作系统通过集群（ clustering ） 、负载共享（与负载平衡不同，例如运行资源可以被处理器共享，但不一定能够被平衡）、进程迁移 和内存导引 （ memory ushering ）等机制提供这种类型的负载平衡。集群是获得高可用性和高性能的一种有效方式，它将许多日常的计算机结合在一起从而提高整体的系统处理能力。进程迁移机制是在进程运行过程中，根据系统的负载情况，将活跃进程从负载较重的结点转移到另一负载较轻的结点继续运行，可以有效的实现负载的动态平衡。由于迁移的对象是活跃进程，因此又称为抢占式 (Preemptive) 进程迁移。迁移是在进程运行时进行的，涉及到进程状态的转移，因此实现的代价相对较大。

支持抢占式进程迁移技术的集群系统有：耶路撒冷的 Hebrew 大学开发的 MOSIX 系统、 Wisconsin 大学研制的 Condor 系统、美国加州大学伯克莱分校的 Sprite 系统等 。一些分布式操作系统和工具，例如 Chorus 和 GNU Queue ，也可以透明地实现进程迁移，用户并不知道进程是在远程的处理结点上被执行的。支持非抢占式进程迁移的系统有 Carnegie-Mellon 大学的 Andrew 分布式系统中的 Butler 系统， Xerox PARC 研制的 Cedar 系统的进程服务员，加拿大 Victoria 大学研究的 REM 远程执行系统和 Ohio 州立大学的 Stealth 分布程序调度系统

使用进程迁移，过载的任务和进程可以转移到负载较轻的结点上，从而减少执行时间。然而，在处理器或网络结点之间平衡负载需要传送进程状态，这需要有力的平台支持，以处理结点间平台的差异。同时，当一个进程迁移到一个新结点时，原来使用的资源也许不可获得。通过与原结点联系可以解决这个问题，但频繁的远程调用也许会阻塞网络，因此并不太适用于大型网络。

在操作系统层次上实现负载平衡的优点在于可以对应用程序透明。但是和基于网络的负载平衡一样，不能灵活地选择负载度量，不能利用请求的内容。同时由于应用层的负载衡量尺度和策略很难在操作系统层面上得到，这就很难选择迁移进程的尺度，对于某些分布式应用来说，操作系统级的负载平衡粒度过粗，被平衡的是服务器进程，而不是内部的服务对象本身。同时，当进程状态需要在结点之间进行转移时，系统平台还要提供某种支持来处理结点间的异构性。

基于应用层的负载平衡

这种层次的负载平衡完全由应用程序本身来执行负载平衡，需要修改应用本身来支持负载平衡，增加了代码开发和应用维护的复杂度。同时，基于应用层的负载平衡机制需要在应用部署阶段确定，仅仅提供支持特定应用所需的功能，只能用于特定的环境和用例。这将导致在将其应用于其它应用时将非常困难，从而带来了很大的局限性。这种一般性的缺乏将导致应用相关的负载平衡服务的重新开发。除了将导致分布式应用部署和开发代价的增加外，也会增加获得非优化负载平衡结果的可能性的增加，因为被测试和证明过的优化不能被直接再次使用。

总的来说，基于应用的负载平衡与应用核心紧密结合，主要针对某种特定类型的应用起作用，当应用升级和更新时，则缺乏必要的应对机制，从而一般不具有通用性，可重用性较差，实现和维护代价比较高。

基于中间件层的负载平衡

中间件 是位于操作系统和应用程序之间的通用服务，它的主要作用是屏蔽网络硬件平台的差异性和操作系统与网络协议的异构性，使应用软件能够比较平滑地运行于不同平台上。因此基于中间件的负载平衡技术与基于网络、基于操作系统以及基于应用层的负载平衡技术相比，就显示出它在整合异构系统、透明访问和扩展能力等方面的优势。中间件为负载平衡提供了相应的接口，可以让平衡过程对客户端和服务器端尽量的透明。基于中间件的负载平衡可以支持多种负载平衡算法，来满足不同应用的负载平衡需求，提高了系统的可扩展性，并且能够根据系统状态的变化作出调整来适应这种变化。

基于网络和基于操作系统的负载平衡体系结构缺少灵活性和适应性。缺少灵活性，是指在做负载平衡决策时不支持应用定义的负载度量方法。缺少适应性，是因为缺少来自副本的负载反馈，对副本的负载难以有效地控制。基于网络和操作系统的负载平衡方案都不能提供一种直接有效而又可移植的方式，根据应用级请求特征（如内容、持续时间）来实现负载平衡。在需要根据运行时负载条件动态调节的应用中，它们是不适合的。

图 1.9 基于中间件层的负载平衡

相反，基于中间件的负载平衡在多方面优于以上层次的负载平衡。如图 1.9 ，这种类型的负载平衡通常以负载平衡服务的方式提供，在中间件内部执行，在负载决策、适应不同应用需求方面具有更大灵活性。此外，基于中间件的负载平衡可以与基于网络和基于操作系统的负载平衡机制结合使用，具有很好的灵活性。例如，如果应用程序仅仅要求基于请求频率的负载平衡，那么基于中间件的负载平衡器就可以将这些任务委派给网络或操作系统层。另外一种可能是，基于中间件的负载平衡器本身可以在网络层或操作系统层被负载平衡，那么系统中的网络或主机资源就可以被中间件和其它应用程序所使用。

当前， CORBA 已经成为分布式应用程序开发和系统集成的主流技术之一。 CORBA 针对分布式系统内在的分布性和通常的异构性，提供了一种不依赖于编程语言、计算平台、网络协议的通信基础设施，使得客户和服务器可以使用不同的编程语言编写并运行在不同的硬件和软件平台上。而且它通过高级的编程抽象，为应用开发者屏蔽了分布复杂性，减少了开发代价。

基于中间件、尤其是基于标准 CORBA 的负载平衡体系结构具有以下优点：

1.        可以与基于网络或操作系统的负载平衡机制结合使用

2.        可以应用在现有网络和操作系统之上，对各类应用提供通用的负载平衡支撑服务，减少成本

3.        可以根据应用相关的各种负载平衡条件执行负载平衡，如 I/O 和 CPU 开销。