Shuffy

對于理解J2EE集群技術不錯的文章，雖然是Sun的技術人員撰寫的，基本觀點還算客觀，內容深淺恰當，非常適合剛剛接觸集群的朋友閱讀，故此大膽翻譯過來，放在這里和大家共享，錯誤難免，歡迎指正。

原鏈接
Uncover the hood of J2EE Clustering

1 前言

越來越多的關鍵任務和大型應用正運行在J2EE平臺上，象銀行之類的應用要求很高的可用性(HA)，大型系統比如google和Yahoo則要求更好的伸 縮性。今天高可用性和伸縮性的重要性對于互聯世界日益增長，最著名的證明是1999年eBay中斷了22小時的服務，原因是超過230萬次的拍賣，最終導 致eBay股票下跌了9.2個百分點。

J2EE集群是最常用的技術，用來提供高可用性和伸縮性的容錯服務。但由于缺乏J2EE規范的支持，J2EE提供廠商實現的集群盡不相同，引起許多J2EE架構師和開發者的麻煩，比如下面：

1. 為什么附帶集群能力的商業J2EE服務器如此昂貴？(比不帶集群能力的貴10倍)
2. 為什么我在單機上創建的應用無法運行在集群模式？
3. 為什么我的應用在集群時運行緩慢但不集群時卻很快速？
4. 為什么我的集群應用不能與其他提供商的服務器通信？

2 基本術語

討論不同實現之前，理解集群技術的概念是很有意義的，我希望不僅能給你提供關于J2EE集群產品基本的設計理念和概念，還可以概括性的描繪不同的集群實現，使它們更容易被理解。

2.1 伸縮性(Scalability)

大型系統很難預測終端用戶的數量與行為，伸縮性是指系統可以支持用戶的快速增長。提高服務器同時處理并發會話的最直覺的方式就是增加服務器資源(內存， CPU，或硬盤)，集群是解決伸縮性的另一種可選方式。它允許一組服務器分擔處理繁重的任務，而邏輯上就象一臺服務器一樣。

2.2 高可用性(High Availability)

提高伸縮性的單服務器解決方案(添加內存和CPU)是并不強壯的辦法，因為單點失效原因。關鍵任務應用不能容忍服務中斷哪怕一分鐘。它要求任何時候都可以合理地可預期的響應時間訪問這些服務，集群可以通過提供額外的服務器使其在一臺服務器實效時提供服務，從而提高可用性。

2.3 負載均衡(Load balancing)

負載均衡是集群技術之后的一個關鍵技術，通過分發請求到不同的服務器來提高可用性和更好的性能。負載均衡器可以是一個Servlet或插件(例如a linux box using ipchains)，除分發請求之外，負載均衡器應負責其他一些重要的任務，例如“會話黏附”，使得某個用戶會話始終在一臺服務器上存活，還有“心跳檢 測”，防止分發請求到失效的服務器。有時候負載均衡器也參與到“失效轉移”處理。

2.4 容錯(Fault Tolerance)

高可用性數據不必是嚴格正確數據.在J2EE集群中，當一個服務器實例失效時，服務仍然可用，因為新的請求可由其他冗余的服務器實例處理。但如果請求正在處理當中時服務器實例失效，則不能能得到正確的數據。然而容錯服務則總是保證嚴格正確的行為。

2.5 失效轉移(Failover)

失效轉移是另一項使得集群實現容錯的關鍵技術。通過選擇集群中另一個節點，原始節點失效時處理將繼續下去。失效轉移可以顯式地編碼也可以由低層平臺自動執行。

2.6 等冪方法(Idempotent methods)

可以用相同的參數重復調用的方法，并且總是得到相同的結果。這些方法不應該影響系統狀態，可以被重復地調用而不必擔心改變系統。例如， “getUsername()” 是等冪方法，而“deleteFile()” 就不是等冪方法。等冪是HTTP會話和EJB失效轉移的重要概念。

