J2EE application server的供應(yīng)商把集群定義為一組計(jì)算機(jī)一起工作，提供透明的企業(yè)級(jí)服務(wù)(支持JNDI, EJB, JSP, HttpSession,組件差錯(cuò)恢復(fù)等).他們故意定義得很模糊,因?yàn)樗麄儗?duì)它的實(shí)現(xiàn)各不相同.一部分開發(fā)商在一組互相獨(dú)立的機(jī)器前端放置一個(gè)dispatcher,dispatcher接受用戶的請(qǐng)求,然后用HTTP redirect header將請(qǐng)求轉(zhuǎn)到集群中一臺(tái)特定的server上.另一部分開發(fā)商則實(shí)現(xiàn)了一個(gè)緊密集成在一起的機(jī)器聯(lián)合,每臺(tái)機(jī)器能完全感知它周圍其它機(jī)器的存在,連同駐在它們之上的對(duì)象.

除了機(jī)器方面的集成,集群還包含冗余和出錯(cuò)恢復(fù):

• 負(fù)載平衡器:進(jìn)入集群的單一的入口點(diǎn),站點(diǎn)或application server的流量指示器
• 網(wǎng)關(guān)路由器:內(nèi)部網(wǎng)絡(luò)的出口點(diǎn)
• 多層交換器:包過(guò)濾或幀過(guò)濾,確保每臺(tái)機(jī)器僅收到和自己相關(guān)的信息
• 防火墻:端口級(jí)別過(guò)濾,防止hacker進(jìn)入集群或內(nèi)部網(wǎng)絡(luò)
• SAN (Storage Area.NETworking)控制器:把a(bǔ)pplication servers, Web servers和databases連接到后端存儲(chǔ)介質(zhì),管理數(shù)據(jù)該寫到哪個(gè)硬盤;以及出錯(cuò)備份
• 數(shù)據(jù)庫(kù)

無(wú)論怎樣實(shí)現(xiàn),集群都提供兩大主要功能:可伸縮性和高可靠性(HA).

可伸縮性

可伸縮性是指一個(gè)應(yīng)用程序能支持不斷增長(zhǎng)的用戶數(shù)量的能力.集群通過(guò)增加server來(lái)提供額外的工作能力,從而保證了可伸縮性.

高可靠性

HA可用一個(gè)詞概括:冗余(redundancy).一個(gè)集群用很多機(jī)器服務(wù)請(qǐng)求, 因此,即使一臺(tái)機(jī)器崩潰了,其它機(jī)器也可透明地接過(guò)任務(wù).

集群僅在application server層提供高可靠性. 對(duì)一個(gè)網(wǎng)絡(luò)系統(tǒng)來(lái)說(shuō),要表現(xiàn)真正的HA,必須像諾亞方舟(Noah's ark)一樣每種東西提供兩件,包括Web servers,網(wǎng)關(guān)路由器,交換結(jié)構(gòu)等.

集群種類

J2EE集群通常采取兩種方法: 不共享集群(shared-nothing cluster),和共享存儲(chǔ)集群.在不共享集群中,每個(gè)application server有自己的文件系統(tǒng)和在集群中運(yùn)行的應(yīng)用的copy.應(yīng)用程序的升級(jí)需要更新集群中的每個(gè)節(jié)點(diǎn).這種設(shè)置對(duì)大的集群而言,維護(hù)就像一場(chǎng)噩夢(mèng),尤其是當(dāng)代碼需要更新時(shí).

相反,共享存儲(chǔ)集群公用一個(gè)存儲(chǔ)設(shè)備,每個(gè)application servers從那里獲得運(yùn)行的application.更新只在一個(gè)文件系統(tǒng)中進(jìn)行,所有機(jī)器能訪問(wèn)到這些變化.直到現(xiàn)在,單點(diǎn)失敗(single-point of failure)仍是它的弱點(diǎn).然而,SAN提供一個(gè)到冗余存儲(chǔ)介質(zhì)的單一的邏輯接口,以便進(jìn)行出錯(cuò)恢復(fù), 出錯(cuò)回退和可伸縮性.(欲詳細(xì)了解SAN, 參見(jiàn)Storage Infrastructure.)

比較J2EE application server的集群技術(shù)實(shí)現(xiàn),最重要的是考慮一下因素:

• 集群的實(shí)現(xiàn)
• 集群和組件的出錯(cuò)恢復(fù)
• HttpSession的出錯(cuò)恢復(fù)
• 集群拓?fù)涞膯吸c(diǎn)失敗
• 可變的拓?fù)浣Y(jié)構(gòu)
• 維護(hù)

