的通信负载，根据实时响应时间进行判断，将任务交由负载最轻的服务器来处理，以实现真正的智能通信管理和最佳的服务性能。目前，负载均衡技术面临三大问题：服务器的负载状况的评价、如何获取以及获取后如何处理[3]。

2.1 负载状况

2.1.1 负载状况的评价

负载状况的评价由三类组成：静态的、统计类的和动态的。静态的由资源决定，可以数字化评价；统计类的只能作为网站扩充的依据；动态地使用探测结果来评价。

2.1.2 负载状况的获取

由于系统中各服务器根据所有服务器的负载情况来决定新的用户访问请求的取舍，因此，各服务器必须知道其他服务器的负载状况，这要求每个服务器必须将自己的当前负载及时通知其他服务器。探知负载状况的技术主要有3种：

1) 利用agent技术使用网管协议SNMP：在需要的服务器上运行设计的agent，定时通知分配器，从而得

到服务器的确切情况。

2) 第三方的软件：有一些第三方开发的软件可以完成这种工作，需要分配器有相应的接口，从而可以

调整分配的结果。

3) 自己开发软件去主动获取：最简单的集成方法就是自己去开发，由分配器去探测服务器的负载状况。

2.2 负载均衡技术

根据实现层次不同，可将负载均衡技术分为如下几类：

2.2.1 基于客户端的负载均衡

这种模式需要每个客户程序均具备一定的服务器集群知识，在客户端运行特定的程序，该程序通过定期或不定期的收集服务器群的运行参数：CPU占用情况、磁盘IO、内存等动态信息，再根据某种选择策略，找到可以提供服务的最佳服务器，将本地的应用请求发向它。整个过程对于应用程序来说是完全透明的，所有的工作都在运行时处理。比如，在Berkeley研究的smart client中，服务提供一个JavaApplet在客户方浏览器中运行，Applet向各个服务器发请求来收集服务器的负载等信息，再根据这些信息将客户的请求发到相应的服务器；当服务器没有响应时，Applet向另一个服务器转发请求，实现高可用性。

这种技术存在明显的通用性问题，因为每一个客户端都要安装这个特殊的程序；并且，为了保证应用层的透明运行，需要针对每一个应用程序加以修改，要对代码进行重新开发，工作量比较大，因而这种技术仅适用于特殊的应用场合。

2.2.2 应用服务器的负载均衡

如果将客户端的负载均衡层移植到某一个中间平台，形成三层结构，则客户端应用可以不需要做特殊的修改，透明的通过中间层应用服务器将请求均衡到相应的服务结点。比较常见的实现手段就是反向代理技术。通过反向代理服务器，可以将请求按一定的策略转发给多台服务器，或者可以直接将缓存的数据返回客户端，这样的加速模式在一定程度上可以提升客户端的访问速度，从而达到负载均衡的目的，目前广泛采用的有HTTP 反向代理技术。

然而，反向代理技术必须为每一种服务都专门开发一个反向代理服务器，这样就限制了反向代理负载均衡技术的应用范围，现在一般都用于对Web服务器的负载均衡；随着并发连接数量的增加，代理服务器本身的负载也会变得非常大，最后反向代理服务器本身会成为服务的瓶颈。

2.2.3 基于DNS域名系统的负载均衡

最早的负载均衡技术是通过DNS轮循来实现的，DNS负载均衡技术是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP 地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。其中最为著名的是NCSA Web服务器。