3 J2EE集群是什么？

一個幼稚的問題，不是嗎？但我仍然用一些話語和圖表來回答它。通常J2EE集群技術包括“負載均衡”和“失效轉移”。

圖1 負載均衡

如圖1所示，有很多客戶端對象并發發送請求到目標對象。負載均衡器則位于調用者和被調用者之間，分發請求到冗余的擁有同樣功能的對象上。用此方法可以實現高可用性和高性能。

圖2：失效轉移

如圖2所示，失效轉移與負載均衡不同。有時候，客戶端對象對目標對象發起連續的方法請求。如果目標對象在請求之間失效，失效轉移系統應該檢測到并將后續請求轉向導另一個可用的對象，容錯也可用此途徑實現。

如果想了解更多J2EE集群，你應該問更多的基本問題，例如：“什么類型的對象可以被集群？”，“在我的J2EE代碼中什么地方出現負載均衡和失效轉 移？”，對于理解J2EE集群的原理，這些都是非常好的問題。實際上，不是所有對象可以被集群，也不是任何地方都可以負載均衡和失效轉移！看看下列代碼：

圖3：代碼例子

當“instance1”失效時，“Class A”的“business()”方法會負載均衡和失效轉移到另一個B實例嗎？不，不會。對于負載均衡和失效轉移，必須要在調用者和被調用者之間存在一個攔 截器，用來分發或者轉向方法調用到不同的對象上。A和B的實例對象運行在同一個JVM上，并緊密耦合。很難在方法調用之間添加分發邏輯。

所以，什么類型的對象可以被集群？---只有發布在分布式結構的對象。

所以，什么地方會發生負載均衡和失效轉移呢？--只有在調用一個分布式對象的方法時。

圖4：分布式對象

在分布式環境，如圖4所示，調用者和被調用者被分離為不同邊界的運行容器，邊界是JVM，進程或機器。

當客戶端調用目標對象時，在目標對象容器內執行功能。客戶端和目標對象通過標準的網絡協議通信。利用這些特性添加機制到方法調用路由中，以實現負載均衡和失效轉移。

如圖4所示，瀏覽器可以通過HTTP協議調用遠程JSP對象。JSP在Web服務器上執行，瀏覽器不關心執行過程，它只需要結果。在這樣的場景中，有些東 西可以位于瀏覽器和web服務器之間用來實現負載均衡和失效轉移功能。在J2EE中，分布式技術包括：JSP(Servlet)，JDBC ，EJB，JNDI，JMS，Webservices和其他。當分布式方法被調用時可以發生負載均衡和失效轉移。下面我們會討論細節。

4 web層集群實現
web層集群是J2EE集群中最重要和基礎的功能。web層集群技術包括：Web負載均衡和HTTPSession失效轉移。

4.1 web負載均衡
J2EE提供商有很多方法實現web負載均衡，基本的，在瀏覽器和web服務器之間放置負載均衡器。

圖5：web負載均衡

負載均衡器可以是硬件產品如F5 負載均衡器，也可以是另一個帶有負載均衡插件的web服務器。簡單的帶有ipchains的linux box也可以執行負載均衡的功能。無論何種技術，負載均衡器通常有以下特性：

*實現負載均衡算法
當客戶端請求達到時，負載均衡器決定如何分發請求到后端服務器實例。通常的算法包括Round-Robin，(指的是使組中所有成員都能均等地以某種合理 的順序被選擇到的一種安排方式， 通常是從列表的頭至尾，而后周而復始)，隨機和基于權重。 負載均衡器試圖使每個服務器實例完成相同的工作量，但以上算法都不能真正達到理想的等量，因為他們只是基于分發到某個服務器實例請求的數量來計算。一些聰 明的負載均衡器實現特別的算法，他們會測試每個服務器的工作負載來決定分發請求。

