對於理解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和你的應用。選擇合適的第三方軟件和框架時確保它們可以被集羣。然後設計合適的架構以得到集羣帶來的實際利益。