以后我們將在不同的方面比較四個(gè)流行的application server的集群技術(shù),但首先,我們先仔細(xì)探討一下各要素.

集群的實(shí)現(xiàn)

J2EE application server在實(shí)現(xiàn)JNDI(Java Naming and Directory Interface)的基礎(chǔ)上實(shí)現(xiàn)集群.盡管JNDI是J2EE應(yīng)用程序依賴的核心,在集群中卻很難實(shí)現(xiàn),因?yàn)椴荒馨讯鄠€(gè)對(duì)象bind到一個(gè)JNDI名字上.依據(jù)不同application server JNDI的實(shí)現(xiàn),有三種集群的方法:

• 獨(dú)立的(Independent)
• 集中的(Centralized)
• 全局共享(Shared global)

獨(dú)立的JNDI tree

HP Bluestone Total-e-Server和SilverStream Application Server在每個(gè)application server中使用獨(dú)立的JNDI tree.JNDI tree的server成員并不知道和關(guān)心集群中其它server的存在.因此,差錯(cuò)恢復(fù)要么不支持,要么通過(guò)一個(gè)重定向HTTP或EJB request的中間服務(wù)支持.這些中間服務(wù)經(jīng)過(guò)配置可知道每個(gè)組件在集群中的位置,并知道萬(wàn)一出現(xiàn)錯(cuò)誤哪里有替代品.

獨(dú)立JNDI tree集群的一個(gè)優(yōu)點(diǎn)是: 集群集中度(convergence)更短,伸縮簡(jiǎn)便.集群集中度衡量的是集群完全感知所有成員和其上的對(duì)象的時(shí)間指標(biāo).然而,集中度在獨(dú)立JNDI tree集群并不是問(wèn)題,一旦兩臺(tái)機(jī)器啟動(dòng)起來(lái),集群就能獲知集中度. 另一個(gè)優(yōu)點(diǎn)是: 可伸縮性只要額外的機(jī)器參與就行.

但是,也存在著缺點(diǎn).首先,出錯(cuò)恢復(fù)通常是開發(fā)者的責(zé)任.故,由于每種application server的JNDI tree是獨(dú)立的,通過(guò)JNDI查詢得到的remote Proxy被綁定到查詢發(fā)生時(shí)的那臺(tái)server上,這樣,如果EJB的這次調(diào)用失敗了,開發(fā)者需要寫額外的代碼連接dispatcher,獲取另一臺(tái)有效的server的地址,再進(jìn)行一次JNDI查詢,重新調(diào)用剛才失敗的方法.Bluestone實(shí)現(xiàn)了一種更為復(fù)雜的形式,每個(gè)請(qǐng)求都通過(guò)一個(gè)EJB proxy服務(wù),稱作Proxy LBB (Load Balance Broker).EJB proxy服務(wù)保證每個(gè)請(qǐng)求都發(fā)往活動(dòng)的UBS實(shí)例.這樣引入了額外的延遲,但是自動(dòng)執(zhí)行了出錯(cuò)恢復(fù).

集中式JNDI tree

Sybase Enterprise Application Server實(shí)現(xiàn)的就是集中的JNDI tree集群.集中的JNDI tree集群對(duì)JNDI采用Corba的CosNaming服務(wù).Name server中駐有集中式JNDI tree,跟蹤哪個(gè)server啟動(dòng)了.每個(gè)server在啟動(dòng)時(shí),把object bind到自己的JNDI tree中,同時(shí)也bind到所有的name server中的JNDI tree.

這種模式下獲得EJB的引用分兩個(gè)步驟.首先,用戶從name server查詢home object, 前者返回一個(gè)可互作用的對(duì)象引用(interoperable object reference IOR). IOR指向幾個(gè)活動(dòng)的含有該home object的server. 然后,用戶用第一個(gè)server獲得home和remote.如果EJB方法調(diào)用中出現(xiàn)錯(cuò)誤,CORBA stub負(fù)責(zé)實(shí)現(xiàn)獲得另一臺(tái)機(jī)器(列于IOR中)上的邏輯.

name server本身是這種方式下的一個(gè)弱點(diǎn).舉例來(lái)說(shuō),如果一個(gè)集群中有50臺(tái)機(jī)器,其中5臺(tái)為name server. 如果每個(gè)name server都不可用的話,集群就沒(méi)用了.實(shí)際上,另45臺(tái)機(jī)器都是好的,但整個(gè)集群將不處理任何EJB 請(qǐng)求.

