WEBLOGIC負載均衡原理
CLUSTER概要
一、 Cluster的概念及優勢
Weblogic支持集羣技術，即讓一組Server指向同一域名一起工作從而提供一個更強大、更可靠的應用平臺。對於客戶端而言，無論Cluster中有幾個Server在工作，看上去都是一個。集羣技術有兩個最明顯的特色：
(1)可伸縮性：Cluster對加入其中的Server在性能上沒有限制，爲了提高性能，當客戶端的請求大幅增加時，可以動態地向Cluster中添加Server。並且，配置Cluster當一臺機器的資源沒有被完全利用時，可以在同一機器上啓動多個Server，但要求每一個Server使用不同的IP，而不能用同一IP的不同端口。
(2)高可用性：由於在Cluster中同一service在多個Server上同時存放或放在一個共享文件系統中，因此相同的請求可以有多個Server提供，並且Server間還可以複製狀態信息。這樣，當其中某一Server宕機或無法響應請求時，其它的Server會立即接管它的任務，從而把應用和客戶端完全隔離開來。
二、Cluster的工作機制
每一個Clustered service,在每一個server上都會有一個instance，即一個replica，這些replicas集合在一起形成一個replica-aware stub。這些stubs負責客戶端與相關的服務器段對象的通信，當客戶端請求該service時，實際上是向stub發出請求，stub根據不同的算法調用集合中某一replica，如果調用失敗，stub會檢測到錯誤並重新調用其它的replica。Cluster支持多種算法：隨機、輪循、基於性能的負載均衡的輪循(Weight-based round-robin)、根據參數值調用(Parameter-based routing)。
Weblogic Cluster通過負載均衡和容錯最大程度的實現了它的可伸縮性和可用性。
爲了提高Cluster的可伸縮性，必須保證充分利用每一個Server。Weblogic可以在不同平臺、不同性能的機器上安裝Server並進行Cluster,然後採用Weight-based round-robin算法達到負載均衡，從而使每一個Server都得到充分的利用。
爲了使Cluster具有高可用性，必須具備故障恢復的能力，這一點可以通過replica-aware stub的容錯功能來實現。Stub 主要是通過在檢測到錯誤信息時重新進行調用的方式實現容錯。當重新調用不會導致錯誤的結果時(如stub確認failed server不能接收到請求)，容錯功能自動實現。而有些情況下，重新調用可能會導致某一service被請求了多次的錯誤結果。例如：客戶端C請求Clustered購物車服務中的additem()方法，replica-aware stub接收到請求，根據算法調用Server1上的service,Server1響應請求並返回結果，但在結果成功到達客戶端之前，Server1出現錯誤。此時stub接收到錯誤信息，因此重新調用Server2上的這一方法，但實際上Server1已經將item加入購物車，這樣就造成重複。爲了解決這種問題，可以爲服務添加一個唯一標識，如上述的additem()方法中可添加一個參數——序列號。每一個item有一個唯一的sequence,相同sequence的item不能被重複添加。
三、 Cluster的命名服務
在Weblogic Server中使用命名服務時，客戶端通過JNDI存取service，JNDI tree上綁定了Server提供的所有的公共服務。Server提供一個新的service時，是將service以某一名稱綁定到JNDI tree上，客戶端和Server建立連接並按照名稱獲取相應的stub。
Custer擴展了Server的這種命名服務機制，它不僅包含了每一個Server上的非Clustered的stub,而且包含了多個Server間的Clustered 的replica-aware stub。
四、 Cluster的服務類型
在Weblogic中，有多種服務可以進行cluster，如：RMI對象、EJB、Servlets、Jsp、Web Application。
（1）RMI和EJB Clustering
RMI和EJB對象在Cluster過程中使用JNDI命名服務機制。RMI和EJB對象發送remote stubs到客戶端，客戶端獲取的這些stubs可以是已經clustered的，也可以是沒有clustered的。對於Clustered的服務，Stubs根據負載均衡和容錯的不同需求調用Cluster中合適的Server；而對沒有Clustered的服務，所有對此stub的調用只能由提供此服務的Server來處理。
有些有狀態的RMI和EJB對象是不可以進行clustered的，因爲客戶端必須總是和同一個Server上的對象實例相聯繫。所有的EJB都是clusterable，雖然EJB也有有狀態的，但是EJB home interface 都是無狀態的，可以進行clustered，這樣就可以從JNDI tree上獲取 Clusterable EJB 的home stub 對象。然後通過home stub的方法創建或檢索相應的EJB bean,若爲stateful session bean 或entity bean，那麼此時得到的stub就是不可clusterable。爲了使有狀態的對象可以更好的cluster，可以將一些操作作爲一個事務來執行，如果工作中的Server出現意外，可以重新獲取此對象並進行事務操作。
RMI和EJB不同，RMI沒有定義有狀態和無狀態分類，因此必須特意綁定一個有狀態的RMI對象到Server上。可以仿效EJB home interface的方式即客戶端從JNDI tree上獲取一個clusterable factory method,然後factory method 可以調用集羣中的任意一臺Server,但是被調用的Server上必須有由此factory調用的對象。
（2）Clustered Servlets
Servlets也是可以進行Cluster的。對於Servlets，它用replica-aware proxy替代了replica-aware。這個proxy接受web server上所有請求，並轉給集羣中的某一Server。Proxy對cluster的所有請求進行負載均衡，並且當請求失敗時會進行恢復處理。Proxy還可以在cluster中特別是Server沒有正常完成請求響應時保持session狀態。當session初始化時，proxy按照負載均衡算法選擇一臺Server保存session，此後，所有與此session相關的請求都由這同一臺Server處理。爲了避免當此Server出錯時，無法保存客戶端狀態信息，所以session會被複製下來，並且session的所有變化都會在備份中進行及時更新，這樣，當原有Server在響應請求過程中失敗時，proxy會立即獲取session的備份，並由此繼續響應客戶端請求，同時做新的複製。
(3)JDBC clustering
爲了利用Weblogic Server cluster的負載均衡和容錯的性能，Weblogic JDBC連接池也可以在replicated naming tree上註冊。通常情況下，cluster中的每一個Server都進行連接池屬性配置來訪問同一個後端的DBMS實例，即對相同數據庫的訪問，每一個Server都有一個連接池。然後通過在配置文件中定義一個DataSource屬性來在naming tree 上註冊連接池。客戶端使用Weblogic JDBC/RMI JDBC 驅動程序從cluster中獲取數據庫連接，即客戶端按照DataSource name獲取連接池，然後按照負載均衡的算法選擇相應的Weblogic Server來響應請求。