一、 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來響應請求。

WEBLOGIC負載均衡原理

相關文章