當(dāng)集群中所有的name server都崩潰了,就需要另一臺(tái)機(jī)器馬上扮演name server的角色,由此產(chǎn)生了另一個(gè)問(wèn)題.這種情況下,新的name server要求集群中所有活動(dòng)的機(jī)器把自己的對(duì)象bind到其上的JNDI tree.盡管bind 過(guò)程中接受請(qǐng)求未嘗不可,但建議不要這樣.binding過(guò)程延長(zhǎng)了集群的恢復(fù)時(shí)間.而且,每個(gè)JNDI查詢實(shí)際上代表兩個(gè)網(wǎng)絡(luò)調(diào)用,一個(gè)從name server獲取IOR,而第二個(gè)從IOR指定的server獲取object.

最后,當(dāng)集中式JNDI tree集群擴(kuò)大規(guī)模時(shí),它的集中度時(shí)間也越來(lái)越長(zhǎng).擴(kuò)大規(guī)模時(shí),必須增加越來(lái)越多的name server. 記住name server和整個(gè)集群機(jī)器的一般可接受比例是1:10, 且至少有兩臺(tái)name server.因此,如果你的集群有10臺(tái)機(jī)器,兩臺(tái)為name server,總共就有20個(gè)bind. 40臺(tái)機(jī)器的集群,有4臺(tái)name server, 就有160個(gè)bind. 每個(gè)bind代表一臺(tái)成員server把它上面所有對(duì)象bind到name server的JNDI tree上的一個(gè)過(guò)程.這樣,集中式JNDI tree集群的集中度在所有實(shí)現(xiàn)中是最差的.

全局共享式JNDI tree

最后, BEA WebLogic實(shí)現(xiàn)的是全局共享式JNDI tree. 這種方式下,當(dāng)集群中的一臺(tái)機(jī)器啟動(dòng)時(shí),它通過(guò)IP組播宣布它的存在和它的JNDI tree.每臺(tái)server把對(duì)象bind到自己本地的JNDI tree的同時(shí),還bind到一個(gè)共享的全局JNDI tree.

把JNDI tree分為全局的和本地的,生成的home和remote stub就能出錯(cuò)恢復(fù),并提供快捷的過(guò)程中(in-process)JNDI查詢.全局JNDI tree在每個(gè)成員中共享,每個(gè)成員都能知道集群中每個(gè)對(duì)象的確切地址.如果哪個(gè)對(duì)象在兩臺(tái)以上的機(jī)器上,一個(gè)特殊的home object被bind到全局JNDI tree上.這個(gè)home知道它關(guān)聯(lián)的所有 EJB object的位置,生成的remote object也同樣知道所有的位置.

全局共享的主要缺陷在于:網(wǎng)絡(luò)流量在server啟動(dòng)初始化時(shí)非常大,集群集中度也很大.相反,在獨(dú)立的JNDI tree集群中,這并不是問(wèn)題,因?yàn)闆](méi)有JNDI信息共享.而全局共享式或集中式集群在簡(jiǎn)歷共享或集中式JNDI tree時(shí)要花費(fèi)時(shí)間.實(shí)際上,由于全局共享集群采用組播傳遞JNDI信息,建立全局JNDI tree的時(shí)間是隨server線性增長(zhǎng)的.

全局共享式較集中式JNDI tree而言,主要的優(yōu)勢(shì)在于:集群實(shí)現(xiàn)主要致力于伸縮的易實(shí)現(xiàn)性和更高的可靠性. 通過(guò)全局共享,你不必改動(dòng)name server的cpu和RAM,或者調(diào)節(jié)集群中的name server數(shù)量.想擴(kuò)展應(yīng)用規(guī)模,增加server就行.而且,如果哪臺(tái)崩潰了,集群仍能很好地工作.最后,每個(gè)遠(yuǎn)程查詢只要一個(gè)網(wǎng)絡(luò)調(diào)用就完成了,相比集中式的兩個(gè)而言就省多了.

由于JSP,servlet,EJB和JavaBean最好能同時(shí)駐扎在一臺(tái)application server上, 它們總是使用進(jìn)程中JNDI查詢.記住如果你僅僅運(yùn)行服務(wù)器端的應(yīng)用,三種方式?jīng)]什么區(qū)別. 事實(shí)上,每個(gè)HTTP請(qǐng)求在application server中做進(jìn)程中JNDI查詢,返回應(yīng)用中調(diào)用的對(duì)象.

接著,我們將注意力集中到J2EE application server的第二大考慮因素:集群和出錯(cuò)恢復(fù)服務(wù).