面向j2ee的負載平衡技術(shù)

面向j2ee的負載平衡技術(shù)

1靈活性和高靈活性隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)軟件的伸縮性和可用性得到了越來越多的關(guān)注。負載平衡和容錯是這兩個問題的典型解決方案。隨著操作系統(tǒng)或網(wǎng)絡(luò)層負載平衡的廣泛應(yīng)用，支持負載平衡的中間件服務(wù)形式的問題越來越普遍。與在操作系統(tǒng)或網(wǎng)絡(luò)層實現(xiàn)負載平衡相比，在中間件層實現(xiàn)負載平衡的優(yōu)勢在于它提供了很大的靈活性，這主要體現(xiàn)在應(yīng)用（負載）類型上。目前，j2ue和corba（基于應(yīng)用的負載平衡器）等主導中間件的技術(shù)提供了支持負載平衡的需求，并提供了各種負載平衡算法和負載計量標準的選擇。然而，傳統(tǒng)的實現(xiàn)僅支持單個負載平衡點和負載平衡粒度，并不能適應(yīng)不同的應(yīng)用環(huán)境。本文首先討論了j2e平臺上的負載平衡的一些問題，分析了不同負載平衡策略的各自應(yīng)用，然后詳細描述了產(chǎn)品化應(yīng)用服務(wù)器apk阿什的實現(xiàn)。PKUAS是一種符合J2EE1.3規(guī)范的反射式構(gòu)件運行支撐平臺.PKUAS基于JMX實現(xiàn)了微內(nèi)核的體系結(jié)構(gòu),支持四類容器系統(tǒng)(無態(tài)會話容器、有態(tài)會話容器、實體容器和消息驅(qū)動容器)與三種互操作協(xié)議(IIOP(InternetInter-OrbProtocol)、JRMP(JavaRemotemethodProtocol)與SOAP(SimpleObjectAccessProtocol)),并內(nèi)置了命名服務(wù)、安全服務(wù)、事務(wù)服務(wù)、日志服務(wù)、數(shù)據(jù)連接服務(wù)與集群服務(wù).2實現(xiàn)負載平衡的方案J2EE平臺以集群的形式同時為負載平衡與容錯提供支持.J2EE集群由一組應(yīng)用服務(wù)器組成,透明地為客戶提供企業(yè)級服務(wù).集群又稱為組,這是因為集群一般使用組通信進行成員管理,并保持各節(jié)點狀態(tài)的同步.這里所說的狀態(tài)既包括實現(xiàn)負載平衡需要的對象(引用)的副本,也包括實現(xiàn)容錯所需的會話狀態(tài)等.為支持企業(yè)級計算,J2EE平臺采用了分層的體系結(jié)構(gòu).相應(yīng)的,可以在不同層上實現(xiàn)負載平衡:(1)Web層的負載平衡常見方案有:(a)DNS輪循法,即由DNS服務(wù)器維護域名與一組(集群內(nèi)節(jié)點的)IP地址的映射,對于每一個域名解析請求,DNS服務(wù)器依次選擇列表中的下一個IP地址返回;(b)硬件負載均衡器法,即整個集群對外而言只有一個IP地址(即均衡器的地址),所有請求都發(fā)往該地址,由均衡器根據(jù)選定的負載平衡算法轉(zhuǎn)發(fā)請求;(c)Web服務(wù)器代理法,即由Web服務(wù)器(可以實現(xiàn)為HTTP服務(wù)器上的插件)或部署于其上的Web應(yīng)用實現(xiàn)對Servlet/JSP請求的負載平衡.(2)EJB(EnterpriseJavaBeans)層的負載平衡由J2EE應(yīng)用服務(wù)器通過增強命名服務(wù)與通信服務(wù)實現(xiàn)對EJB及公共服務(wù)(如JNDI(JavaNamingandDirectoryInterface)、JDBC(JavaDataBaseConnectivity)、JMS(JavaMessageService)等)的負載平衡.(3)數(shù)據(jù)層的負載平衡一些數(shù)據(jù)庫供應(yīng)商提供數(shù)據(jù)庫集群產(chǎn)品,支持不同數(shù)據(jù)庫服務(wù)器間的數(shù)據(jù)復制,透明(相對于使用數(shù)據(jù)庫的Web服務(wù)器與EJB服務(wù)器)地實現(xiàn)了JDBC連接在不同數(shù)據(jù)庫節(jié)點間的負載平衡.本文主要關(guān)注EJB層的負載平衡.2.1對象引用與執(zhí)行流程EJB層的負載平衡決策可以在不同位置做出,如負載均衡器、應(yīng)用服務(wù)器(JNDI命名服務(wù)器、容器等)以及客戶代理(homestub與remotestub)等.由負載均衡器轉(zhuǎn)發(fā)請求的方案(圖1)有明顯的缺陷.首先,為了避免單點失效與性能瓶頸,一般都使用幾個負載均衡器.然而即便如此,仍然不能避免所有均衡器均失效而導致系統(tǒng)癱瘓(即使服務(wù)節(jié)點仍可用)的情況.此外由于每次請求都需由均衡器轉(zhuǎn)發(fā),不可避免的會帶來性能開銷.為了克服上述缺點,本文提出了一種由命名服務(wù)實現(xiàn)負載平衡的方案(圖2).命名服務(wù)維護了JNDI名與一組對象引用(或客戶代理)的映射,在執(zhí)行查找請求時根據(jù)一定的負載平衡算法選擇一個特定于某個節(jié)點的對象引用返回給客戶.由于命名服務(wù)位于集群的每個節(jié)點上,一般不會出現(xiàn)上述的第一種情況.同時由于無需第三方轉(zhuǎn)發(fā)請求,因而降低了性能開銷.當然,由此帶來的一個問題是僅能支持較粗粒度的負載平衡(見2.2節(jié)).這種方案的優(yōu)點是實現(xiàn)比較簡單,運行時刻開銷小.此外,由于命名服務(wù)比較容易獲取全局信息(如各節(jié)點的負載狀況),因而易于實現(xiàn)動態(tài)負載平衡算法.服務(wù)器端負載平衡還可由容器或通信服務(wù)中的接收器實現(xiàn),但這種做法進一步加重了服務(wù)器的負擔,一般很少采用.上述兩種方案的共同之處是由服務(wù)器實現(xiàn)負載平衡(負載均衡器也應(yīng)視為一種服務(wù)器),這意味著隨著客戶數(shù)量的增加,服務(wù)器用于負載平衡的開銷也會相應(yīng)增加.對于以事務(wù)處理為主的應(yīng)用領(lǐng)域(如CORBA應(yīng)用),由于并發(fā)客戶數(shù)較少且客戶請求的處理時間較長(因而負載平衡開銷所占的比例較小),這類方案是合適的.而對于基于Web的應(yīng)用領(lǐng)域,常常需要面對大量客戶,并且所處理的多為交互式請求,則需要考慮降低服務(wù)器用于負載平衡的開銷.正是由于上述原因,由客戶代理轉(zhuǎn)發(fā)請求(圖3)成為J2EE平臺上最廣泛采用的實現(xiàn)機制.客戶代理維護了一組對象引用,其內(nèi)封裝了部署了相應(yīng)EJB或提供相應(yīng)服務(wù)的一組節(jié)點的地址.每次方法調(diào)用中,客戶代理根據(jù)選定的負載平衡算法及其它信息(如各節(jié)點的負載)選擇一個對象引用,向相應(yīng)的節(jié)點發(fā)出請求.這種實現(xiàn)機制的優(yōu)點是(1)具有較好的可伸縮性.由于負載平衡開銷主要由客戶負擔,服務(wù)器無需考慮由于客戶數(shù)量增加引起的負載平衡開銷的增加;(2)支持細粒度的負載平衡(見2.2小節(jié)).然而,客戶代理需要從服務(wù)器獲取必要的信息以及細粒度負載平衡都意味著運行時刻開銷的增加.此外,需要為每一種互操作協(xié)議開發(fā)支持負載平衡的客戶代理也意味著實現(xiàn)難度的增加.考慮到2、3兩種方案各有特定的適用環(huán)境,PKUAS同時實現(xiàn)了兩種方案.本文將在第三部分詳細描述實現(xiàn)細節(jié).2.2ejb負載平衡粒度客戶使用EJB的一次典型流程如圖4所示.首先,客戶從命名服務(wù)查找home對象,得到其客戶代理(homestub).而后客戶通過homestub調(diào)用home對象的create方法,創(chuàng)建一個remote對象,得到remote對象的客戶代理(remotestub).最后客戶通過remotestub調(diào)用remote對象的某個方法,完成實際的業(yè)務(wù)操作.本文認為,對于EJB而言存在以下三種負載平衡粒度:(1)查找級(perlookup)向一個home對象以及該home對象創(chuàng)建的所有remote對象發(fā)出的請求都由一個固定的節(jié)點處理,僅支持同一個EJB的不同home對象及不同EJB的負載平衡.其效果可由上述的命名服務(wù)轉(zhuǎn)發(fā)請求實現(xiàn),故名.(2)會話級(persession)向home對象發(fā)出的不同請求可以負載平衡,而向remote對象發(fā)出的請求則始終由創(chuàng)建該對象的節(jié)點處理.有態(tài)會話構(gòu)件一般只能做到這一級,故名.(3)請求級(perrequest)home與remote對象的請求都可以負載平衡.一般只有無態(tài)會話構(gòu)件與只讀實體構(gòu)件能做到這一級.盡管會話狀態(tài)復制為有態(tài)會話構(gòu)件的請求級負載平衡提供了支持,但是考慮到性能開銷,在實際應(yīng)用中會話狀態(tài)復制一般僅用于需要支持容錯的情況.從級別1到級別3,負載平衡粒度逐漸變細.一般來說,粒度越細,負載平衡效果越好,但運行時開銷也越大.2.1小節(jié)提到的方案2支持查找級,方案3支持會話級與請求級.本文將在第三部分描述這三種負載平衡粒度在PKUAS中的實現(xiàn)與定制方法.2.3動態(tài)算法與靜態(tài)加權(quán)根據(jù)決策時是否使用運行時刻的信息(如各節(jié)點的負載狀況),負載平衡算法可以分為靜態(tài)算法與動態(tài)算法兩大類.靜態(tài)算法不使用運行時刻的信息,常用的靜態(tài)算法有輪循、隨機及靜態(tài)加權(quán)算法等幾種.其中輪循與隨機算法適合于所有節(jié)點處理能力相當?shù)那闆r.靜態(tài)加權(quán)算法適合于節(jié)點處理能力不同的情況.動態(tài)算法也稱為適應(yīng)性算法,根據(jù)運行時的系統(tǒng)狀態(tài)信息做出負載平衡決策.理論上,動態(tài)算法具有更大的靈活性,其實際效果則依賴于所選擇的負載分發(fā)策略、負載度量標準以及運行時數(shù)據(jù)的獲取.目前主流的J2EE應(yīng)用服務(wù)器一般只支持靜態(tài)算法,而CORBA產(chǎn)品則大都支持動態(tài)算法.這同樣與兩類中間件主要面向不同類型的應(yīng)用有關(guān).目前,PKUAS僅支持三種靜態(tài)負載平衡算法,并且支持在運行時刻替換缺省的負載平衡算法.3負載平衡機制在ppp的實現(xiàn)中的實現(xiàn)3.1pkuas負載平衡如前文所述,J2EE平臺上的負載平衡涉及到許多相關(guān)的策略(不同的負載平衡點、負載平衡粒度以及算法),這些策略各有其特定的適用環(huán)境.為了同時支持多種策略并允許客戶根據(jù)實際需要加以選擇,PKUAS實現(xiàn)了一個可靈活定制的負載平衡框架.PKUAS負載平衡建立在PKUAS互操作框架與JGroups提供的組通信服務(wù)之上.JGroups是基于Java的開源組通信中間件,被廣泛運用于各種J2EE平臺的開源實現(xiàn)中.JGroups提供了可靠有序的組通信、組成員管理以及組內(nèi)RPC等特性.在此基礎(chǔ)之上,PKUAS實現(xiàn)了集群服務(wù)、全局命名服務(wù),并在針對IIOP互操作協(xié)議的客戶代理中增加了對負載平衡的支持,從而實現(xiàn)了上述的兩種方案.目前,PKUAS僅支持使用RMI/IIOP互操作協(xié)議的EJB的負載平衡.3.2基于rpc的集群攔截集群服務(wù)負責在PKUAS啟動時加入組,監(jiān)聽JGroups發(fā)出的消息以及進行消息轉(zhuǎn)發(fā)等.集群服務(wù)允許其它服務(wù)注冊所關(guān)心的消息,并在收到消息時通知相應(yīng)服務(wù).其它服務(wù)可以通過集群服務(wù)發(fā)出組內(nèi)RPC調(diào)用,從而實現(xiàn)組內(nèi)節(jié)點的狀態(tài)同步.為了使EJB容器可以在方法調(diào)用前后對集群服務(wù)進行必要的控制,在PKUAS現(xiàn)有的截取器鏈中增加了集群截取器.目前,集群截取器僅在調(diào)用返回前完成兩項工作:從集群服務(wù)獲得當前視圖id,插入調(diào)用上下文中;對于返回remote對象的home方法,從構(gòu)件元數(shù)據(jù)獲取remote接口的負載平衡策略,并將其封裝為對象引用的一部分.3.3全局命名服務(wù)在PKUAS中,命名服務(wù)維護了JNDI名字與IOR(Inter-OperableobjectReference)(可互操作對象引用)的映射,而全局命名服務(wù)則維護了所有需要負載平衡的EJB(及RMI對象)的JNDI名字與一組IOR的映射.對于EJB,PKUAS會在應(yīng)用部署時刻為其生成home接口的IOR,并將IOR綁定到本地命名服務(wù)上,對于需要負載平衡的EJB則還會將其綁定到全局命名服務(wù)上.全局命名服務(wù)通過集群服務(wù)將名字信息組播到組內(nèi)其它節(jié)點上,以保持狀態(tài)同步.在查找過程中,如果全局命名服務(wù)在自身維護的綁定信息中找不到相應(yīng)的對象引用,則首先將請求轉(zhuǎn)發(fā)給本地命名服務(wù),如果仍然查找不到,則通過集群服務(wù)將請求轉(zhuǎn)發(fā)給組內(nèi)其它節(jié)點的全局命名服務(wù).當?shù)弥硞€節(jié)點失效時(由集群服務(wù)通知),全局命名服務(wù)將屬于該節(jié)點的名字信息刪除.對于需要查找級負載平衡的構(gòu)件,全局命名服務(wù)在查找時根據(jù)一定的負載平衡算法選擇相應(yīng)的對象引用返回給客戶.對于需要會話級與請求級負載平衡的構(gòu)件,全局命名服務(wù)在查找時將對應(yīng)于JNDI名的一組僅含單個地址的IOR重組為一個含多個地址的IOR返回給客戶.3.4remotestbub實現(xiàn)PKUAS實現(xiàn)了開放的互操作框架,自主開發(fā)了符合IIOP規(guī)范的RMI-IIOP互操作協(xié)議.為了實現(xiàn)在IOR內(nèi)封裝多個節(jié)點的地址與端口號,引入了標準IOR組件TAG-ALTERNATE-IIOP-ADDRESS.對于需要會話級與請求級負載平衡的構(gòu)件,全局命名服務(wù)返回一個包含此組件的IOR給客戶,保存在homestub中.Homestub在創(chuàng)建remote對象的方法中將自身維護的地址列表復制到remotestub中.為了實現(xiàn)2.2小節(jié)所述的各級負載平衡,stub需要對IOR中的地址列表進行不同的處理.對于會話級負載平衡,homestub的每次方法調(diào)用可以選擇地址列表中的不同地址,remotestub則僅使用創(chuàng)建該對象的home方法所用的地址;對于請求級負載平衡,homestub與remotestub都可以使用不同的地址.為了實現(xiàn)請求轉(zhuǎn)發(fā),stub必須獲得特定于該對象的負載平衡策略與其它相關(guān)信息,考慮到IIOP規(guī)范中并無相應(yīng)的標準組件,引入了自定義IOR組件TAG-LOADBALANCE-POLICY.其內(nèi)封裝了負載平衡粒度、算法、組成員視圖id以及各節(jié)點的靜態(tài)權(quán).負載平衡算法與各節(jié)點的靜態(tài)權(quán)分別來自部署描述文件與服務(wù)配置文件(見3.6小節(jié)).組成員視圖id從調(diào)用上下文獲得.當stub發(fā)現(xiàn)當前的視圖id與自身保存的id值不一致時,將從全局命名服務(wù)獲取包含了最新節(jié)點地址列表的IOR,從而避免了不必要的容錯開銷.3.5驗證認證信息PKUAS安全服務(wù)支持“單次登錄”(SingleSignon):客戶在執(zhí)行首次EJB業(yè)務(wù)操作前,要到認證服務(wù)器顯式登錄一次,認證服務(wù)器為客戶分配一個令牌作為臨時身份憑證,并將該令牌加入自身維護的一個緩存中.以后客戶的每次請求都將攜帶該令牌,由安全截取器調(diào)用認證服務(wù)檢查令牌的合法性.在集群環(huán)境中,由于客戶的每次請求可能由不同節(jié)點處理,為了保持“單次登錄”的特色,認證信息需要在集群范圍內(nèi)共享.為此將認證服務(wù)注冊到集群服務(wù)中,當新的令牌加入緩存或原有令牌失效時,通過組內(nèi)RPC維護各節(jié)點認證信息的同步.具體來說,當客戶在某個節(jié)點登錄后,該節(jié)點的認證服務(wù)為客戶分配一個令牌并加入自身的緩存,同時通過組內(nèi)RPC將該令牌加入組內(nèi)其它節(jié)點的認證服務(wù)緩存中.而后攜帶該令牌的客戶可以在組內(nèi)的任意節(jié)點上通過身份認證,而無需重新登錄.3.6部署和關(guān)閉負載平衡服務(wù)PKUAS基于微內(nèi)核的體系結(jié)構(gòu)允許對服務(wù)進行靈活定制.就負載平衡而言,用戶可以選擇使用或者不使用負載平衡,可以選擇不同的負載平衡粒度和負載平衡算法.目前,除缺省的負載平衡算法可以在運行時刻設(shè)置外,其它配置工作需要在部署時刻完成.下文將依次加以說明.管理員可以通過修改PKUAS的服務(wù)配置文件來啟動或關(guān)閉負載平衡服務(wù).客戶可以通過使用不同的客戶代理(由代理生成器自動生成)以及命名服務(wù)(本地或全局)以決定是否使用負載平衡服務(wù).部署人員可以在特定于應(yīng)用的部署描述文件中為每個EJB指定負載平衡策略,如圖5所示.其中負載平衡算法是可選允許管理員在運行時刻對一些配置參數(shù)進行調(diào)整.對集群服務(wù)而言,管理員可以從管理界面看到節(jié)點的靜態(tài)權(quán)、組名等信息,并可調(diào)整缺省負載平衡算法,從而使負載平衡服務(wù)對環(huán)境的變化具備一定的適應(yīng)性.3.7負載平衡機制的響應(yīng)時間節(jié)拍測試1與測試2評估了上述框架對單個節(jié)點的響應(yīng)時間產(chǎn)生的影響.測試環(huán)境如下:兩臺配置為P42.4G,512M內(nèi)存的DellPC,其中一臺作為服務(wù)器,安裝了RedHat9操作系統(tǒng),一臺作為客戶端,安裝了WindowsXP操作系統(tǒng).節(jié)點間通過100Mbps以太網(wǎng)聯(lián)接.測試用例是一個簡單的無態(tài)會話EJB和一個standalone的Java客戶程序.該EJB接受客戶傳來的一個字符串,并將其直接返回給客戶.該EJB部署在單個服務(wù)節(jié)點上,home與remote接口都使用輪循算法.客戶程序依次向服務(wù)器發(fā)送不同字節(jié)數(shù)的字符串(各1萬次,以避免測試結(jié)果的隨機性),并記錄響應(yīng)時間.三條曲線分別代表關(guān)閉負載平衡、命名服務(wù)轉(zhuǎn)發(fā)請求(查找級)與客戶代理轉(zhuǎn)發(fā)請求(請求級)三種情況.在測試1中,客戶僅在程序開始運行時調(diào)用JNDI命名服務(wù).在測試2中,客戶在每次調(diào)用前都進行查找與創(chuàng)建工作.圖6與圖7分別給出了兩種情況下的測試結(jié)果.當選擇命名服務(wù)作為負載平衡點時,負載平衡機制引起的響應(yīng)時間開銷僅存在于每次查找過程中,可以看到其影響是比較小的(對于一次查找、多次調(diào)用的情況幾乎可以忽略不計).當選擇客戶代理作為負載平衡點時,由于每次調(diào)用都需要運行負載平衡算法分派請求,對響應(yīng)時間有一定影響.4webgos和webgists負載平衡當前主流的應(yīng)用服務(wù)器都提供了對負載平衡的支持.考慮到J2EE應(yīng)用的特點,大多數(shù)實現(xiàn)(如JBoss、JOnAS與WebLogic等)均選取客戶代理作為負載平衡點.JBoss作為當前最成功的開源應(yīng)用服務(wù)器為負載平衡與容錯提供了全面支持.JBoss集群使用JGroups作為底層的組通信基礎(chǔ)設(shè)施,實現(xiàn)了集群服務(wù)、高可用命名服務(wù)以及特定于JRMP互操作協(xié)議的客戶代理及相關(guān)設(shè)施.與PKUAS相比,JBoss負載平衡的優(yōu)點在于支持分布熱部署,即僅需在集群的一個節(jié)點上部署需要負載平衡的構(gòu)件,熱部署過程自動將該構(gòu)件部署到集群的所有節(jié)點上.此外,JBoss3.2以上版本支持代理族(ProxyFamily).同一個EJB接口的位于同一個JVM內(nèi)的所有客戶代理組成一個代理族,可在其內(nèi)共享一些信息(如視圖id,地址列表等),從而使集群動態(tài)變化時客戶代理的更新工作得以簡化,并為某些特殊的負載平衡策略提供了支持.其不足之處在于,由于home與remote接口的客戶代理各自獨立地實施負載平衡算法,JBoss不能支持查找級與會話級負載平衡(有態(tài)會話構(gòu)件除外).此外,JBoss不支持運行時刻修改缺省的負載平衡算法.作為當前最成功的商業(yè)應(yīng)用服務(wù)器產(chǎn)品之一,WebLogic提供了功能更強大的集群服務(wù).與PKUAS相比,WebLogic除支持2.3小節(jié)所述的三