在一個(gè)復(fù)雜的企業(yè)應(yīng)用環(huán)境中，往往一個(gè)application server無法承擔(dān)所有的服務(wù)請(qǐng)求，所以很多企業(yè)都為此架起了多個(gè)服務(wù)器實(shí)例。這些服務(wù)器實(shí)例結(jié)合在一起，可以組織成一個(gè)強(qiáng)健的企業(yè)運(yùn)行環(huán)境，它易于擴(kuò)展、支持load banlance, 支持fail over, 可以做到backend server的failure對(duì)于客戶是透明的。這樣的一個(gè)企業(yè)環(huán)境就是我們常說的Cluster。Weblogic Cluster提供了多種load banlance的可能, 比如web application請(qǐng)求處理,可以通過proxy來實(shí)現(xiàn)(e.g. apache, HttpClusterServlet, IIS), 不同的J2EE Component在Weblogic有不同的load banlance實(shí)現(xiàn)．下面我們來逐一看看，

        1: Http請(qǐng)求通過proxy實(shí)現(xiàn)的load banlance

        當(dāng)客戶端通過proxy訪問Cluster中的業(yè)務(wù)頁面時(shí)，proxy通過自身的算法(round-robin)來實(shí)現(xiàn)load banlance．當(dāng)然這些請(qǐng)求要求是從不同的客戶端(或者不帶session的同一客戶端的請(qǐng)求)發(fā)起的．對(duì)于同一客戶端，如果頁面中使用了session, 那么Weblogic 通過session粘連來實(shí)現(xiàn)同一客戶端的請(qǐng)求會(huì)被dispatch到primary server上．如果primary server無法提供服務(wù)，那么請(qǐng)求會(huì)被dispatch到其他server上。session粘連可以通過以下幾種方式實(shí)現(xiàn)：
        1.1：browser支持cookie的話，weblogic會(huì)把jsession id寫入到cookie中，下次請(qǐng)求提交的時(shí)候jseeion id會(huì)被提交到proxy端，proxy通過jseeion id 來決定請(qǐng)求的dispatch。
        1.2：browser不支持cookie，server端在處理返回頁面時(shí)，調(diào)用response.encodeURL()來將session id附在url上。
        1.3：post-data方式，直接將session作為數(shù)據(jù)，post到proxy端。
        我們來看看weblogic提供的HttpClusterServlet是如何實(shí)現(xiàn)load banlance的，
        HttpClusterServlet維護(hù)一個(gè)managed servlet list，每當(dāng)一個(gè)請(qǐng)求被dispatch到某個(gè)managed server后，server list的index加1，這樣在下次dispatch請(qǐng)求的時(shí)候，請(qǐng)求將會(huì)被dispatch到server list中的其他server上去。邏輯很簡(jiǎn)單，但基本也實(shí)現(xiàn)了load banlance功能。

        2：InitialContext的load banlance
        
        我們知道，每次我們需要獲取jdbc connection， jms connection，ejb stub這類RMI Object的時(shí)候，我們都要初始化一個(gè)上下文，問題是我們初始化上下文的時(shí)候，連接的到底是哪個(gè)managed server?
        初始化上下文的時(shí)候，我們需要提供一個(gè)provider url, 如下：
        PROVIDER_URL = "t3://localhost:7011";
        這種寫法很簡(jiǎn)單，直接連接7001對(duì)應(yīng)的server, 但如果寫法如下呢？
        CLUSTER_PROVIDER_URL="t3://localhost:7011,localhost:7021";
        這時(shí)候，load banlance就又來了。10個(gè)客戶端(weblogic server或者thin client)new 10個(gè)InitialContext的話，這10個(gè)客戶端將55分別連接到后端的兩臺(tái)server上去。實(shí)際上客戶端在new InitialContext的時(shí)候，weblogic會(huì)創(chuàng)建一個(gè)T3連接到對(duì)應(yīng)的managed server上(RJVMConnection)，注意這個(gè)RJVMConnection是個(gè)長(zhǎng)連接，在同一個(gè)JVM中，連向同一managed server的連接只有一個(gè)。即如果一個(gè)客戶端，連續(xù)new 10個(gè) InitialContext, 這10個(gè)Context實(shí)際上是同一對(duì)象，weblogic server這時(shí)根本不會(huì)和后端的server通訊，因?yàn)閷?duì)象已經(jīng)在client JVM中有了。
        new InitialContext的load banlance算法基本和proxy的算法一樣，都是維護(hù)一個(gè)server list, 通過index遞增的方法實(shí)現(xiàn)。不同的是：在連接某個(gè)managed server的connection遇到peer gone的時(shí)候， proxy可以recover server list, 而jndi context的load banlance算法則不能。也就是說如果后端有三個(gè)managed server， server1， server2相繼出現(xiàn)故障的話，所有客戶端的context將都會(huì)連接到server3, 即使server1, server2能夠恢復(fù)過來，后續(xù)請(qǐng)求也不會(huì)連接到他們，除非server3后來出現(xiàn)問題。

        值得一提的是：context所有的相關(guān)操作時(shí)server affinity的，而非load banlance。比如：2個(gè)客戶端分別new了個(gè)context, 分別連接到server1和server2上，連接到server1的context，做了10次lookup，那么這10次操作，都在server1上完成，不會(huì)在server2上作任何操作。所以說jndi級(jí)別的load banlance不是絕對(duì)均衡的。

        3: JMS Distributed Queue的load banlance

        Distributed Queue(簡(jiǎn)稱DQ)，顧名思義，分布式隊(duì)列。在不同的JMS Server上，我們會(huì)創(chuàng)建不同的物理Queue, 按照傳統(tǒng)方式，我們?cè)诎l(fā)送消息(或者創(chuàng)建JMSSession)的時(shí)候，需要指定一個(gè)物理Queue， 這樣我們可以將消息發(fā)送到固定的Queue上。 由于在Weblogic server上， JMS Server是一個(gè)pin service， 即只能運(yùn)行于單個(gè)managed server上的服務(wù)實(shí)例。 如果我們發(fā)送消息的時(shí)候，指定Queue對(duì)應(yīng)的jms server出現(xiàn)了問題，這樣消息無法發(fā)送出去。基于這個(gè)原因， Weblogic上提出了DQ，DQ是個(gè)邏輯Queue,并沒有時(shí)間的物理Queue與其對(duì)應(yīng)，它用于管理多個(gè)、分布于不同jms server上的物理Queue, 這樣客戶發(fā)送、接受消息的時(shí)候，需要指定的是DQ，而不是物理Queue。客戶端知道的只是將消息發(fā)送到了DQ，而無法知道到底發(fā)送到哪個(gè)具體的物理Queue上了。那么Weblogic是如何計(jì)算消息該發(fā)送到具體物理Queue呢？ 

        JMS Connection Factroy的配置選項(xiàng)中l(wèi)oad banlance參數(shù)：LoadBanlanceEnabled，ServerAffinityEnabled
        Distributed Queue的配置選項(xiàng)中l(wèi)oad banlance參數(shù)：LoadBanlancePolicy，默認(rèn)為Round-Robin， 可選值包括：Round-Robin, Random

        Load Balancing Enabled:
        Specifies whether non-anonymous producers created through a connection factory are load balanced within a distributed destination on a per-call basis.