*心跳檢測
當一些服務器實例失效時，負載均衡器應該檢測到失效，并不再分發請求到失效的服務器上。負載均衡器也需要監視服務器恢復狀況，并給它重新分發請求。

*會話粘連
幾乎每個web應用都有會話狀態，使得記住用戶是否登陸或購物車變得非常簡單。因為HTTP協議本身沒有狀態，會話狀態需要存在某個地方，并和瀏覽會話關 聯起來，可以在下一次請求時很容易地被檢索到。當負載均衡時，最好選擇分發相同的瀏覽器會話請求到同一臺服務器實例上，否則應用工作會不正常。

因為會話狀態存儲在某個web服務器實例的內存中，“會話粘連”對于負載均衡非常重要。但，如果一臺服務器實例因為某些原因失效（比如斷電），那么該服務 器上多有的會話狀態就丟失了。負載均衡器檢測到了該失效，不再向其分發請求。但存儲在失效服務器上的會話的那些請求將丟失會話信息，這種情況會引起錯誤， 因此會話失效轉移到來了！

4.2 HTTPSession失效轉移
幾乎所有的流行的J2EE提供商都在他們的集群產品中實現了HTTPSession失效轉移，確保所有的客戶請求可以不因為一些服務器實例的失效而丟失任 何會話狀態。如圖6所示，當瀏覽器訪問一個有狀態的web應用（第1，2步），此應用可以在內存中創建會話對象存儲信息以備后用。同時，向瀏覽器送回 HTTPSession ID，用來標記該會話對象（第3步）。瀏覽器以cookie的方式存儲該ID，并會在下次發起請求時送回web服務器。為了支持會話失效轉移，會話對象將 在某時某處將它自己備份（第4步）。負載均衡器可以檢測失效（第5，6步），分發請求到其他服務器實例（第7步）。因為會話對象已經被備份，新的web服 務器實例可以恢復該會話并正確地處理請求。

圖6：HTTPSession失效轉移

為了實現以上功能，注意下列問題：

*全局HTTPSession ID
如上所述，HTTPSession ID用來標記某個服務器實例內存中的會話對象。在J2EE中，HTTPSession ID依賴于JVM實例。每個JVM實例可以控制多個web應用，每個應用又可以控制許多不同用戶的HTTPSession，HTTPSession ID是存取當前JVM實例中相關會話對象的鍵。在會話失效轉移實現中，要求不同的JVM實例不應該產生兩個同樣的HTTPSession ID，因為失效時，在一個JVM的會話可能在另一個JVM中備份和恢復。所以，應該建立全局的HTTPSession ID機制。

*如何備份會話狀態
如何備份會話狀態是一個使得J2EE服務器與眾不同的關鍵因素。不同的提供商實現不同。

*備份頻率和粒度
HTTPSession狀態備份有性能消耗，包括CPU周期，網絡帶寬和寫磁盤和數據庫的IO消耗。備份頻率和粒度嚴重影響集群的性能。

4.3 數據庫持久化方案
幾乎所有的J2EE集群產品允許你通過JDBC接口使用關系數據庫備份會話狀態。如圖7所示，該方案只是簡單地讓服務器實例序列化會話內容，并在適當的時 候寫入數據庫。當失效轉移發生時，另一個可用的服務器實例負責失效的服務器，并從數據庫中恢復會話狀態。 對象序列化是關鍵點，使得內存會話對象數據持久化和可移動。更多對象序列化信息請參考
http://java.sun.com/j2se/1.5.0/docs/guide/serialization/index.html

圖7：備份會話狀態到數據庫

象數據庫事務一樣代價昂貴，該方案的主要缺點是有限的伸縮性：當存儲大量會話中的對象時。許多使用數據庫會話持久化的應用服務器鼓吹 HTTPSession的最小限度的使用，但其實他們還限制了你的應用架構和設計，特別是如果你使用HTTPSession存儲緩沖用戶數據。

