在一个复杂的企业应用环境中，往往一个application server无法承担所有的服务请求，所以很多企业都为此架起了多个服务器实例。这些服务器实例结合在一起，可以组织成一个强健的企业运行环境，它易于扩展、支持load banlance, 支持fail over, 可以做到backend server的failure对于客户是透明的。这样的一个企业环境就是我们常说的Cluster。Weblogic Cluster提供了多种load banlance的可能, 比如web application请求处理,可以通过proxy来实现(e.g. apache, HttpClusterServlet, IIS), 不同的J2EE Component在Weblogic有不同的load banlance实现．下面我们来逐一看看，
1: Http请求通过proxy实现的load banlance
当客户端通过proxy访问Cluster中的业务页面时，proxy通过自身的算法(round-robin)来实现load banlance．当然这些请求要求是从不同的客户端(或者不带session的同一客户端的请求)发起的．对于同一客户端，如果页面中使用了 session, 那么Weblogic 通过session粘连来实现同一客户端的请求会被dispatch到primary server上．如果primary server无法提供服务，那么请求会被dispatch到其他server上。session粘连可以通过以下几种方式实现：
1.1：browser支持cookie的话，weblogic会把jsession id写入到cookie中，下次请求提交的时候jseeion id会被提交到proxy端，proxy通过jseeion id 来决定请求的dispatch。
1.2：browser不支持cookie，server端在处理返回页面时，调用response.encodeURL()来将session id附在url上。
1.3：post-data方式，直接将session作为数据，post到proxy端。
我们来看看weblogic提供的HttpClusterServlet是如何实现load banlance的，
public synchronized Server next() {
if (list.size() == 0) return null;
if (index == -1) index = (int)(java.lang.Math.random() * list.size());
else index = ++index % list.size();
Object[] servers = list.values().toArray();
return (Server) servers[index];
}
HttpClusterServlet维护一个managed servlet list，每当一个请求被dispatch到某个managed server后，server list的index加1，这样在下次dispatch请求的时候，请求将会被dispatch到server list中的其他server上去。逻辑很简单，但基本也实现了load banlance功能。
2：InitialContext的load banlance
我们知道，每次我们需要获取jdbc connection， jms connection，ejb stub这类RMI Object的时候，我们都要初始化一个上下文，问题是我们初始化上下文的时候，连接的到底是哪个managed server?
初始化上下文的时候，我们需要提供一个provider url, 如下：
PROVIDER_URL = "t3://localhost:7011";
这种写法很简单，直接连接7001对应的server, 但如果写法如下呢？
CLUSTER_PROVIDER_URL="t3://localhost:7011,localhost:7021";
这时候，load banlance就又来了。10个客户端(weblogic server或者thin client)new 10个InitialContext的话，这10个客户端将55分别连接到后端的两台server上去。实际上客户端在new InitialContext的时候，weblogic会创建一个T3连接到对应的managed server上(RJVMConnection)，注意这个RJVMConnection是个长连接，在同一个JVM中，连向同一managed server的连接只有一个。即如果一个客户端，连续new 10个 InitialContext, 这10个Context实际上是同一对象，weblogic server这时根本不会和后端的server通讯，因为对象已经在client JVM中有了。
new InitialContext的load banlance算法基本和proxy的算法一样，都是维护一个server list, 通过index递增的方法实现。不同的是：在连接某个managed server的connection遇到peer gone的时候， proxy可以recover server list, 而jndi context的load banlance算法则不能。也就是说如果后端有三个managed server， server1， server2相继出现故障的话，所有客户端的context将都会连接到server3, 即使server1, server2能够恢复过来，后续请求也不会连接到他们，除非server3后来出现问题。
值得一提的是：context所有的相关操作时server affinity的，而非load banlance。比如：2个客户端分别new了个context, 分别连接到server1和server2上，连接到server1的context，做了10次lookup，那么这10次操作，都在server1上完成，不会在server2上作任何操作。所以说jndi级别的load banlance不是绝对均衡的。