JBoss的集群策略分析
(來(lái)源：http://www.yesky.com)
序言 在閱讀本文前，請確定您有以下基礎，否則您可能會(huì )是在浪費您的時(shí)間：
1、 了解J2EE的一些基本概念
2、 了解集群的基本概念
3、 對JBOSS有一些大致的了解，可到http://www.jboss.org上下載它。 JBOSS是一個(gè)開(kāi)放源碼的、基于J2EE規范的應用服務(wù)器，它實(shí)現了大多數的J2EE規范，除此之外，它還提供了一些J2EE中所沒(méi)有涉及到的企業(yè)級功能，例如集群。本文主要描述JBOSS采取的集群策略，并重點(diǎn)介紹它的負載平衡與失效轉發(fā)機制。
由于JBOSS是一個(gè)建立在J2EE規范上的應用服務(wù)器，因此在開(kāi)始之前，我們還是簡(jiǎn)單地介紹一下J2EE規范：J2EE是一套針對于企業(yè)級分布式應用的計算環(huán)境，它定義了動(dòng)態(tài)WEB頁(yè)面功能（servlet和jsp）,商業(yè)組件（EJB），異步消息傳輸機制（JMS），名稱(chēng)和目錄定位服務(wù)（JNDI），數據庫訪(fǎng)問(wèn)（JDBC），與子系統的連接器（JCA），安全服務(wù)等等。
但美中不足的是J2EE并沒(méi)有定義一些企業(yè)級應用所必須的規范，例如集群，所以集群的實(shí)現只能由各廠(chǎng)商自行來(lái)設計實(shí)現。要實(shí)現基于J2EE規范的集群，我們通常要做如下考慮：集群的管理、負載平衡、失效轉發(fā)、服務(wù)端狀態(tài)的復制（例如JSP中的session），還要考慮同步和異步的問(wèn)題（例如JMS服務(wù)就是異步方式）。如果要對這些內容做一個(gè)全面的闡述的話(huà)，估計可以寫(xiě)成一本書(shū)了：） 因此本文主要探討的是：怎樣實(shí)現無(wú)狀態(tài)EJB的負載平衡與失效轉發(fā)機制？
1999年，Marc Fleury建立了JBOSS開(kāi)源項目，現在它有差不多100個(gè)活躍的開(kāi)發(fā)者，30個(gè)核心開(kāi)發(fā)者，每月高達35萬(wàn)次的下載量，它當前的最高穩定版是3.2版，4.0版正在穩定之中，自從JBOSS3.0開(kāi)始就加入了集群技術(shù)，幾乎能對任何J2EE規范進(jìn)行集群管理，如JNDI、JSP中的session、EJB等等。更令人振奮的是，即將發(fā)行的JBOSS4.0將會(huì )對JMS也加入集群管理特色。
EJB集群在JBOSS中的實(shí)現 下面言歸正傳，上圖大致描述了一個(gè)客戶(hù)端調用JBOSS中的EJB的過(guò)程。在JBOSS中，客戶(hù)端并不直接調用EJB對像，而采用了一個(gè)迂回的方法，更專(zhuān)業(yè)的說(shuō)是一種設計模式――代理模式，真正與客戶(hù)端交互的是一個(gè)代理對像①，這個(gè)代理對像一般由客戶(hù)端通過(guò)JNDI技術(shù)來(lái)取得的。而具體的代理對像的實(shí)現就由各廠(chǎng)商自完成了，在JBOSS中，一個(gè)代理對像是一段精心設計的復雜代碼。
但在客戶(hù)端看來(lái)，調用一個(gè)代理對像好像就是在調用那個(gè)實(shí)際的EJB對像，雖然事實(shí)并非如此。在這里JBOSS耍了一個(gè)小把戲，代理對像雖然實(shí)現了與EJB對像相同的接口，但它實(shí)際上是把客戶(hù)端對它的調用轉發(fā)到了它在服務(wù)端的另一個(gè)伙伴身上②，同時(shí)，這個(gè)伙伴同樣定義了客戶(hù)端所要求的一些EJB接口，當這些接口被調用時(shí)③，精彩的部分開(kāi)始了，JBOSS把客戶(hù)端發(fā)過(guò)來(lái)的各種各樣不同的調用全部轉換成為一個(gè)統一格式的接口④（在本文中我們暫且稱(chēng)客戶(hù)端發(fā)出的調用為應用級接口，而JBOSS生成的統一格式的接口稱(chēng)為系統級接口）。當轉換完成后，所有的應用級接口變成了系統級接口⑤。為了能更清楚地闡述這個(gè)問(wèn)題，我們假設客戶(hù)端向EJB對像發(fā)出如下調用：
myRemoteComponent.increaseSalary(100);
//myRemoteComponent為代理對像 |
這個(gè)調用實(shí)際上被JBOSS轉換成了如下的系統級調用：
proxyClientContainer.invoke(invocation);
//proxyClientContainer為代理對像在服務(wù)端的另一個(gè)伙伴 |
但這個(gè)invocation到底是什么呢？實(shí)際上它是類(lèi)Invocation的一個(gè)實(shí)例，這里有它的一個(gè)簡(jiǎn)單的說(shuō)明：
public class Invocation{
Object[] args; //應用級接口中的一些參數
Method method; //被調用的應用級接口
Map payload; //JBOSS就是在這里采取的負載平衡策略的
……
} |
當應用級接口被轉換成為了系統級接口之后，它將經(jīng)過(guò)一系列的攔截器（⑥至⑦）。在這里我首先要說(shuō)明一下什么是攔截器，實(shí)際上，它是JBOSS中獨具特色的一個(gè)設計思路，一個(gè)攔截器就好像是一張過(guò)濾網(wǎng)，它用來(lái)對客戶(hù)端的調用進(jìn)行攔截，并對其進(jìn)行一些處理，比如檢查客戶(hù)端調用的合法性、實(shí)現安全策略、對事務(wù)進(jìn)行支持等。值得一提的是，JBOSS的集群管理也是通過(guò)攔截器來(lái)實(shí)現的，更令人欣慰的是，JBOSS的設計者并沒(méi)有將這個(gè)攔截器固化在其核心內，而是采用一種插件式（plug-in）的方法來(lái)設計，因此你只要實(shí)現它的插件接口，你甚至可以寫(xiě)出自己的攔截器來(lái)，當然，這已不屬于本文的討論范圍之內了。
這里（⑥至⑦）的每個(gè)攔載器將順序地攔截invocation，它們都具有如下的集群管理方面的能力：
1、 分析invocation的內容和任務(wù)。
2、 加入一些信息到invocation中的payload中，以?xún)?yōu)化集群策略。
3、 讀取出放在payload中的任何可用信息。
4、 將invocation轉發(fā)到下一個(gè)攔截器中。
5、 如果發(fā)生錯誤，能夠將錯誤報告給調用者，并返回到正確的地方去。
值得注意的是最后一個(gè)攔截器，它有一些特殊，因為它才真正地執行對實(shí)際的EJB的調用⑧，它能檢測到客戶(hù)端是否和EJB對像在同一個(gè)Java虛擬機中，如果是的話(huà)，它只是簡(jiǎn)單地將這個(gè)調用直接傳給EJB對像，這樣做的原因是可以避免由于網(wǎng)絡(luò )傳輸帶來(lái)的不必要的開(kāi)銷(xiāo)，使用調用速度大大加快。
另一方面，如果客戶(hù)端與EJB不在同一個(gè)虛擬機中，那么它們就要通過(guò)網(wǎng)絡(luò )傳輸了，在這里JBOSS提供了另一個(gè)有趣的策略，就是代理對像并不知道采取的是什么傳輸協(xié)議，只有最后那個(gè)攔截器才知道真正采用的傳輸協(xié)議是什么。就目前而言，它提供了RMI/JRMP、IIOP、HTTP、SOAP等協(xié)議來(lái)進(jìn)行傳輸。
當我們設計JBOSS的集群策略時(shí)，我們還必須決定究竟要在哪兒將負載平衡以及失效轉發(fā)行激活，為此，請先看下圖：
1、 在某個(gè)服務(wù)器結點(diǎn)上發(fā)生
2、 在一個(gè)中介服務(wù)器上進(jìn)行發(fā)生
3、 在客戶(hù)端上進(jìn)行發(fā)生
上圖中的3種方案都有其利弊，但我們覺(jué)得最后一個(gè)方法要比前2個(gè)好，原因如下：
1、 與第2種方案相比，它避免了由于中介服務(wù)器失效而引發(fā)的全線(xiàn)崩潰。
2、 除非客戶(hù)端崩潰，負載平衡和失效轉發(fā)策略才會(huì )失敗。而我想應該沒(méi)有人會(huì )對此產(chǎn)生報怨的。這也沒(méi)有什么好報怨的，不是嗎？
3、 從性能方面來(lái)考慮，這種方案也是最優(yōu)的，因為所有的策略都是發(fā)生在客戶(hù)端的，省去了第1、2種方案由服務(wù)器來(lái)管理帶來(lái)的瓶頸。
因此，我們選擇了最后一種方案來(lái)做為JBOSS的集群策略。其實(shí)，只要大家再仔細回顧一下前面的部分，就會(huì )發(fā)現我們先前描述的方案不正是第3種方案嗎？但我們現在必須對這個(gè)策略在以下幾個(gè)方面做一些更深入的分析：
1、 我們必須加入真正實(shí)現負載平衡的邏輯。
2、 當客戶(hù)端發(fā)出調用時(shí)，我們應該能夠決定到底將它發(fā)送到哪個(gè)服務(wù)器節點(diǎn)上。
3、 我們希望為客戶(hù)端代理對像設計一個(gè)比較合適的服務(wù)器結點(diǎn)的拓撲圖，以便我們做出好的集群策略。
負載平衡的設計策略 前面已經(jīng)說(shuō)過(guò)，JBOSS的負載平衡與失效轉發(fā)策略是由最后一個(gè)攔截器實(shí)現的（上圖中的①），然而我們要考慮的是雖然客戶(hù)端只發(fā)出一個(gè)調用，但針對于代理對像的調用可能包含多個(gè)可用的服務(wù)器結點(diǎn)，其個(gè)數等于集群中所有有效節點(diǎn)之和（參見(jiàn)上圖中的②），那么到底是由誰(shuí)來(lái)決定這個(gè)策略的呢？這個(gè)工作由一個(gè)叫插件式的負載平衡策略來(lái)實(shí)施的（在下一段中簡(jiǎn)稱(chēng)策略①,如下圖）。
當客戶(hù)端調用到達最后一個(gè)攔截器的時(shí)候，攔截器會(huì )請求策略①來(lái)為它選擇一個(gè)服務(wù)器結點(diǎn)。如果此結點(diǎn)有效且調用成功，則結果會(huì )返回給代理對像，如果失敗了，攔截器不會(huì )直接將錯誤返回給代理對像，而是將這個(gè)錯誤信息報告給策略①，并請求它再為客戶(hù)端選擇一個(gè)新節點(diǎn)。
但還有一個(gè)問(wèn)題值得考慮的，就是對一些致命性錯誤的處理。例如某個(gè)數據庫服務(wù)器突然崩潰了，那么最后一個(gè)攔截器將無(wú)法對此進(jìn)行失效轉發(fā)了，因為不管選擇哪個(gè)服務(wù)器結點(diǎn)都不能解決這個(gè)問(wèn)題了，在這里攔截器會(huì )將錯誤報告給客戶(hù)端，并由其自已做出決定。
IT界里好像有這樣一個(gè)原理，就是"越是可擴展性強，靈活的東西實(shí)施起來(lái)就越復雜"。在JBOSS中也不例外，但幸運的是這些工作并沒(méi)為給客戶(hù)端帶來(lái)額外的編程負擔，因為所有策略的配置都是在服務(wù)器完成的。
JBOSS的集群配置遵循XML規范，下面是的一個(gè)普通EJB對像的典型集群配置：
＜jboss＞
?。糴nterprise-beans＞
?。約ession＞
?。糴jb-name＞MySessionBean＜/ejb-name＞
?。糲lustered＞True＜/clustered＞
?。糲luster-config＞
?。紁artition-name＞DefaultPartition＜/partition-name＞
?。糷ome-load-balance-policy ＞
org.jboss.ha.framework.interfaces.RoundRobin
?。?home-load-balance-policy＞
?。糱ean-load-balance-policy＞
org.jboss.ha.framework.interfaces.FirstAvailable
?。?bean-load-balance-policy＞
?。?cluster-config＞
?。?session＞
?。?enterprise-beans＞
＜/jboss＞ |
上述配置說(shuō)明了一個(gè)名為MySessionBean的會(huì )話(huà)Bean的集群策略，它定義了名為DefaultPartion的缺省策略名稱(chēng)，并定義了2個(gè)具體的策略。當然，如果你覺(jué)得它比較復雜，而只想用JBOSS缺省的集群策略的話(huà)，可以將整個(gè)＜cluster-config＞標簽去掉。
最后還有一個(gè)小問(wèn)題值得考慮：由于集群策略是發(fā)生在客戶(hù)端的，當客戶(hù)端發(fā)出調用請求時(shí)，它不得不下載它的代理對像、攔截器、負載平衡策略等等。如果要下載的內容過(guò)多，會(huì )影響客戶(hù)端的調用速度，這里JBOSS采取了一種延遲下載的方法，就是每次只下載一個(gè)必須的類(lèi)，而不是一次全部下載，這樣就能使性能得到較大的改善。
服務(wù)器結點(diǎn)拓撲圖的刷新 JBOSS的集群實(shí)現是動(dòng)態(tài)的，也就是說(shuō)你可以動(dòng)態(tài)地往集群中加入一個(gè)新節點(diǎn)或關(guān)閉任意一個(gè)節點(diǎn)，而不用費力地維護一張靜態(tài)的拓撲圖，就好像是JBOSS自己有能力管理集群一樣。這個(gè)思想夠先進(jìn)吧？但與此同時(shí)它也帶來(lái)了一些令人頭痛的問(wèn)題，請先看下圖：
由于JBOSS的集群策略是在客戶(hù)端進(jìn)行的，那么客戶(hù)端在調用EJB的時(shí)候會(huì )將所有必須的組件下載下來(lái)，然后由其進(jìn)行集群決策。如果我們設T為時(shí)間，且t0＜t1＜t2，那么當處于t0時(shí)刻時(shí)，集群拓撲圖中包含server1和server2兩個(gè)節點(diǎn)，客戶(hù)端的調用被轉發(fā)到了結點(diǎn)2上。當處于t1時(shí)刻時(shí)，server1和server2全部都崩潰了。當處于t2時(shí)刻時(shí)，管理員增加了server3和server4兩個(gè)節點(diǎn)，但客戶(hù)端的拓撲圖中還只是包含原先的server1和server2兩節點(diǎn)的信息，因為它無(wú)法知道這新加入的2個(gè)節點(diǎn)。
為了解決這個(gè)問(wèn)題，JBOSS是這樣設計的，在客戶(hù)端的每次對某個(gè)節點(diǎn)調用后，服務(wù)器節點(diǎn)自動(dòng)檢查客戶(hù)的拓撲圖是不是最新的，如果不是，則向客戶(hù)端發(fā)送新的拓撲圖，如下圖所示：
當客戶(hù)端進(jìn)行調用時(shí)，代理對像對其進(jìn)行了一個(gè)小小的包裝，它將系統級調用invocation和自已現在的拓撲圖（JBOSS開(kāi)發(fā)者稱(chēng)它為view ID）發(fā)送到服務(wù)端，而服務(wù)端則檢查它自己的view ID是否與代理對像中的view ID吻合。這里我們先簡(jiǎn)單介紹一下view ID，它實(shí)際上就是包含所有服務(wù)器節點(diǎn)的一個(gè)哈希表，至于為什么要用哈希表是因為它生成方便（java編譯器自帶）、存取快速，無(wú)須考慮排序問(wèn)題。
下面接著(zhù)講述，如果代理對像的view ID與服務(wù)端節點(diǎn)的view ID相吻合的話(huà)，服務(wù)端將直接把結果傳給EJB對像，并將結果返回。
如果服務(wù)器集群拓撲產(chǎn)生了變化，則會(huì )導致它們不吻合。這時(shí)服務(wù)器節點(diǎn)同樣也將調用EJB對像，但此時(shí)返回的結果有所不同，它除了返回客戶(hù)端的結果外，還要為代理對像返回一個(gè)最新的view ID，并通知代理對像："喂，你的拓撲圖太舊了，我發(fā)了份新的，你趕快更新一下吧！" 當代理對像收到這個(gè)消息后會(huì )更新自己的view ID，并將結果返回客戶(hù)端代碼。
性能考慮
對于JBOSS來(lái)說(shuō)，實(shí)現負載平衡與失效轉發(fā)所帶來(lái)的性能上的損失是很難計算的，因為它只發(fā)生在客戶(hù)端上，而每個(gè)客戶(hù)端不管從硬件配置、操作系統來(lái)說(shuō)都是不一樣的。
由于本文講的主要是對于無(wú)狀態(tài)的EJB對像的集群，但如果是有狀態(tài)的EJB或實(shí)體EJB，那情況會(huì )怎樣呢？答案是：情況只會(huì )更糟！為此服務(wù)器節點(diǎn)不得不進(jìn)行狀態(tài)復制，而這個(gè)開(kāi)銷(xiāo)通常是很大的，取決于狀態(tài)中上下文的內容和狀態(tài)更新的頻率。所幸的是，對于大多數應用而言，它們主要是進(jìn)行無(wú)狀態(tài)的EJB調用，這樣就不服務(wù)器節點(diǎn)就不需進(jìn)行大量狀態(tài)復制了。
結論
JBOSS為J2EE應用提供了一個(gè)非常靈活有效的集群機制。它能使得在保持服務(wù)端性能損失最小的情況下進(jìn)行失效轉發(fā)，并能動(dòng)態(tài)地對集群節點(diǎn)進(jìn)行配置。更令人振奮的是，在JBOSS4.0中，集群機制將會(huì )發(fā)揮到極致，到時(shí)候就不僅僅是J2EE應用能夠進(jìn)行集群管理了，連普通的J2SE應用都能進(jìn)行集群了，到那時(shí)高可用性的計算并不只是一句口號了，而是JBOSS的一個(gè)簡(jiǎn)單實(shí)現！