數據庫方案也有一些優點.
*實現簡單。江會話備份處理和請求處理分離，使得集群易于管理并比較健壯。
*會話可以失效轉移到任何其它機器上，因為使用共享數據庫。
*會話數據可以在整個集群失效后仍然生存。

4.4 內存復制方案

由于性能問題，一些J2EE服務器(Tomcat,JBoss,WebLogic和WebSphere)提供另一種實現：內存復制。

圖8：內存復制

基于內存的會話持久化存儲會話信息，該方案由于性能好非常流行。和數據庫方案比較，在原始服務器和備份服務器之間直接網絡通信是非常輕量級的。請注意該方案，數據庫方案中的“恢復”階段是不需要的。請求到來時，所有的會話數據已經存在于備份服務器的內存中了。

”JavaGroups”是目前JBoss和Tomcat集群的通訊層，JavaGroups 是一個實現群通訊和管理的工具包。它提供的核心特性是“Group membership protocols”和“message multicast”更多信息請參考http://www.jgroups.org/javagroupsnew/docs/index.html

4.4.1 Tomcat方案：多機復制
內存復制存在很多變體方案。一中辦法是跨集群中的多節點復制會話狀態。Tomcat5以此法實現內存復制。

圖9：多機復制

如圖9所示，當一個服務器實例的會話狀態改變時，它將向集群中所有服務器備份它的數據。如果其中一個實例失效，負載均衡器可選擇其它任何可用的服務器實例 作為其備份服務器。但該方案在伸縮性上有缺陷。如果集群中有很多實例，網絡通訊消耗就不可忽略了，這種情況將嚴重降低性能和網絡交通，成為瓶頸問題。

4.4.2 Weblogic, Jboss and WebSphere的方案--配對復制
因為性能和伸縮性問題，Weblogic, JBoss and Websphere 都提供了另一種方法實現內存復制：每個服務器實例選擇任一個備份實例存儲會話信息，如圖10。

按這種方式，每個服務器實例擁有它自己的配對備份服務器而不是所有其它服務器。該方案消除了伸縮性問題。

圖10：配對復制

雖然該方案實現了會話失效轉移的高性能和高伸縮性，仍然有下列限制：

*給負載均衡器帶來了復雜性。當一臺服務器實例失效，負載均衡器必須記住哪個實例是其配對備份服務器，縮小了負載均衡器 的選擇范圍，一些硬件均衡器不能在此結構中使用。
* 除了處理正常的請求，服務器同時負責復制。每個服務器實例，請求處理容量被減小，因為CPU周期需要完成復制職責。
*除了正常處理，許多內存被用來存儲備份會話狀態，即使沒有失效轉移發生，也增加了JVM垃圾收集的消耗。
*集群中的服務器實例組成復制配對。所以如果會話粘連失效的主服務器，負載均衡器能發送失效轉移請求到備份服務器上。備份服務器將在進入的請求中遇到麻煩，引起性能問題。

為了克服以上限制,不同的提供商的變種產生了。Weblogic 為每個會話而不是服務器定義了備份配對。當一臺服務器實例失效，失效服務器上的會話被分散到不同備份服務器上，并且被分散地裝載。

4.4.4 IBM的方案--中央狀態服務器
Websphere 另一個可用的內存復制選擇是:備份會話信息到一個中央狀態服務器，如圖11。

圖11：中央服務器復制

和數據庫方案非常相似，不同的是一個專門的“會話備份服務器”代替了數據庫服務器。該方案兼有數據庫和內存復制的優點：

*分離的請求處理和會話備份，使得集群更強壯。
*所有的會話數據備份到專門的服務器上。bu需要服務器實例浪費內存區保存其它服務器的備份會話數據。
*會話可以失效轉移到其它任何實例上。因為會話備份服務器是被集群中的所有節點共享的。所以，大多數負載均衡軟件和硬件可以在此集群中使用。更重要的是，請求裝載在失效時將均勻分散。
*因為應用服務器和會話備份服務器之間的socket通訊是輕量級的相對于重型的數據庫聯接。它比數據庫方案有著更好的性能和伸縮性。

