一種自適應(yīng)的web應(yīng)用服務(wù)器服務(wù)

web應(yīng)用程序是為創(chuàng)建、提交、運(yùn)營、集成和管理web應(yīng)用程序服務(wù)提供許多運(yùn)營服務(wù)（如新聞、事務(wù)、安全、應(yīng)用集成等）的分散系統(tǒng)。web應(yīng)用程序需要一個可信任的角色引導(dǎo)系統(tǒng)提供可靠的角色和高度伸展的功能（例如，javarmi、coba和com）等qos特征，以提高整個系統(tǒng)的性能和吞吐量。此外，它還可以根據(jù)中間件（如javarmi、coba和com）進(jìn)行負(fù)載平衡，以提高系統(tǒng)的可伸縮性。另一方面，它可以動態(tài)地調(diào)整硬件或軟件故障帶來的變化，并增強(qiáng)系統(tǒng)的可靠性。負(fù)載平衡的中間部分有兩個角色：非自由空間件和自適應(yīng)。非自由空分配服務(wù)只能為簡單的分布模式應(yīng)用程序提供負(fù)載平衡支持。例如，在文獻(xiàn)中，集成的名稱服務(wù)可以為無狀態(tài)分布應(yīng)用程序提供負(fù)載平衡服務(wù)，但這種負(fù)載分配是靜態(tài)的，不符合系統(tǒng)的變化，因此無法根據(jù)系統(tǒng)的變化來調(diào)整自己的行為，也不能應(yīng)用于復(fù)雜的負(fù)載平衡需求的分布系統(tǒng)。自適應(yīng)負(fù)載平衡服務(wù)可以根據(jù)系統(tǒng)運(yùn)行狀態(tài)信息進(jìn)行加載，并在系統(tǒng)負(fù)荷變化的情況下進(jìn)行調(diào)整。自適應(yīng)負(fù)載平衡服務(wù)目前還存在許多不足之處,如缺乏服務(wù)端透明性、僅支持無狀態(tài)復(fù)件(statelessreplica)的負(fù)載平衡、不支持容錯、固化的負(fù)載策略和負(fù)載度量等等[8~10],不能滿足Web應(yīng)用服務(wù)器如下一些關(guān)鍵需求:(1)不僅需要支持基于進(jìn)程、TCP/IP地址、系統(tǒng)服務(wù)等粗粒度的負(fù)載平衡,而且需要支持組件負(fù)載平衡模型,該模型不僅支持無狀態(tài)的組件,而且支持有狀態(tài)的實體組件,能夠協(xié)調(diào)多個組件的交互;(2)客戶不需要修改代碼就能將客戶請求透明地分發(fā)到后端應(yīng)用服務(wù)器處理.同樣,在系統(tǒng)運(yùn)行期間,可以適時地添加或刪除服務(wù)端組件,不影響對客戶的服務(wù),不更改服務(wù)端應(yīng)用代碼就可以提供負(fù)載平衡服務(wù);(3)盡可能均衡后端應(yīng)用服務(wù)器的負(fù)載,最大化系統(tǒng)可伸縮性,提高系統(tǒng)資源的利用率;(4)雖然負(fù)載平衡服務(wù)不需要提供完全的容錯能力,但能有效地處理應(yīng)用服務(wù)器出現(xiàn)失敗、崩潰的情況,提高系統(tǒng)可信賴性;此外,負(fù)載平衡服務(wù)自身必須容錯,不會出現(xiàn)單點(diǎn)失敗;(5)不同的應(yīng)用對負(fù)載有不同的要求,對負(fù)載度量和負(fù)載平衡策略有不同的語義,負(fù)載平衡服務(wù)需要支持客戶定制的負(fù)載度量和負(fù)載平衡策略,在運(yùn)行期間可以替換負(fù)載度量和負(fù)載平衡算法.WebFrame2.0是我們自行研制的J2EE應(yīng)用服務(wù)器,提供組件生命周期管理、數(shù)據(jù)庫連接管理、分布式事務(wù)、命名服務(wù)、消息服務(wù)等規(guī)范中規(guī)定的功能和服務(wù).由于J2EE1.3規(guī)范并沒有對負(fù)載平衡約定標(biāo)準(zhǔn)接口,也沒有指定負(fù)載平衡機(jī)制,因此,需要擴(kuò)展J2EE1.3規(guī)范的基本功能,實現(xiàn)負(fù)載平衡服務(wù),滿足Web應(yīng)用服務(wù)器的上述需求.為此,本文設(shè)計一種自適應(yīng)負(fù)載平衡服務(wù),并分析了在WebFrame2.0上實現(xiàn)負(fù)載平衡服務(wù)的一些關(guān)鍵技術(shù).1下一步,傳統(tǒng)kras,主要考WebFrame2.0支持縱向和橫向集群拓?fù)浣Y(jié)構(gòu),其集群邏輯拓?fù)浣Y(jié)構(gòu)如圖1所示,一個WebFrame集群由多個WebFrame應(yīng)用服務(wù)器組成,在每個WebFrame應(yīng)用服務(wù)器上運(yùn)行一個負(fù)載平衡服務(wù),該負(fù)載平衡服務(wù)能夠根據(jù)所有后端服務(wù)器運(yùn)行狀態(tài)動態(tài)地選擇一個EJB復(fù)件(replica)響應(yīng)客戶的請求.EJB復(fù)件是同一EJB組件在不同服務(wù)器上的實例.一個集群由多個子群(subcluster)構(gòu)成,在同一子群中的某個應(yīng)用服務(wù)器在運(yùn)行期間備份另外某個應(yīng)用服務(wù)器EJB復(fù)件的狀態(tài).負(fù)載平衡服務(wù)將請求在集群中所有EJB復(fù)件進(jìn)行分配.WebFrame2.0負(fù)載平衡服務(wù)組件結(jié)構(gòu)如圖2所示.根據(jù)J2EE規(guī)范,EJB由容器(container)管理,客戶不能直接訪問EJB實例.為了實現(xiàn)負(fù)載平衡,需要定位EJB所在的容器,然后對客戶請求進(jìn)行分配,為此,設(shè)計了ContainerLoadBalancer和RequesLoadBalancer.ContainerLoadBalancer根據(jù)集群服務(wù)器的負(fù)載情況,選擇一個負(fù)載輕的EJB容器響應(yīng)客戶創(chuàng)建EJB的請求,返回EJB在客戶端的動態(tài)代理ReplicaProxy.RequestLoadBalancer有負(fù)載和容錯兩大功能,它能根據(jù)Replica的負(fù)載情況或強(qiáng)制轉(zhuǎn)發(fā)請求,選擇Replica響應(yīng)客戶的方法調(diào)用;它還能夠感知Replica,Container和服務(wù)器失敗的情況,將客戶的請求轉(zhuǎn)發(fā)到備份服務(wù)器.ObjectRequestManager從ContainerLocator獲得Container,然后將需要創(chuàng)建的EJB通過JNDI名字綁定在選定的Container上,返回EJB在客戶端的動態(tài)代理ReplicaProxy,客戶可以通過這個Proxy訪問后端的EJB對象.ContainerLocator根據(jù)ContainerLoadAnalyzer對Container負(fù)載分析的結(jié)果,定位一個負(fù)載輕的Container.ReplicaLocator與ContainerLocator類似,所不同的是,其功能是定位于一個負(fù)載輕的Replica上.ContainerLoadAnalyzer應(yīng)用負(fù)載平衡策略,選定一個輕負(fù)載的Container返回給ContainerLocator,可以在運(yùn)行期間指定負(fù)載平衡策略,滿足系統(tǒng)負(fù)載動態(tài)變化的要求.ReplicaLoadAnalyzer與ContainerLoadAnalyzer功能類似,其負(fù)載分析對象是Replica.ContainerLoadMonitor主要監(jiān)視Container的負(fù)載以及Container所在的應(yīng)用服務(wù)器系統(tǒng)負(fù)載,如內(nèi)存、CPU等.ReplicaLoadMonitor有3大功能:(1)監(jiān)視Replica的負(fù)載;(2)將負(fù)載監(jiān)視結(jié)果發(fā)送給RequestLoadBalancer;(3)處理RequestLoadBalancer的請求轉(zhuǎn)發(fā)消息,通知Replica轉(zhuǎn)發(fā)或接受客戶的請求.ReplicaProxy是Replica在客戶端的代理,在運(yùn)行期間動態(tài)產(chǎn)生,RequestLoadBalancer通過這個ReplicaProxy區(qū)分不同的Replica,截取客戶所有調(diào)用請求.Containerinvoker是Container的入口,接收遠(yuǎn)程客戶端調(diào)用,并將其傳遞給Container.從圖2可以看出,應(yīng)用服務(wù)器通過LoadMonitor監(jiān)視系統(tǒng)負(fù)載,LoadAnalyzer根據(jù)負(fù)載情況在運(yùn)行期間應(yīng)用不同負(fù)載策略將負(fù)載在多個Replica平衡,解決了非自適應(yīng)負(fù)載平衡服務(wù)不可感知的問題;ReplicaLoadMonitor向RequestLoadBalancer提供負(fù)載的反饋信息,RequestLoadBalancer根據(jù)反饋結(jié)果向ReplicaLoadMonitor發(fā)送請求轉(zhuǎn)發(fā)的控制請求,使應(yīng)用服務(wù)器在運(yùn)行期間對系統(tǒng)負(fù)載的變化具有自適應(yīng)的調(diào)整能力.負(fù)載平衡服務(wù)的交互如圖3所示.當(dāng)Replica接收到LoadMonitor的“拒絕服務(wù)”的控制信息后,將LOCATIONFORWARD消息發(fā)送給RequestLoadBalancer,RequestLoadBalancer接收到LOCATIONFORWARD消息后,調(diào)用ReplicaProxy的Location_Forward方法更改Replica所在的容器在客戶端的存根,這樣,客戶可以繼續(xù)使用原來的ReplicaProxy向Replica發(fā)送調(diào)用請求.2關(guān)鍵技術(shù)及其解決2.1web應(yīng)用服務(wù)器分散式負(fù)載平衡服務(wù)自適應(yīng)負(fù)載均衡服務(wù)一般采取集中的方式.集中方式雖然易于設(shè)計與實現(xiàn),但是集中方式的負(fù)載平衡服務(wù)集中處理所有負(fù)載任務(wù),分發(fā)所有客戶請求,是系統(tǒng)的一個瓶頸.當(dāng)負(fù)載平衡服務(wù)出現(xiàn)失敗時,Web應(yīng)用服務(wù)器則不能接收客戶的請求,出現(xiàn)單點(diǎn)失敗,降低了系統(tǒng)的可靠性和可用性,不能滿足Web應(yīng)用服務(wù)器24×7的不間斷運(yùn)行的要求.為此,我們采取分散式負(fù)載平衡服務(wù).分散式避免集中式遇到的上述問題,提高了系統(tǒng)的容錯能力和可用性.如圖4所示,每個應(yīng)用服務(wù)器上都運(yùn)行相同負(fù)載平衡器(loadbalancer),多個負(fù)載平衡器管理系統(tǒng)的負(fù)載,形成一個邏輯上的負(fù)載平衡服務(wù).負(fù)載平衡器之間相互協(xié)調(diào)工作,將各自的負(fù)載信息發(fā)送給其他負(fù)載平衡器,每個負(fù)載平衡器根據(jù)各自收集到的負(fù)載信息通過LoadAnalyzer進(jìn)行負(fù)載決策.2.2componentconfigulator設(shè)計模式2.為了實現(xiàn)客戶和后端EJB組件的通信,Web應(yīng)用服務(wù)器需要接受客戶直接請求或負(fù)載平衡服務(wù)的轉(zhuǎn)發(fā)請求.雖然大多數(shù)EJB組件需要負(fù)載平衡,但是可能有一部分后端EJB組件不需要這種能力,為此,Web應(yīng)用服務(wù)器需要在運(yùn)行期間根據(jù)不同要求決定是否提供負(fù)載平衡服務(wù),不更改應(yīng)用服務(wù)器代碼實現(xiàn)負(fù)載平衡服務(wù)的熱插拔(hotplug-in),從而實現(xiàn)負(fù)載平衡服務(wù)的透明性.采用Interceptor設(shè)計模式,如圖5所示,Web應(yīng)用服務(wù)器在接收到客戶請求這個事件的時候,LoadBalancingInterceptors透明地將請求轉(zhuǎn)發(fā)給負(fù)載平衡服務(wù),然后負(fù)載平衡服務(wù)將負(fù)載控制命令通過RequestForward例外的形式返回給LoadBalancingInterceptor,ReplicaProxy捕獲這個例外后,將請求重新定向到指定的EJB,最后調(diào)用EJB實例的方法.為了提供真正的服務(wù)端的透明性和服務(wù)可熱插拔,需要在運(yùn)行期間動態(tài)地、透明地為每個EJB加載LoadBalancingInterceptors到應(yīng)用服務(wù)器.ComponentConfigurator設(shè)計模式可以實現(xiàn)在運(yùn)行期間動態(tài)地將一個服務(wù)加載到應(yīng)用,具體來說,ComponentConfigurator讀取EJB的配置文件,然后將LoadBalancingInterceptors(如LoadLocator,LoadMonitor等)加載到Interceptor鏈.當(dāng)接收到函數(shù)調(diào)用等事件時,自動地按照裝載順序觸發(fā)相應(yīng)的這些服務(wù).這樣,基于Interceptor和ComponentConfigurator設(shè)計模式,在沒有更改應(yīng)用服務(wù)器代碼的情況下,負(fù)載平衡服務(wù)能夠透明地將客戶請求轉(zhuǎn)發(fā),在運(yùn)行期間動態(tài)地、透明地添加攔截請求的Interceptor.2.3負(fù)載反饋和自適應(yīng)控制為了有效地在多個Replica上進(jìn)行負(fù)載均衡,負(fù)載平衡服務(wù)在事先不知道負(fù)載度量類型的情況下,可計算出當(dāng)前Replica的負(fù)載.當(dāng)Replica負(fù)載重時,Replica拒絕請求,將請求重定向給負(fù)載平衡器;當(dāng)負(fù)載輕時,負(fù)載平衡器迫使Replica又能接收客戶請求.為此,使用負(fù)載反饋和自適應(yīng)控制機(jī)制.如圖6所示,負(fù)載平衡器向LoadMonitor詢問Replica的負(fù)載或LoadMonitor將負(fù)載主動發(fā)送給負(fù)載平衡器.負(fù)載平衡器接收到負(fù)載反饋后,根據(jù)系統(tǒng)整體負(fù)載情況分發(fā)請求,將負(fù)載控制消息發(fā)送給LoadMonitor,并設(shè)置當(dāng)前Replica的負(fù)載狀態(tài).LoadMonitor基于Strategy設(shè)計模式,可對不同類型的資源進(jìn)行監(jiān)測,用戶只需定義不同的對象實現(xiàn)即可.在對象實現(xiàn)里,用戶可以采用不同的度量技術(shù)和策略獲取給定資源的負(fù)載,通過相同的接口向負(fù)載平衡器反饋負(fù)載.由于沒有將負(fù)載度量綁定在負(fù)載平衡器中,負(fù)載平衡服務(wù)可以基于不同類型的負(fù)載度量進(jìn)行均衡.負(fù)載平衡器和Replica并不直接通信,而是通過一個Mediator進(jìn)行交互,這個Mediator就是LoadMonitor,LoadMonitor響應(yīng)負(fù)載平衡器的請求,根據(jù)請求的類型,Replica決定是否繼續(xù)接收請求還是拒絕請求.2.4webfratege自適應(yīng)策略許多負(fù)載平衡服務(wù)只支持一些常見的負(fù)載平衡算法,如RoundRobin等,但是這些負(fù)載平衡算法遠(yuǎn)遠(yuǎn)不夠可以根據(jù)不同的情況使用不同的負(fù)載分析技術(shù),某些應(yīng)用需要動態(tài)更改負(fù)載平衡算法(如在不同的訪問時間段使用不同的算法),以便適應(yīng)新的負(fù)載要求.此外,開發(fā)人員可能需要評估不同負(fù)載平衡算法在Web應(yīng)用服務(wù)器中負(fù)載的效果和性能,也可能需要在測試、部署時定義一種應(yīng)用相關(guān)或綜合的負(fù)載平衡算法.任何負(fù)載平衡服務(wù)都不能實現(xiàn)所有用戶所需要的負(fù)載平衡算法.為此,自適應(yīng)負(fù)載平衡服務(wù)需要在運(yùn)行期間動態(tài)配置負(fù)載平衡服務(wù),如LoadMonitor和LoadAnalyzer,以替換負(fù)載平衡算法.結(jié)合ComponentConfigurator和Strategy設(shè)計模式,負(fù)載平衡算法可以替換模型,如圖7所示.LBStrategyConfigurator使得應(yīng)用在運(yùn)行期間能動態(tài)裝載或卸載負(fù)載策略實現(xiàn),用戶就可以根據(jù)不同要求和應(yīng)用場景在不停止服務(wù)器的情況下動態(tài)替換負(fù)載平衡算法,具有很好的擴(kuò)展性.Strategy設(shè)計模式應(yīng)用于負(fù)載平衡算法的實現(xiàn),每個負(fù)載平衡策略(strategy)有相同的接口,但卻有不同的負(fù)載分析技術(shù)和算法.WebFrame負(fù)載平衡服務(wù)支持RoundRobin,FirstAvailable,WeightBased,隨機(jī)以及模糊的自適應(yīng)策略等.模糊的自適應(yīng)策略比RoundRobin算法更復(fù)雜,允許Replica間負(fù)載有差別的情況,盡可能地將負(fù)載平均分配到各個Replica上.之所以稱之為“模糊”是因為該策略以整體性能為考慮,不精確考慮到每個Replica的負(fù)載而進(jìn)行任務(wù)遷移.模糊的自適應(yīng)策略描述如下:(1)每當(dāng)負(fù)載平衡器完成負(fù)載決策后,計算出Replica的平均負(fù)載,表示為AverageLoad;(2)比較各個Replica的負(fù)載與平均負(fù)載的差,表示為LoadDiff;(3)如果LoadDiff的值大于系統(tǒng)設(shè)定的負(fù)載差異閾值LoadDiffMax的N分之一,負(fù)載平衡器則將負(fù)載遷移到低負(fù)載的Replica,其中N是當(dāng)前系統(tǒng)所有Replica的數(shù)目.模糊的自適應(yīng)策略在某段時間內(nèi),在每個Replica的負(fù)載可能不完全相等,但是隨著時間的延長和Replica數(shù)目的增加,每個Replica的負(fù)載趨向平衡.許多研究人員在負(fù)載平衡算法方面做了大量的工作,他們提出的大多數(shù)負(fù)載平衡算法、策略都可以集成到WebFrame自適應(yīng)負(fù)載平衡.2.5u3000semote的實現(xiàn)如圖8所示,當(dāng)后端Web應(yīng)用服務(wù)器崩潰的時候,客戶就不能訪問該服務(wù)器上的所有Replica,自適應(yīng)負(fù)載平衡服務(wù)不僅需要將客戶的請求轉(zhuǎn)發(fā)到備份的Web應(yīng)用服務(wù)器,而且不影響轉(zhuǎn)發(fā)后請求的執(zhí)行結(jié)果,也就是說,自適應(yīng)負(fù)載平衡服務(wù)需要具有較強(qiáng)的容錯能力,能透明地處理應(yīng)用服務(wù)器崩潰的情況,客戶根本不會感知請求已轉(zhuǎn)發(fā),但請求會繼續(xù)正常執(zhí)行.為了實現(xiàn)自適應(yīng)負(fù)載平衡服務(wù)能透明地處理系統(tǒng)失效,要求后端Replica的狀態(tài)必須一致.Web應(yīng)用服務(wù)器中的Replica主要有無狀態(tài)(stateless)、有狀態(tài)(stateful)和實體(entity)3種類型,它們具有各自不同的特點(diǎn),負(fù)載平衡服務(wù)針對不同類型的Replica請求具有不同的容錯處理策略.對于StatelessSessionBean來說,由于不保存任何狀態(tài)信息,其請求轉(zhuǎn)發(fā)策略很簡單,負(fù)載平衡服務(wù)只需將客戶任意調(diào)用路由到任何一臺已部署該Bean的可用服務(wù)器即可;然而對于StatefullSessionBean的請求,由于同一Replica實例的不同請求之間存在著狀態(tài)相關(guān)性,因此對它們進(jìn)行請求轉(zhuǎn)發(fā)前必須確保狀態(tài)的一致性.為此,Web應(yīng)用服務(wù)器在客戶創(chuàng)建EJB對象時,負(fù)載平衡服務(wù)選擇一個備份服務(wù)器(secondaryserver)保存StatefullSessionBean狀態(tài)的備份.請求執(zhí)行后,StatefullSessionBean狀態(tài)的改變也同時復(fù)制到備份服務(wù)器中.當(dāng)主服務(wù)器不可用時,自適應(yīng)負(fù)載平衡服務(wù)自動地把客戶的請求指向備份服務(wù)器(如圖8所示),此時,備份服務(wù)器才在本地創(chuàng)建EJB實例,恢復(fù)EJB實例以前的狀態(tài),備份服務(wù)器繼續(xù)響應(yīng)客戶的請求,從而完成客戶請求的透明切換.此時的備份服務(wù)器已升級為主服務(wù)器,Web應(yīng)用服務(wù)器又為這個新的主服務(wù)器選擇一個備份服務(wù)器,最后自適應(yīng)平衡服務(wù)每次完成客戶請求調(diào)用后,自動刷新EJB實例其備份服務(wù)器的信息.對于EntityBean,它的狀態(tài)數(shù)據(jù)保存在數(shù)據(jù)庫中.當(dāng)某個EntityBean不可用時,負(fù)載平衡服務(wù)將客戶調(diào)用轉(zhuǎn)向備份的服務(wù)器,重新創(chuàng)建實例,并將EntityBean的狀態(tài)從數(shù)據(jù)庫中重新裝載到實例中,最后修改EntityBean所在的主服務(wù)器、備份服務(wù)器的位置信息.StatefulSessionBean和EntityBean都是有狀態(tài)的,統(tǒng)稱為StatefulReplica,當(dāng)負(fù)載平衡服務(wù)將請求從過載StatefulReplica轉(zhuǎn)發(fā)到輕負(fù)載Replica時,必須進(jìn)行狀態(tài)遷移,實現(xiàn)狀態(tài)的持久性、一致性.應(yīng)用Memento設(shè)計模式,通過Get_State和Set_State方法實現(xiàn)狀態(tài)遷移.StatefulReplica的負(fù)載平衡序列圖如圖9所示,通過如下操作將請求轉(zhuǎn)發(fā)到一個低負(fù)載的StatefulReplica:(1)負(fù)載平衡器透明地接收客戶發(fā)出的請求;(2)為了把負(fù)載遷移到一個新的StatefulReplica,負(fù)載平衡器調(diào)用Get_State操作從文件、數(shù)據(jù)或內(nèi)存中獲得重負(fù)荷Replica的狀態(tài);(3)負(fù)載平衡器調(diào)用Set_State操作將狀態(tài)恢復(fù)、載入到輕負(fù)載的StatefulReplica;(4)當(dāng)狀態(tài)遷移成功完成后,負(fù)載平衡器通知新的StatefulReplica可以處理客戶的請求;(5)負(fù)載平衡器通知負(fù)載重的StatefulReplica可以拒絕客戶的請求;(6)負(fù)載重的StatefulReplica將所有客戶請求都轉(zhuǎn)發(fā)給負(fù)載平衡器;(7)客戶將請求發(fā)送給新的StatefulReplica.2.6負(fù)載平衡集中均衡admm策略自適應(yīng)負(fù)載平衡服務(wù)可以提高Web應(yīng)用服務(wù)器的響應(yīng)速度,但是可能由于負(fù)載快速變化而導(dǎo)致系統(tǒng)不穩(wěn)定.由于Web應(yīng)用服務(wù)器的負(fù)載粒度小,負(fù)載平衡服務(wù)就可能不斷地在兩個Replica之間快速地切換負(fù)載,這種現(xiàn)象稱為負(fù)載顛簸.負(fù)載成群是指,當(dāng)有一個輕負(fù)載Replica可用時,負(fù)載平衡服務(wù)在很短時間內(nèi)將所有請求都轉(zhuǎn)發(fā)給這個Replica的現(xiàn)象.這兩個現(xiàn)象都是由于負(fù)載平衡服務(wù)對負(fù)載動態(tài)變化反應(yīng)過度造成的.有兩種策略可以避免上述兩種現(xiàn)象對系統(tǒng)整體性能的影響.第1種是增大LoadMonitor的負(fù)載取樣時間間隔T,但不超過系統(tǒng)容許的最大時間間隔Tmax.由于負(fù)載顛簸降低系統(tǒng)性能的原因在于負(fù)載平衡服務(wù)“頻繁”地將系統(tǒng)負(fù)載在多個Replica間進(jìn)行切換,增大取樣時間間隔可以使“頻繁度”降低,從而減少顛簸對系統(tǒng)性能的影響;第2種辦法是采用第2.4節(jié)所描述的“模糊”的負(fù)載平衡策略,增大負(fù)載差異閾值Loaddiffmax.基于該策略,負(fù)載平衡器并不會在出現(xiàn)負(fù)載不均衡的瞬間就進(jìn)行負(fù)載切換.此外,當(dāng)Replica的數(shù)目減少時,負(fù)載切換頻率盡可能地降低;當(dāng)Replica的數(shù)目增多時,負(fù)載平衡器能自適應(yīng)地多進(jìn)行負(fù)載切換,以盡可能地將負(fù)載均衡.3軟件設(shè)計以及負(fù)載平衡方式負(fù)載平衡服務(wù)主要包括網(wǎng)絡(luò)級、操作系統(tǒng)級和基于中間件這3種.基于中間件的負(fù)載平衡服務(wù)位于應(yīng)用和操作系統(tǒng)之間,屏蔽底層通信復(fù)雜性和操作系統(tǒng)的差異,提供一致對外接口,克服了網(wǎng)絡(luò)級和操作系統(tǒng)級負(fù)載平衡服務(wù)的不足,可以根據(jù)需要在運(yùn)行期間靈活地定制負(fù)載度量和負(fù)載平衡策略,根據(jù)請求內(nèi)容進(jìn)行決策,因此具有很高的靈活性.BEAWeblogic和IBMWebsphere是目前兩大主流的J2EE應(yīng)用服務(wù)器,雖然它們都能對3種不同類型的EJB進(jìn)行負(fù)載平衡,但是,與本文的負(fù)載平衡服務(wù)相比,它們存在如下差異:(1)由于將負(fù)載服務(wù)硬編碼到應(yīng)用服務(wù)器中,從而不可熱插拔,不具有便利性,只能通過一些管理工具靜態(tài)地配置負(fù)載平衡策略;(2)僅支持一些常見的負(fù)載平衡算法,如RoundRobin(缺省)、Weight-Based和隨機(jī)算法,不能根據(jù)系統(tǒng)負(fù)載信息進(jìn)行決策,也不能進(jìn)行負(fù)載反饋,不具有自適應(yīng)控制能力;(3)由于將算法的實現(xiàn)硬編碼在應(yīng)用服務(wù)器中,負(fù)載平衡算法和負(fù)載度量都不能根據(jù)實際需要進(jìn)行定制,不能替換;(4)客戶端透明性差.以Weblogic為例,為了實現(xiàn)動態(tài)的負(fù)載平衡,在處理請求時進(jìn)行任務(wù)遷移,客戶在調(diào)用每個對象方法之前需要顯式調(diào)用Callrouter的方法獲得對象所在的服務(wù)器名.而本文設(shè)計的負(fù)載平衡服務(wù)則不需要更改客戶任何代碼就可以實現(xiàn)負(fù)載平衡,具有很好的位置和訪問透明性.而微軟通過ApplicationCenter為運(yùn)行在MTS應(yīng)用服務(wù)器上的COM組件提供負(fù)載平衡服務(wù),其基本原理是由ApplicationCenter接受客戶創(chuàng)建組件實例的請求,然后在事先配置好的服務(wù)器列表中根據(jù)負(fù)載平衡策略選擇一個COM服務(wù)器響應(yīng)客戶的請求.客戶需要更改客戶端代碼后負(fù)載平衡服務(wù)才可以截獲請求.微軟的組件負(fù)載平衡服務(wù)存在與BeaWeb