• If enabled, the associated message producers are load balanced on every send() or publish() .

• If disabled, the associated message producers are load balanced on the first send() or publish().

        ServerAffinityEnabled：    
        Specifies whether a server instance that is load balancing consumers or producers across multiple members destinations of a distributed destination, will first attempt to load balance across any other physical destinations that are also running on the same server instance.

        Load Balancing Policy：
        Determines how messages are distributed to the members of this destination.
        
        Round-Robin 
        - The system maintains an ordering of physical topic members within the set by distributing the messaging load across the topic members one at a time in the order that they are defined in the configuration file. Each WebLogic Server instance maintains an identical ordering, but may be at a different point within the ordering. If weights are assigned to any of the topic members in the set, then those members appear multiple times in the ordering.

        Random 
        - The weight assigned to the topic members is used to compute a weighted distribution for the members of the set. The messaging load is distributed across the topic members by pseudo-randomly accessing the distribution. In the short run, the load will not be directly proportional to the weight. In the long run, the distribution will approach the limit of the distribution. A pure random distribution can be achieved by setting all the weights to the same value, which is typically set to 1.

        JMS Connection Factroy在創(chuàng)建JMSConnection的時(shí)候，這一層是load banlance的， 即JMSConnection會(huì)連接到不同的后端managed server上。這個(gè)load banlance是基于round_robin的。一旦connection創(chuàng)建完成，所有通過該JMSConnection創(chuàng)建的consumer, producer會(huì)stick到JMSConnection對(duì)應(yīng)的managed server上， 即所有的message會(huì)被dispatch到該managed server的物理Queue上(因?yàn)閟ub-type的jms對(duì)象不是RMI對(duì)象，他們和后端managed server的通訊是基于dispatcher的，通過invocable id來識(shí)別對(duì)象)。如果producer send了很多條message, 那么這些消息如何分發(fā)？這就是Load Balancing ，ServerAffinity要做的事兒。

        Load Balancing Enabled被check的時(shí)候，消息分發(fā)是基于send()方法的，即send一條message, message都會(huì)被分發(fā)到不同的Queue上。如果Load Balancing Enabled沒有被check，那么同一producer send的所有message會(huì)被分發(fā)到同一物理Queue上。而ServerAffinity則說明loadbalance Queue的范圍，如果serverAffinity為true，那么說明load banlance的范圍為處理send request那臺(tái)managed server上的Queues，如果為false，則說明在所有的queue間作load balance。

        4：EJB的load banlance

        EJB的load banlance比較復(fù)雜，涉及到如下三個(gè)方面：
        1：IntitialContext
        關(guān)于InitialContext, 前面已經(jīng)談過，這里不再做討論。

        2：EJB Home
        對(duì)于EJB Home，可以通過weblogic-ejb-jar.xml中的home-load-algorithm 配置，可選項(xiàng)包括：round-robin | random | weight-based | RoundRobinAffinity | RandomAffinity | WeightBasedAffinity, default依賴于weblogic.cluster.defaultLoadAlgorithm，如果沒有對(duì)應(yīng)的system property, 則為round-robin。
        如果home-load-algorithm為round-robin，則說明客戶端拿到initial context后，在做ejb home create的時(shí)候是round robin的(創(chuàng)建的的bean object位于不同的managed server上)。如果home-load-algorithm為RoundRobinAffinity ，則表明home create是round robin的，但后續(xù)的home的操作則是server affinity的，比如，home位于serverA上，則該home創(chuàng)建的所有bean object均位于serverA上。
        其余算法基本類似，區(qū)別只是home create時(shí)候的算法不同而已。
       
         3:   EJB Object
         對(duì)于Bean的load banlance，只有stateless session支持，可以通過stateless-bean-load-algorithm配置，可選項(xiàng)同EJB Home。因?yàn)閟tateful session bean及entity bean包含狀態(tài)數(shù)據(jù)，所以無法作laod banlance，否則在數(shù)據(jù)同步方面，weblogic需要付出的開銷要遠(yuǎn)大于laod banlance帶來的收益。
        如果stateless-bean-load-algorithm為round-robin，則說明bean操作是round-robin的。如果為RoundRobinAffinity ，則business method是affinity的，即所有的method都在object對(duì)應(yīng)的server上被執(zhí)行。

        5：JDBC
        對(duì)于JDBC,如果要使用load banlance的話，我們需要配置multi pool，multi pool和jms 的distribute destination類似，是一個(gè)邏輯pool，用于管理一組物理pool(通常位于不同的managed server上)。Multi pool的算法包括: HA(用于fail over), Load banlance。前者只是在某個(gè)物理pool出現(xiàn)故障的時(shí)候，用于fail over，而不提供load banlance。而后者則是兩種功能都提供，正常時(shí)作laod banlance，運(yùn)行故障期間，fail over會(huì)起作用。