然而，由于“恢復”階段覆蓋失效服務器的會話數據，它的性能和直接或配對內存復制方案不一樣，附加的會話備份服務器對管理員也增加了復雜性，性能瓶頸由備份服務器自己的性能所限制。

4.4.5 Sun的方案--特殊的數據庫

Sun 自己的方案，本節略，大家感興趣可以自己看原文。

4.4.6 其它失效轉移實現
JRun 使用Jini,Tangosol 使用分布式緩沖。本節無實質內容，略。

5 JNDI集群實現
暫略。

6 EJB 集群實現
暫略。

7 關于J2EE集群的神話

7.1 失效轉移可以完全避免錯誤。 ---否定

JBoss文檔中，有一整章節警告“你真的需要HTTP會話復制嗎？”，是的，有時候一個沒有失效轉移的高可用性方案也是可以接受的，并且便宜。更進一步說，失效轉移并不像你想的那樣有力。

到底失效轉移給了你什么？你們中的一些可能認為它可以避免錯誤。您瞧，沒有失效轉移，會話數據在服務器失效時丟失了并引起錯誤；當會話失效轉移，會話可以從備份中恢復，并且請求可以由另一個實例繼續處理，客戶端不知道該失效。這可能是真的，但它不是必要的條件。

當我定義“失效轉移”時，我定義了失效轉移發生的條件：“在方法調用之間”，意味著你可以有兩個連續的到一個遠程對象的方法，失效轉移將發生在第一個方法成功完成之后和第二個方法請求發出之前。

那么，在方法調用處理中間，遠程服務器失效了會發生什么事情？答案是：處理將停止，大多數案例中，客戶端將看到錯誤信息，除非該方法是等冪的（參考前文）。如果是等冪方法，一些負載均衡器足夠聰明，會在其它服務器上重試這些方法。

為什么等冪重要？因為當失效發生時，客戶端從來不知道請求在哪里執行，方法被初始化或已經完成了？客戶端從不確定它。如果方法不是等冪的，兩次調用同樣的方法將改變系統狀態兩次，系統將處于不一致狀態。

您可能想把所有的方法放在一個事務中就變成等冪的了。畢竟，如果錯誤發生，事務將回滾，所有的事務狀態沒有改變。但是事實是，事務邊界不能包括所有遠程方法調用。如果事務提交，在返回客戶端時網絡崩潰，客戶端不會知道服務器事務成功與否。

在應用中，將所有方法變成等冪是不可能的。所以，通過失效轉移，你可以減少錯誤，但不能避免它們！以再現購物網站為例，假定每臺服務器實例可以同時處理 100個在線用戶的請求。當一臺服務器失效，沒有會話失效轉移的方案將丟失所有那100個用戶的會話數據并激怒他們；當擁有會話失效轉移，只有20個用戶 的請求被失效的服務器在處理過程中，只有這些用戶被錯誤激怒了。其它80個用戶還處在思考時間(用戶行為的間隔時間)或者方法調用之間。這些用戶的會話被 透明地失效轉移了。所以，你應該考慮以下事項：

*激怒20個和100個用戶的不同影響
*擁有失效轉移和沒有失效轉移的成本

7.2 單機應用可以被透明地轉換為集群結構 ---- 絕對不是！
雖然一些提供商聲稱他們的J2EE產品的適應性，不要相信他們！實際上，你應該在系統設計開始時就考慮集群，并影響到開發和測試的所有階段。

