Shuffy

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

原鏈接
Uncover the hood of J2EE Clustering

1 前言

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

J2EE集群是最常用的技術(shù)，用來提供高可用性和伸縮性的容錯服務(wù)。但由于缺乏J2EE規(guī)范的支持，J2EE提供廠商實現(xiàn)的集群盡不相同，引起許多J2EE架構(gòu)師和開發(fā)者的麻煩，比如下面：

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

2 基本術(shù)語

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

2.1 伸縮性(Scalability)

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

2.2 高可用性(High Availability)

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

2.3 負載均衡(Load balancing)

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

2.4 容錯(Fault Tolerance)

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

2.5 失效轉(zhuǎn)移(Failover)

失效轉(zhuǎn)移是另一項使得集群實現(xiàn)容錯的關(guān)鍵技術(shù)。通過選擇集群中另一個節(jié)點，原始節(jié)點失效時處理將繼續(xù)下去。失效轉(zhuǎn)移可以顯式地編碼也可以由低層平臺自動執(zhí)行。

2.6 等冪方法(Idempotent methods)

可以用相同的參數(shù)重復(fù)調(diào)用的方法，并且總是得到相同的結(jié)果。這些方法不應(yīng)該影響系統(tǒng)狀態(tài)，可以被重復(fù)地調(diào)用而不必擔心改變系統(tǒng)。例如， “getUsername()” 是等冪方法，而“deleteFile()” 就不是等冪方法。等冪是HTTP會話和EJB失效轉(zhuǎn)移的重要概念。

3 J2EE集群是什么？

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

圖1 負載均衡

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

圖2：失效轉(zhuǎn)移

如圖2所示，失效轉(zhuǎn)移與負載均衡不同。有時候，客戶端對象對目標對象發(fā)起連續(xù)的方法請求。如果目標對象在請求之間失效，失效轉(zhuǎn)移系統(tǒng)應(yīng)該檢測到并將后續(xù)請求轉(zhuǎn)向?qū)Я硪粋€可用的對象，容錯也可用此途徑實現(xiàn)。

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

圖3：代碼例子

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

所以，什么類型的對象可以被集群？---只有發(fā)布在分布式結(jié)構(gòu)的對象。

所以，什么地方會發(fā)生負載均衡和失效轉(zhuǎn)移呢？--只有在調(diào)用一個分布式對象的方法時。

圖4：分布式對象

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

當客戶端調(diào)用目標對象時，在目標對象容器內(nèi)執(zhí)行功能。客戶端和目標對象通過標準的網(wǎng)絡(luò)協(xié)議通信。利用這些特性添加機制到方法調(diào)用路由中，以實現(xiàn)負載均衡和失效轉(zhuǎn)移。

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

4 web層集群實現(xiàn)
web層集群是J2EE集群中最重要和基礎(chǔ)的功能。web層集群技術(shù)包括：Web負載均衡和HTTPSession失效轉(zhuǎn)移。

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

圖5：web負載均衡

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

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

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

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

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

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

圖6：HTTPSession失效轉(zhuǎn)移

為了實現(xiàn)以上功能，注意下列問題：

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

*如何備份會話狀態(tài)
如何備份會話狀態(tài)是一個使得J2EE服務(wù)器與眾不同的關(guān)鍵因素。不同的提供商實現(xiàn)不同。

*備份頻率和粒度
HTTPSession狀態(tài)備份有性能消耗，包括CPU周期，網(wǎng)絡(luò)帶寬和寫磁盤和數(shù)據(jù)庫的IO消耗。備份頻率和粒度嚴重影響集群的性能。

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

圖7：備份會話狀態(tài)到數(shù)據(jù)庫

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

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

4.4 內(nèi)存復(fù)制方案

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

圖8：內(nèi)存復(fù)制

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

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

4.4.1 Tomcat方案：多機復(fù)制
內(nèi)存復(fù)制存在很多變體方案。一中辦法是跨集群中的多節(jié)點復(fù)制會話狀態(tài)。Tomcat5以此法實現(xiàn)內(nèi)存復(fù)制。

圖9：多機復(fù)制

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

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

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

