早期的均衡问题解决方案是在应用服务器的操作系统或应用软件中直接部署均衡能力，但是大多数
都涉及到基本的网络欺骗。
 
例如（让集群中的所有服务器监听除自身ip地址之外的" 集群ip"。）用户试图连接服务时，用户会连接到集群ip，而不是服务器的物理ip。集群中最先对连接请求做出 响应的服务器将把用户重定向到物理的ip地址（可以是自己的ip地址，也可以是集群中的另一个） ，服务会话开始启
 
首先这个方案的主要优点是：应用开发人员可以使用大量信息确定客户端连接哪个物理ip地址；举
例（集群中的每台服务器可以维护每个集群成员正在服务的会话数量，并将请求定向到利用率最低
的服务器）；
 
最开始该解决方案的扩展性很明显：但是随着集群成员服务器被添加到集群中的数量越多，集群成
员之间的网络流量就会呈指数级增长。一般集群扩展到10台以后，流量就开始影响最终用户的业务
流量以及服务器本身的利用率。
 
该方案的可用性也显著提高：由于集群成员始终互相通信，而且应用开发人员可以使用综合的应用
知识了解服务器在何时正确的运行，因此几乎不会出现用户到达一个无法处理请求的服务器的情况
；然而必须指出的是，对高可用性的另一个负面影响是可靠性。系统中分配流量的许多网络欺骗方
法非常复杂，要求大量的网络级监控工作；相应的，这些方法经常会遇到影响整个应用以及应用网
络上所有流量的问题。
 

该方案也提高了可预测性：对应用的深入了解，开发人员能够根据应用的真正健康状态更好的开发
负载均衡算法，而不是根据连接。
 

最后给予应用的专用负载均衡软件还有一个缺点：过分的依赖应用供应商提供开发维护，这样的问
题是并非所有应用都提供负载均衡或集群技术，而且提供这些技术的应用无法与其他应用提供商良
好配合。尽管许多企业制作了不依赖供应商的操作系统级别的负载=均衡软件，但他们都遭遇了同
样的扩展性问题！而且由于缺乏与应用的密切集成，这些软件的“解决方案”也遇到了高可用性的
挑战。