7.2.1 Http會話
在集群環境，對HTTPSession的使用有著嚴格的限制正如我在前邊提及的一樣，你的應用服務器依賴不同的機制使用會話失效轉移。最重要的限制是所有 存儲在HTTPSession里的對象必須是可序列化的，這一點限制了應用的結構和設計。一些設計模式和MVC框架使用HTTPSession存儲不可序 列化對象（如Servlet Context,Local EJB 接口，web services引用），這樣的設計不能在集群中工作。其次，對象序列化和反序列化在性能上消耗很大特別是數據庫方案。在這樣的環境中，存儲巨大或眾多的 會話對象，應該避免。如果你已經選擇內存復制方案，小心HTTPSession的交叉引用屬性的限制。另一主要的區別是，你需要在每次改變 HTTPSession屬性的時候調用“setAttribute ()”方法。調用這些方法在單機應用中不是必須的。其目的是將改變的屬性和未改變的屬性分離開來，所以系統可以只備份必要的數據。

7.2.2 緩沖
幾乎我經歷過的每一個J2EE項目都使用緩沖提升性能，所有的流行服務器提供不同程度的緩沖以提升應用性能。但這些緩沖是單機應用的典型設計，只能在一個 JVM實例上工作。我們需要緩沖是因為創建這些新對象的代價是如此昂貴，所以我們維護一個對象池來重用對象實例。每個JVM實例都擁有自己的緩沖拷貝，它 們也應該被同步,以在所有服務器實例上維持一致的狀態。有時，這種同步導致性能惡劣還不如不要緩沖。

7.7.3 靜態變量
一些設計模式，比如“Singleton”(單例) 使用靜態變量來給其它對象共享狀態。這種方案在單一的服務器上工作得很好，但在集群中失效了。集群中的每個實例都會在其JVM實例中維護它自己的靜態變量 拷貝，因此就破壞了該設計模式的共享機制。一個使用靜態變量的例子是保持在線用戶的總數。簡單的辦法就是將改數字存儲到靜態變量中，當用戶登錄或下線時增 加或減少它。在單一服務器上該應用絕對運行得非常好，但在集群中就失效了。更可取的辦法是將所有狀態存儲到數據庫中去。

7.7.4 外部資源
雖然J2EE規范不推薦使用，外部I/O操作還是有很多的用途。例如一些應用使用文件系統存儲用戶上載的文件，或者創建動態的配置XML文件。在集群中， 英勇服務器沒法跨實例復制這些文件。為了在集群中工作，解決方案是如有可能，使用數據庫替代外部文件。也可以選擇SAN作為中央文件存儲。(備注：SAN 英文全稱：Storage Area Network，即存儲區域網絡。它是一種通過光纖集線器、光纖路由器、光纖交換機等連接設備將磁盤陣列、磁帶等存儲設備與相關服務器連接起來的高速專用 子網。)

7.7.5 特殊的服務
有一些特殊的服務只有在單機模式下才有意義。定時器服務就是一種，給予一個恒定的間隔有規律地發生。定時器服務通常用來自動執行管理任務，比如日志文件轉 儲，系統數據備份，數據庫consistence 檢測和冗余數據清除。一些基于事件的服務也很難移植到集群環境中。初始化服務就是很好的例子。郵件通知服務也是如此。

這些服務由事件而非請求觸發，應當只執行一次。這樣的服務將使得集群的負載均衡和失效轉移的意義降低。

一些產品對這樣的服務早有準備，例如，JBoss使用“集群單一設施”協調所有實例，保證只執行這些服務一次或僅僅一次。基于你選擇的產品平臺，這些服務有可能成為移植到集群的障礙。

7.8 分布式結構比排列式結構更有彈性？ -- 不一定！
J2EE技術，特別是EJB，因為分布式計算而產生。解耦業務功能，重用遠程對象使得多層應用流行。但我們也不能把所有東西都分布式化吧。一些J2EE架構師認為將web層和EJB層緊密排列更好。

圖20：分布式結構

如圖20分布式結構，當請求到來時，負載均衡器將它們分發到不同的服務器上的web容器，如請求中包括EJB調用，web容器將重新分發EJB調用到布通的EJB容器。這樣，請求被負載均衡和失效轉移了兩次。

