關(guān)于J2EE應(yīng)用服務(wù)器集群簡介
J2EE應(yīng)用服務(wù)器提供商給集群下了定義, 一個集群就是一組在一起工作,顯式提供企業(yè)服務(wù)(支持JNDI,EJB,JSP, HttpSession和組件失敗轉(zhuǎn)移等等)的機器群.下面是小編整理的J2EE應(yīng)用服務(wù)器集群簡介，希望大家認(rèn)真閱讀!
負(fù)載均衡器(Load balancers):
進(jìn)入集群和通行指示器到單個Web或應(yīng)用服務(wù)器的唯一入口點
·Web servers
·網(wǎng)關(guān)路由器(Gateway routers) 在內(nèi)網(wǎng)外的的出口點.
·多層交換器(Multilayer switches)
包和幀過濾確保在集群里的每個機器僅僅收到相關(guān)機器的信息.
·防火墻(Firewalls)
集群保護器通過端口過濾防止Hackers訪問集群和內(nèi)網(wǎng)
·存儲區(qū)域網(wǎng)絡(luò)交換器(SAN---Storage Area Networking switches)
連接應(yīng)用服務(wù)器,web服務(wù)器,和數(shù)據(jù)庫到一個后端存儲媒介;
管理寫數(shù)據(jù)到物理硬盤;還有失敗轉(zhuǎn)移.
·數(shù)據(jù)庫(Databases)
不管他們是如何實現(xiàn)的,所有的集群都提供兩個好處:可伸縮性(scalability)和高可用性(high availability---HA)
可伸縮性(scalability)
伸縮性支持用戶增長時保證應(yīng)用服務(wù)質(zhì)量的能力.集群允許你依靠增加額外的服務(wù)器提供額外的容量,因而保證伸縮性.
高可用性(high availability---HA)
HA能被一個詞概括:冗余.集群使用許多的機器處理服務(wù)請求.因此,如果在集群里的任何機器失敗,另外一臺機器會直接接管.
集群僅僅在應(yīng)用服務(wù)器層提供HA.對于一個要展示真正HA的Web系統(tǒng),一定象諾亞方舟一樣至少包括Web服務(wù)器,網(wǎng)關(guān)路由器, 交換基礎(chǔ)設(shè)施,等等中的兩種.(關(guān)于HA的更多內(nèi)容,看這個HA Checklist.)
集群類型
J2EE集群通常流行兩種風(fēng)格:非共享和共享磁盤.在非共享集群里, 每個應(yīng)用服務(wù)器都有的它自己的文件系統(tǒng), 和這個集群里運行的應(yīng)用程序自己的拷貝相一致.應(yīng)用的更新和增加需要更新集群里的每個節(jié)點.當(dāng)代碼增加和更新發(fā)布時進(jìn)行配置,大的集群有惡夢般的維護.
相反,磁盤共享集群使用一個所有的應(yīng)用服務(wù)器都用的存儲設(shè)備來獲取在集群里運行的應(yīng)用.更新和增加出現(xiàn)在一個文件系統(tǒng)里,集群里的所有的機器可以訪問這些變化.直到最近才發(fā)現(xiàn), 單點失敗是這種方法的不利方面.然而,SAN給出了一個單獨的邏輯接口,通過這個接口可以進(jìn)入到一個提供失敗轉(zhuǎn)移,反饋,和伸縮性的冗余存儲中介.(關(guān)于SAN更多的內(nèi)容,看Storage Infrastructure)
當(dāng)比較J2EE應(yīng)用服務(wù)器的集群實現(xiàn)時,重要考慮:
·集群實現(xiàn)
·集群和組件失敗轉(zhuǎn)移服務(wù)
·HttpSession失敗轉(zhuǎn)移
·集群拓?fù)淅锏膯吸c失敗
·柔性拓?fù)湟?guī)劃
·維護
以后我們將看到四種流行的應(yīng)用服務(wù)器在不同領(lǐng)域如何比較,但是,首先還是讓我們更詳細(xì)的檢查所要考慮的每一項.
集群實現(xiàn)
J2EE應(yīng)用服務(wù)器在他們的JNDI(java命名和目錄接口)實現(xiàn)周圍實現(xiàn)了群集.雖然JNDI是J2EE應(yīng)用依賴的核心服務(wù),但是它很難在集群里實現(xiàn),因為它不能把多個對象綁定在單個名字上.關(guān)于每個應(yīng)用服務(wù)器的JNDI實現(xiàn)有三個普遍的群集方法.
·獨立的
·中央集中的
·全局共享的
獨立JNDI樹
HP Bluestone Total-e-Server 和SilverStream Application Server利用了一個適合于每個應(yīng)用服務(wù)器的獨立JNDI樹.在一個獨立JNDI樹的集群里成員服務(wù)器不知道或不關(guān)心集群里其他服務(wù)的存在.因此,不支持失敗轉(zhuǎn)移或者通過重定向HTTP或EJB請求的媒介服務(wù)提供支持.配置媒介服務(wù),使他們知道集群里每個組件都駐留在哪里和萬一失敗發(fā)生如何得到一個替代的組件.
獨立JNDI樹的集群它的一個優(yōu)點:更短的集群收斂時間和靈活的伸縮.集群收斂衡量了集群完全知道集群里所有的機器和相關(guān)對象的時間.然而, 在一個獨立JNDI樹的集群里收斂(Convergence)并不是一個要關(guān)心的問題,因為集群在兩臺機器一啟動就完成了收斂(Convergence).獨立的JNDI樹的其他優(yōu)點:伸縮僅僅需要需要增加額外的服務(wù)器.
然而,也存在幾個弱點.首先,失敗轉(zhuǎn)移通常是開發(fā)者的責(zé)任. 也就是說,因為每個應(yīng)用服務(wù)器的JNDI樹都是獨立的,所以通過JNDI重新找到的遠(yuǎn)程代理被固定到已出現(xiàn)的lookup服務(wù)器上.在這種情況下,如果調(diào)用EJB的一個方法失敗了,開發(fā)者必須寫額外的代碼連接到分發(fā)器來獲得另外一個活動服務(wù)器的地址,做另外一次JNDI查找,再一次調(diào)用已失敗的方法. Bluestone實現(xiàn)了一個更復(fù)雜的獨立JNDI樹的形式,就是每個請求都經(jīng)過EJB代理服務(wù)或者代理LBB (Load Balance Broker).EJB代理服務(wù)保證每個EJB請求都進(jìn)入一個活動的UBS實例.這種方案對每個請求都添加了額外的反應(yīng)時間,但是在方法調(diào)用之間允許自動的失敗轉(zhuǎn)移.
中央集中JNDI樹
Sybase企業(yè)應(yīng)用服務(wù)器實現(xiàn)了一個中央集中JNDI樹的集群.根據(jù)這種設(shè)置,中央集中的JNDI樹利用了CORBA的CosNaming服務(wù).命名服務(wù)器收容了集群的中央集中的JDNI樹,清楚哪個服務(wù)器出事了.剛一啟動,集群里的每個服務(wù)器就綁定它的對象到它的JNDI樹和所有的命名服務(wù)器.
在一個中央集中JNDI樹的集群里獲得一個EJB的引用需要兩個步驟.首先,客戶端從命名服務(wù)器查找一個home對象,返回一個互操作對象引用(IOR).一個IOR指向集群里活動的具有home對象的幾臺機器.第二,客戶端挑選出定位在IOR里的第一個服務(wù)器,得到home和remote.如果在EJB方法調(diào)用之間出現(xiàn)失敗,CORBA stub實現(xiàn)了重新獲得另外一個home或者remote的邏輯.這個home或者remote來自從命名服務(wù)器返回的IOR里列出的一個替代服務(wù)器.
命名服務(wù)器本身就證實了中央集中JNDI樹集群的一個弱點.如果你有特定的50臺機器的集群,之中有5臺是命名服務(wù)器,如果5臺命名服務(wù)器都down掉了,那么這個集群就變的沒什么用了.當(dāng)然,另外45臺機器能運行,但是當(dāng)命名服務(wù)器down了,這個集群將不能為一個EJB客戶端服務(wù).
如果集群原先的命名服務(wù)器全部發(fā)生了失敗, 在線引進(jìn)一個額外的命名服務(wù)器就會出現(xiàn)另一個問題. 假如這樣做的話,一個新的中央集中命名服務(wù)器就需要集群里每個活動機器綁定它的對象到新的命名服務(wù)器的JNDI樹.雖然當(dāng)綁定過程發(fā)生時開始收到請求是可能的,但不推薦這樣做,因為綁定過程延長了集群的恢復(fù)時間.此外,來自一個application或者applet的JNDI lookup,事實上出現(xiàn)了兩次網(wǎng)絡(luò)調(diào)用.第一個調(diào)用從命名服務(wù)器重新獲得一個對象的IOR,第二的調(diào)用從IOR里指定的一個服務(wù)器那重新獲得客戶端想要的對象.
最后,當(dāng)集群數(shù)量增長時中央集中JNDI樹的集群承擔(dān)收斂(Convergence)所帶來的增加時間.就是說當(dāng)你伸縮你的集群時,你必須增加更多的命名服務(wù)器. 緊記命名服務(wù)器所在的機器和全部的集群機器通常公認(rèn)的比率是1:10,兩個命名服務(wù)器是最小數(shù)目.因此,如果你有一個10臺機器的集群和兩臺命名服務(wù)器,在服務(wù)器和命名服務(wù)器之間綁定的總數(shù)能達(dá)到20,在一個40臺機器的集群和四臺命名服務(wù)器里,會有160個綁定關(guān)系.每個綁定都表示其中一個成員服務(wù)器綁定所有的對象到一個命名服務(wù)器的JNDI樹的過程.記住,中央集中JDNI樹的集群在所有的JNDI集群實現(xiàn)之間具有更糟糕的收斂時間(Convergence time).
全局共享JNDI樹
最后,BEA Weblogic實現(xiàn)了一個全局共享的JNDI樹.用這種方式,當(dāng)集群里的一個服務(wù)器啟動時,通過IP廣播宣布它的存在并且把JNDI樹通知給集群里的其它服務(wù)器.群集里的每個機器既綁定它的對象到全局共享JNDI樹,又綁定到它自己的本地JNDI樹.
在每個成員服務(wù)器里都擁有一個全局的和本地的JNDI樹,允許生成的home和remote stubs失敗轉(zhuǎn)移,并且提供很快的進(jìn)程里的JNDI lookups. 全局共享JNDI樹在集群里的所有機器之間都是共享的,允許任何成員機器知道集群里所有對象的精確位置.如果在集群里的多個機器上對象是可用的,一個特殊的home對象被綁定到全局共享JNDI樹.這個特殊的home知道所有EJB對象和與它相關(guān)聯(lián)對象的位置, 也生成知道所有EJB對象和與它相關(guān)聯(lián)對象的位置的remote對象.
全局共享方式的主要不利方面：當(dāng)服務(wù)器啟動時所產(chǎn)生的大量網(wǎng)絡(luò)初始化傳輸和集群的過分收斂時間(Convergence time).相反,在一個獨立JNDI樹的集群里, 由于沒有JNDI共享信息出現(xiàn),所以收斂并不被看做是個問題.然而,對集群里所有機器來說, 一個全局共享或者中央集中的集群,建立全局共享或者中央集中JNDI樹都需要花費時間. 實際上,因為全局共享集群使用廣播傳輸JNDI信息,建立全局共享JNDI樹所需的時間與以后增加的服務(wù)器數(shù)相比是線性相關(guān)的.
全局共享與中央集中JNDI樹的集群相比主要的好處集中在自由伸縮和高可用性.使用全局共享,你就不必在專門的命名服務(wù)器上亂動CPU和RAM,不必在集群里調(diào)整命名服務(wù)器的數(shù)目.當(dāng)然,為了伸縮應(yīng)用程序,僅僅增加更多的機器就可以.此外,如果集群里的一些機器down掉了,集群將完全繼續(xù)起作用.最后,和在中央集中JNDI樹的集群里每個remote lookup都需要兩個網(wǎng)絡(luò)調(diào)用相比, 每個remote lookup都只需要一個單一的網(wǎng)絡(luò)調(diào)用.
所有這些都應(yīng)該打個折扣,不可全信.因為運行在應(yīng)用服務(wù)器上的JSPs,servlets,EJBs,和JavaBeans可以共處在EJB服務(wù)器里.他們總是使用一個進(jìn)程里的JNDI lookup.緊記,如果你只運行服務(wù)器端(server-side)應(yīng)用,那么在獨立的,中央集中的,或者全局共享的集群實現(xiàn)幾乎沒有什么差別. 實際上,每個HTTP請求在應(yīng)用服務(wù)器上都將結(jié)束,因為應(yīng)用服務(wù)器將使用進(jìn)程里的JNDI lookup返回你server-side服務(wù)器里使用的一些對象.
集群和失敗轉(zhuǎn)移服務(wù).
在一臺機器上提供J2EE服務(wù)與通過集群提供相同的服務(wù)相比是微不足道,價值不高的.由于集群的復(fù)雜性,每個應(yīng)用服務(wù)器都以統(tǒng)一的方法實現(xiàn)群集組件.你應(yīng)當(dāng)理解提供商如何實現(xiàn)entity beans, stateless session beans, stateful session beans, 和JMS的群集和失敗轉(zhuǎn)移.許多提供商聲稱支持群集組件,但是他們所做的定義通常意味著涉及集群里運行的組件.例如,BEA WebLogic Server 5.1支持群集stateful session beans但是如果bean實例所在的服務(wù)器失敗,bean的所有狀態(tài)都將丟失.客戶端然后將必須重新創(chuàng)建和重新駐留,在集群里這么做是沒用的.直到BEA WebLogic 6.0, stateful session beans才使用內(nèi)存復(fù)制來處理失敗轉(zhuǎn)移和群集.
所有的應(yīng)用服務(wù)器都支持EJB群集,但是在可配置的自動失敗轉(zhuǎn)移方面存在著非常大的差別.實際上,一些應(yīng)用服務(wù)器依靠EJB客戶端的一些條件,不支持自動的失敗轉(zhuǎn)移.例如, Sybase Enterprise Application Server通過你從數(shù)據(jù)庫或者系列化裝載bean的狀態(tài)來支持stateful session bean失敗轉(zhuǎn)移.就象上面提到的那樣, BEA WebLogic 6.0通過stateful session bean狀態(tài)的內(nèi)存復(fù)制支持stateful session bean的失敗轉(zhuǎn)移.大多數(shù)應(yīng)用服務(wù)器可以在集群里運行JMS,但是不具有個別命名的主題(Topics)和隊列(Queues)負(fù)載均衡或失敗轉(zhuǎn)移,記住,你可能需要購買一個JMS的可群集實現(xiàn).比如說通過購買SonicMQ獲得Topics和Queues的負(fù)載均衡.
現(xiàn)在,我們轉(zhuǎn)到另外一個重要考慮的事情: HttpSession失敗轉(zhuǎn)移.
HttpSession失敗轉(zhuǎn)移
當(dāng)客戶端在原始的服務(wù)器上建立的一個session失敗時,HttpSession失敗轉(zhuǎn)移允許客戶端從集群里的其他服務(wù)器無縫的取得session信息. BEA WebLogic Server實現(xiàn)了session信息的內(nèi)存復(fù)制,而HP Bluestone Total-e-Server有個為HA所做的備份,利用了一個中央集中session服務(wù)器. SilverStream Application Server和Sybase Enterprise Application Server利用一個所有應(yīng)用服務(wù)器都要讀寫的中央集中數(shù)據(jù)庫或者文件系統(tǒng).
數(shù)據(jù)庫/文件系統(tǒng)session持久性的主要缺點集中在當(dāng)存儲大的或者眾多的HttpSession對象時受限的伸縮性.一個用戶每次增加一個對象到HttpSession,在session里的所有對象都被系列化寫到一個數(shù)據(jù)庫或者共享文件系統(tǒng).大多數(shù)利用了數(shù)據(jù)庫session持久性的應(yīng)用服務(wù)器提倡最小限度的使用HttpSession存儲對象,但是這限制了你web應(yīng)用的架構(gòu)和設(shè)計,尤其如果你正在使用HttpSession來存儲緩存的用戶數(shù)據(jù).
基于內(nèi)存的session持久性把內(nèi)存里的session信息存儲到備份服務(wù)器.這種方法存在兩種變化.第一個方法把HttpSession信息寫到一個中央集中的狀態(tài)服務(wù)器.集群里的所有機器把它們的HttpSession對象寫到這個服務(wù)器.在第二種方法里,每個集群節(jié)點選擇一個任意備份節(jié)點來存儲內(nèi)存里的session信息.用戶每次增加一個對象到HttpSession,那個對象獨自被序列化,然后從內(nèi)存里添加到一個備份服務(wù)器.
在這些方法中,如果集群里的服務(wù)器數(shù)低的話,這個專門的狀態(tài)服務(wù)器證明了比內(nèi)存復(fù)制到一個任意的備份服務(wù)器更好,因為為了事務(wù)處理和動態(tài)頁面生成,它釋放了CPU周期.
另一方面,當(dāng)集群里的機器數(shù)變大時,這個專門的狀態(tài)服務(wù)器會成為瓶頸,當(dāng)你增加更多的服務(wù)器時,內(nèi)存復(fù)制到一個任意的備份服務(wù)器(相對于一個專門的狀態(tài)服務(wù)器來說)將線形伸縮.此外,當(dāng)你在集群里增加更多的機器時,也需要你增加更多的RAM和CPUs來持續(xù)的調(diào)整這個狀態(tài)服務(wù)器.對于內(nèi)存復(fù)制到一個任意的備份服務(wù)器來說,你只需添加更多的機器,sessions可以均勻的把自己分布到集群里的所有機器上.
基于內(nèi)存的持久性提供了柔性的web應(yīng)用設(shè)計,伸縮性和高可用性.
我們已經(jīng)解決了HttpSession的失敗轉(zhuǎn)移, 現(xiàn)在我們將研究單點失敗(single points of failure)
單點失敗(single points of failure)
沒有備份的集群服務(wù)以單點失敗而聞名.他們會引起整個集群或你的部分應(yīng)用失敗.例如, WebLogic JMS可以在集群里的單機上只有一個運行的Topic. 你的應(yīng)用依賴JMS Topics,如果那臺機器發(fā)生死機,你的集群將down掉直到另外一個WebLogic實例和那個JMS Topics一起啟動. (注意:當(dāng)開始新的實例時, 只有持久信息將被發(fā)送.)
問問自己你的集群是否具有單點失敗,如果有的話,你需要估計基于你應(yīng)用的需求,是否可以忍受它們.
【J2EE應(yīng)用服務(wù)器集群簡介】相關(guān)文章：
J2EE應(yīng)用服務(wù)器03-29
J2EE技術(shù)簡介03-20
什么是J2EE03-16
j2ee介紹03-20
J2EE的概念03-19