圖10：配對復(fù)制

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

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

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

4.4.4 IBM的方案--中央狀態(tài)服務(wù)器
Websphere 另一個可用的內(nèi)存復(fù)制選擇是:備份會話信息到一個中央狀態(tài)服務(wù)器，如圖11。

圖11：中央服務(wù)器復(fù)制

和數(shù)據(jù)庫方案非常相似，不同的是一個專門的“會話備份服務(wù)器”代替了數(shù)據(jù)庫服務(wù)器。該方案兼有數(shù)據(jù)庫和內(nèi)存復(fù)制的優(yōu)點：

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

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

4.4.5 Sun的方案--特殊的數(shù)據(jù)庫

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

4.4.6 其它失效轉(zhuǎn)移實現(xiàn)
JRun 使用Jini,Tangosol 使用分布式緩沖。本節(jié)無實質(zhì)內(nèi)容，略。

5 JNDI集群實現(xiàn)
暫略。

6 EJB 集群實現(xiàn)
暫略。

7 關(guān)于J2EE集群的神話

7.1 失效轉(zhuǎn)移可以完全避免錯誤。 ---否定

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

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

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

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

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

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

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

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

7.2 單機應(yīng)用可以被透明地轉(zhuǎn)換為集群結(jié)構(gòu) ---- 絕對不是！
雖然一些提供商聲稱他們的J2EE產(chǎn)品的適應(yīng)性，不要相信他們！實際上，你應(yīng)該在系統(tǒng)設(shè)計開始時就考慮集群，并影響到開發(fā)和測試的所有階段。

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

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

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

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

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

這些服務(wù)由事件而非請求觸發(fā)，應(yīng)當只執(zhí)行一次。這樣的服務(wù)將使得集群的負載均衡和失效轉(zhuǎn)移的意義降低。

一些產(chǎn)品對這樣的服務(wù)早有準備，例如，JBoss使用“集群單一設(shè)施”協(xié)調(diào)所有實例，保證只執(zhí)行這些服務(wù)一次或僅僅一次。基于你選擇的產(chǎn)品平臺，這些服務(wù)有可能成為移植到集群的障礙。

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

圖20：分布式結(jié)構(gòu)

如圖20分布式結(jié)構(gòu)，當請求到來時，負載均衡器將它們分發(fā)到不同的服務(wù)器上的web容器，如請求中包括EJB調(diào)用，web容器將重新分發(fā)EJB調(diào)用到布通的EJB容器。這樣，請求被負載均衡和失效轉(zhuǎn)移了兩次。

一些人不看好分布式結(jié)構(gòu)，他們指出：

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

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

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

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

圖2：排列式結(jié)構(gòu)

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

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

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

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

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

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

8 結(jié)論
集群和單機環(huán)境是不同的。J2EE提供商以不同的方式實現(xiàn)集群。為了構(gòu)建一個大型的系統(tǒng)，在項目開始時，你就應(yīng)該為J2EE集群做準備。選擇合適的 J2EE產(chǎn)品是g和你的應(yīng)用。選擇合適的第三方軟件和框架時確保它們可以被集群。然后設(shè)計合適的架構(gòu)以得到集群帶來的實際利益。

概述

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

集群層次說明

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

應(yīng)用級集群，是ejb集群，EJB是J2EE應(yīng)用平臺的核心，EJB是用于開發(fā)和部署具多層結(jié)構(gòu)的、分布式的、面向?qū)ο蟮腏ava應(yīng)用系統(tǒng)跨平臺的構(gòu)件體系結(jié)構(gòu)。主要是業(yè)務(wù)應(yīng)用，部署在EJB容器上。<o:p></o:p>

數(shù)據(jù)庫級集群，是oracle數(shù)據(jù)庫設(shè)置多個數(shù)據(jù)庫實例，全部映射到數(shù)據(jù)庫。

Weblogic集群概念

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

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

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

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

Weblogic集群要求

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

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

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

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

項目實戰(zhàn)

項目概況

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

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

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

<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的目的就是應(yīng)用服務(wù)器集群，部署示意圖如下：

Web級集群

Web集群中使用內(nèi)存復(fù)制策略<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