一些人不看好分布式結構，他們指出：

*第二次負載均衡是不必要的，因為它不能使任務分配更均勻。每個服務器實例在同一個JVM實例中都擁有它自己的web容器和EJB容器。讓EJB容器處理其它實例的web容器的請求，看不出比實例內部調用有更多的優點。

*第二次失效轉移是不必要的，因為它并不增加可用性。多數提供商的產品都是在同一JVM實例中集成了web容器和EJB容器。如果EJB容器失效，在多數情況下，web容器此時也是失效的。

*性能降低了。設想應用中的一個方法將調用幾個EJB，若對每個EJB進行負載均衡，最終應用實例跨越了很多的服務器實例運行。這些服務器對服務器的橫跨通信是不必要的。還有，如果方法在一個事務中，事務邊界將包括許多服務器實例，嚴重影響了性能。

在實際的運行狀態，多數提供商（包括Sun JES, Weblogic and JBoss）優化了EJB負載均衡使得請求首先選擇在同一個服務器中的EJB容器。用這種辦法，只在web層進行負載均衡，后續的服務都在同一服務器上處 理。這種結構稱為排列式結構。技術上說，也是分布式結構的一種。

圖2：排列式結構

一個有趣的問題是，因為大部分發布運行時最后都成為了排列式結構，為什么不直接使用本地接口代替遠程接口，這將提升性能。當然可以這樣。但請記住，使用本 地接口，web組件和EJB就緊密耦合了，使得方法直接調用而非通過IIOP/RMI。負載均衡器和失效轉移分發器沒有機會攔截本地調用，“Web+ EJB”過程就被作為一個整體了。

不幸的是，集群中，在J2EE服務器上使用本地接口有很多限制。EJB是帶有本地接口的本地對象，但他們不可序列化。限制就是本地引用不允許存儲在 HTTPSession中。一些產品，如Sun JES區別處理本地EJB,使他們可序列化也能存儲在HTTPSession中。

另一個有趣的問題是：因為排列式結構很流行也有良好的性能，為什么還需要分布式結構？大多蘇h情況，事出有因，有時分布式結構不可替代。

*EJB不僅僅給web容器使用，富客戶端也是用戶之一。

*EJB組件和web組件可能在不同的安全級別，需要物理地分隔開來。所以，防火墻可能用來保護運行EJB的更重要的機器。

*Web層和EJB層的極端不對稱也許是選擇分布式結構的一個好理由，例如，一些EJB組件太復雜資源消耗巨大，那么它們只能在一些昂貴的 大服務器上運行；另一方面，web組件(HTML，JSP，Servlet)非常簡單可以在便宜的PC服務器上運行。在這種條件下，專門的web服務器接 收客戶端請求，提供靜態數據（HTML和圖片）和簡單的web組件（JSP和Servlet）。大型服務器只用來進行復雜計算。

8 結論
集群和單機環境是不同的。J2EE提供商以不同的方式實現集群。為了構建一個大型的系統，在項目開始時，你就應該為J2EE集群做準備。選擇合適的 J2EE產品是g和你的應用。選擇合適的第三方軟件和框架時確保它們可以被集群。然后設計合適的架構以得到集群帶來的實際利益。

概述

一個集群系統是一群松散結合的服務器組，形成一個虛擬的服務器，為客戶端用戶提供統一的服務。對于這個客戶端來說，通常在訪問集群系統時不會意識到它的服務是由具體的哪一臺服務器提供。集群系統一般應具高可用性、可伸縮性、負載均衡、故障恢復和可維護性等特殊性能。越來越多的關鍵任務和大型應用正運行在J2EE平臺上，象銀行之類的應用要求很高的可用性(HA)，大型系統比如大型網站則要求更好的伸縮性。J2EE集群是最常用的技術，用來提供高可用性和伸縮性的容錯服務，單機部署和多機集群化部署差別很大，網上的資料大多語焉不詳，即使文檔圖文并茂，也是到了關鍵處就部署成功，其實后面還要做些工作才行，且多以單機部署多個server來模擬集群化部署，其實和真正多機部署還是有比較大的差別。本文僅以weblogic應用服務器為例說明集群化部署。

集群層次說明

Web級集群，是J2EE集群中最重要和基礎的功能。web層集群技術包括：Web負載均衡和HTTPSession失效轉移。web負載均衡，基本的是在瀏覽器和web服務器之間放置負載均衡器。<o:p></o:p>

應用級集群，是ejb集群，EJB是J2EE應用平臺的核心，EJB是用于開發和部署具多層結構的、分布式的、面向對象的Java應用系統跨平臺的構件體系結構。主要是業務應用，部署在EJB容器上。<o:p></o:p>

數據庫級集群，是oracle數據庫設置多個數據庫實例，全部映射到數據庫。

Weblogic集群概念

Ø Domain：由配置為Administrator Server的WebLogic Server實例管理的邏輯單元，這個單元是有所有相關資源的集合。

Ø Server： 一個相對獨立的，為實現某些特定功能而結合在一起的單元。按功能可分為domain server 和managed server。一個Domain 可以包含一個或多個WebLogic Server實例，甚至是Server集群。一個Domain中有一個且只能有一個Server 擔任管理Server的功能，其它的Server具體實現一個特定的邏輯功能。

Ø Domain Server：在一個集群中，有且僅有一個domain server，即管理server，該server只負責管理多個Managed server（被管理server），即domain server僅僅是行政領導，考勤之類的活動，如某個managed Sever的狀態，是未知（unKnown），還是運行（run），還是停止（shutdown），遠程啟動等等，不負責具體業務。因此部署時domain server上不要部署具體任務，畢竟人家是當官的嗎。

Ø Managed Server：真正的實干家，部署具體的應用。應用及業務邏輯組件被分發在多個受管服務器（Managed Server）。<o:p></o:p>

Weblogic集群要求

Ø 集群中的所有Server必須位于同一網段，并且必須是IP廣播(UDP)可到達的

Ø 集群中的所有Server必須使用相同的版本,包括Service Pack

Ø 集群中的Server必須使用永久的靜態IP地址。動態IP地址分配不能用于集群環境。如果服務器位于防火墻后面，而客戶機位于防火墻外面，那么服務器必須有公共的靜態IP地址，只有這樣，客戶端才能訪問服務器 <o:p></o:p>

Ø 使用weblogic的支持集群的licence<o:p></o:p>

項目實戰

項目概況

我們的項目是struts—ejb—hibernate—spring，因為hibernate和spring都必須進行初始化且初始化都依賴于servlet，在系統啟動時就初始化數據，并且我們在web層和ejb層分別部署為web集群和ejb集群，而hibernate和spring都部署在應用服務器上。為此，我們打了兩個部署包，一個是cnlife.war, cnlife_app.ear，其中cnlife.war包部署在web集群上，cnlife

_app.ear部署在ejb集群上，cnlife_app.ear包括兩個包，其中一個是cnlifeejb.jar（ejb包），

另外一個是backgroudinit.war，backgroudinit.war用來初始化spring，hibernate的初始化數據。

<o:p> </o:p>

cnlife.war (部署在Web Server)

_backgroudinit.war

|

cnlife_app.ear-| （部署在 Application Server）

|_cnlifeejb.jar

<o:p> </o:p>

Ejb是stateless Session bean，使用ejb的目的就是應用服務器集群，部署示意圖如下：

Web級集群

Web集群中使用內存復制策略<o:p></o:p>

weblogic.xml 如下

<o:p></o:p>

8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd"><o:p></o:p>

<o:p> </o:p>

<weblogic-web-app><o:p></o:p></weblogic-web-app>

 <session-descriptor><o:p></o:p></session-descriptor>

原文地址：http://hqman.iteye.com/blog/92684