這種架構存在以下幾點不足之處：

1）採用主機備機的方式，一般主機使用比較頻繁，導致另外比較空閒，資源利用不均衡。

2）當一個Server發生故障的時候，必須通知使用者使用另外一臺的Server，管理和維護比較麻煩。

3） 使用者切換應用的時候，需重新登入，有些延誤時間。

可伸縮性

可以動態增加部署在 WebLogic Server 群集中的應用程式的容量以滿足需要。可以將伺服器例項新增到群集中而不會中斷服務，應用程式將繼續執行而不會影響客戶端和終端使用者。

 高可用性

  在WebLogic Server 群集中，當伺服器例項失敗時應用程式可繼續進行處理。可通過將應用程式元件部署到群集中的多個伺服器例項，“群集”這些元件，這樣，如果在其上執行某個元件的伺服器例項失敗，則將此元件部署到的其他伺服器例項可以繼續進行應用程式處理。

  群集WebLogic Server 例項的選擇對於應用程式開發人員和客戶端是透明的。但是，瞭解啟用群集的技術基礎結構將有助於程式設計人員和管理員最大化其應用程式的可伸縮性和可用性。

應用程式故障轉移

  簡單的說，故障轉移是當應用程式元件（在下列部分中通常稱作“物件”）正在處理某個特定作業時 某些處理任務部分由於任何原因而變得不可用，已失敗物件的副本將結束此作業。 WebLogic Server 支援自動或手動將群集伺服器例項從一臺計算機遷移到另一臺計算機。可遷移的受管伺服器被稱作“可遷移伺服器”。本功能適用於要求高可用性的環境。

負載平衡

  負載平衡是在環境中跨計算資源與網路資源平均分發作業和關聯的通訊。

  群集的應用程式或應用程式元件在群集中的多個 WebLogic Server 例項上可用。如果已群集某個物件，則此物件的故障轉移和負載平衡是可用的。將物件均勻部署到群集中的每個伺服器例項，可以簡化群集管理、維護和故障排除。

  Web 應用程式可由不同型別的物件組成，包括企業 Java Bean (EJB)，servlet 和 Java Server Pages (JSP)。每種物件型別都具有唯一的一組與控制、呼叫以及它如何在應用程式內起作用相關的行為。由於此原因，WebLogic Server 用於支援群集的方法，以及用於提供負載平衡和故障轉移的方法，會因不同的型別物件而異。可在 WebLogic Server 部署對下列型別的物件進行群集：

1）Servlet

2）JSP

3）EJB

4）遠端方法呼叫（Remote Method Invocation，簡稱 RMI）物件

5）Java 訊息服務 (JMS) 目標

6）Java 資料庫連線 (JDBC) 連線

以下 API 和外部服務不可在 WebLogic Server 內群集：

1）包含檔案共享的檔案服務

2）時間服務

  在群集的各個 WebLogic Server 例項中仍可使用這些服務。但是，這些服務不能使用負載平衡或故障轉移功能。

1）叢集中的WebLogic主機必須使用永久的靜態IP地址。動態IP地址分配不能用於叢集環境。如果伺服器位於防火牆後面，而客戶機位於防火牆外面，那麼伺服器必須有公共的靜態IP地址，只有這樣，客戶端才能訪問伺服器。

2）叢集中的所有WebLogic伺服器必須位於同一個區域網，並且必須是IP廣播可到達的。

3）叢集中的所有WebLogic伺服器必須使用相同的版本。配置叢集中的伺服器，使它們支援所提供的服務。對於使用了JDBC連線的EJB，所有部署了某EJB的伺服器必須具有相同的部署與持久化配置。也就是說所有伺服器都應該有相同的JDBC配置。所有部署了servlet的主機必須維護一組具有相同ACL的servlet

0  引言

網際網路的出現使資訊訪問產生了質的飛躍，但隨之而來的是Web流量的激增（高併發訪問），由於涉及資訊量十分龐大，使用者訪問的頻率也高，許多基於Web的大型公共資訊系統（如電子圖書館、BBS、搜尋引擎和遠端教育等）需要在實時性和吞吐量方面都具有較高效能的Web伺服器支援。一些熱門的Web站點由於負荷過重而變的反應遲緩。如何提高Web伺服器的效能和效率成為一個亟待解決的問題。 實際上，伺服器的處理能力和I/O已經成為提高Web服務的瓶頸。如果客戶的增多導致通訊量超出了伺服器能承受的範圍，那麼其結果必然是服務質量下降。顯然單臺伺服器有限的效能不可能解決這個問題，一臺普通伺服器的處理能力只能達到每秒幾萬個到幾十萬個請求，無法在一秒內處理上百萬個甚至更多的請求。顯然，採用高效能的主機系統（小型機或大型機）是可行的，但是除了價格十分昂貴外，這種高速、高效能的主機系統，很多情況下也不能解決同時處理幾萬個併發，因為，高速主機系統只是對於複雜的單一任務和有限的併發處理顯得高效能，而Internet中的Web伺服器大多數處理是“簡單任務”、高強度併發處理，因此即便有大資金投入高效能、高價格的主機系統，也不能很好的滿足Web應用的需要。這就是利用Web伺服器叢集實現負載均衡的最初基本設計思想^[1]。

1 負載均衡叢集

高擴充套件型叢集，即負載均衡叢集技術^[2]，就是帶均衡策略（演算法）的伺服器叢集。負載均衡叢集在多節點之間按照一定的策略（演算法）分發網路或計算處理負載。負載均衡建立在現有網路結構之上，它提供了一種廉價有效的方法來擴充套件伺服器頻寬，增加吞吐量，提高資料處理能力，同時又可以避免單點故障^[3]。 以Web訪問為例，後臺的多個Web伺服器上面有相同的Web內容，Internet客戶端的訪問請求首先進入一臺伺服器，由它根據負載均衡策略（演算法）合理地分配給某個伺服器^[4]。

1.1 基於WebLogic的負載均衡叢集

WebLogic支援叢集技術，即讓一組Server指向同一域名一起工作從而提供一個更強大、更可靠的應用平臺。對於客戶端而言，無論Cluster中有幾個Server在工作，看上去都是一個^[5]。叢集技術有兩個最明顯的特色： (1)可伸縮性：Cluster對加入其中的Server在效能上沒有限制（如普通的PC機），為了提高效能，當客戶端的請求大幅增加時，可以動態地向Cluster中新增Server。並且，配置Cluster當一臺機器的資源沒有被完全利用時，可以在同一機器上啟動多個Server，但要求每一個Server使用不同的IP，而不能用同一IP的不同埠。 (2)高可用性：由於在Cluster中同一service在多個Server上同時存放或放在一個共享檔案系統中，因此相同的請求可以有多個Server提供，並且Server間還可以複製狀態資訊。這樣，當其中某一Server宕機或無法響應請求時，其它的Server會立即接管它的任務，從而把應用和客戶端完全隔離開來。

1.2  WebLogic 叢集的工作機制

每一個Clustered service,在每一個server上都會有一個instance，即一個replica，這些replicas集合在一起形成一個replica-aware stub。這些stubs負責客戶端與相關的伺服器段物件的通訊，當客戶端請求該service時，實際上是向stub發出請求，stub根據不同的演算法呼叫集合中某一replica，如果呼叫失敗，stub會檢測到錯誤並重新呼叫其它的replica。Cluster支援多種演算法：隨機、輪循、基於效能的負載均衡的輪循(Weight-based round-robin)、根據引數值呼叫(Parameter-based routing)。 WebLogic Cluster通過負載均衡和容錯最大程度的實現了它的可伸縮性和可用性。^[6] 為了提高Cluster的可伸縮性，必須保證充分利用每一個Server。WebLogic可以在不同平臺、不同效能的機器上安裝Server並進行Cluster,然後採用Weight-based round-robin演算法達到負載均衡，從而使每一個Server都得到充分的利用。 為了使Cluster具有高可用性，必須具備故障恢復的能力，這一點可以通過replica-aware stub的容錯功能來實現。Stub 主要是通過在檢測到錯誤資訊時重新進行呼叫的方式實現容錯。當重新呼叫不會導致錯誤的結果時(如stub確認failed server不能接收到請求)，容錯功能自動實現。而有些情況下，重新呼叫可能會導致某一service被請求了多次的錯誤結果。例如：客戶端C請求Clustered購物車服務中的additem()方法，replica-aware stub接收到請求，根據演算法呼叫Server1上的service,Server1響應請求並返回結果，但在結果成功到達客戶端之前，Server1出現錯誤。此時stub接收到錯誤資訊，因此重新呼叫Server2上的這一方法，但實際上Server1已經將item加入購物車，這樣就造成重複。為了解決這種問題，可以為服務新增一個唯一標識，如上述的additem()方法中可新增一個引數——序列號。每一個item有一個唯一的sequence,相同sequence的item不能被重複新增。

2 構建WebLogic叢集

2.1  Domain和Server

Domain是WebLogic Server例項的基本管理單元。所謂Domain就是，由配置為Administrator Server的WebLogic Server例項管理的邏輯單元，這個單元是有所有相關資源的集合。 Server是一個相對獨立的，為實現某些特定功能而結合在一起的單元。^[7]一個Domain 可以包含一個或多個WebLogic Server例項，甚至是Server叢集。一個Domain中有一個且只能有一個Server 擔任管理Server的功能，其它的Server具體實現一個特定的邏輯功能。

2.2  系統實現方案

在此，作業系統平臺使用Windows 2000，軟體使用Bea WebLogic Server 8.1 SP2，程式基於J2EE架構，有以下兩種方案： a．單層混合型的叢集架構（Cluster） 這種架構將所有的Web應用以及相關的服務應用全部置於叢集中的單一WLS例項中，這種架構的優勢在於：　　 易於管理； 靈活的負載平衡機制； 更強的安全控制； b．多層結構的叢集架構（Cluster） 這種架構使用兩個WLS叢集，一個放置表靜態內容和叢集Servlet，另一個放置叢集EJB。一般應用於下面這些情況：　　(1)在負載平衡機制需要呼叫叢集EJB中的方法時；　　(2)在提供內容與提供物件的服務之間需要更大的機動性時；　　(3)在需要更高的系統穩定性時；

2.3 叢集應用的必要條件

叢集中的所有Server必須位於同一網段，並且必須是IP廣播(UDP)可到達的。^[8]叢集中的所有Server必須使用相同的版本,包括Service Pack。 叢集中的Server必須使用永久的靜態IP地址。動態IP地址分配不能用於叢集環境。如果伺服器位於防火牆後面，而客戶機位於防火牆外面，那麼伺服器必須有公共的靜態IP地址，只有這樣，客戶端才能訪問伺服器。  要以Cluster方式執行，必須有包含Cluster許可的License。

3 系統實現及壓力測試

在配置叢集應用前要對叢集的配置資訊有一個良好的設計，下面就是我們配置的叢集資訊。如圖1：圖1 叢集配置資訊

機器型別 作業系統 硬體配置 角色 DELL PC Windows 2000 IP:10.16.92.7 PORT:7080 Administrat or Server DELL PC Windows 2000 IP:10.16.92.7 PORT:8080 Proxy Server DELL PC Windows 2000 IP:10.16.92.7 PORT:7082 Managed Server DELL PC Windows 2000 IP:10.16.92.31 PORT:7084 Managed Server DELL PC Windows 2000 IP:10.16.92.32 PORT:7086 Managed Server DELL PC Windows 2000 IP:10.16.92.33 PORT:7088 Managed Server

我們使用了四臺DELL-PC機器，其中每個機器都作Managed Server，而選擇其中一臺機器兼作Administrator Server和Proxy Server。 管理伺服器（Administration Server）是一個WebLogic 伺服器例項，它負責配置與管理同一個域裡的其它WebLogic Server 例項。管理伺服器例項的意外中止對整個域的執行沒有什麼影響。當一個管理服務停止了，它所管理的其它服務例項(叢集的或未叢集的)都能正常執行。如果在這個域裡存在有叢集，叢集提供的Failover和負載均衡服務也能夠繼續而不受影響。^[9]代理伺服器（Proxy Server）是整個網站系統的總入口（和網站的域名對應），它接受web server上所有請求，並轉給叢集中的某一個Managed Server。Proxy對cluster的所有請求進行負載均衡，並且當請求失敗時會進行恢復處理。Proxy還可以在cluster中特別是Server沒有正常完成請求響應時保持session狀態。當session初始化時，proxy按照負載均衡演算法選擇一臺Server儲存session，此後，所有與此session相關的請求都由這同一臺Server處理。為了避免當此Server出錯時，無法儲存客戶端狀態資訊，所以session會被複制下來，並且session的所有變化都會在備份中進行及時更新，這樣，當原有Server在響應請求過程中失敗時，proxy會立即獲取session的備份，並由此繼續響應客戶端請求，同時做新的複製。 Managed Server上部署了網站的應用程式，用於執行Proxy Server分發過來的使用者請求。我們對以上的集群系統進行了測試，編寫了一個簡單的WEB應用，它會在控制檯和瀏覽器上同時打印出“OK”字樣，然後將這個WEB應用部署到叢集中所有Managed Server上面。在這裡我們將通過Apache中所帶的ab包來進行併發訪問的模擬測試，使用如下的命令進行壓力測試。 ab -n 100 -c 10 http://10.16.92.7:8080/index.jsp ab是測試程式的名稱 引數n代表請求的總數量 引數c代表併發的請求數 url為要測試壓力的頁面 使用這個命令時，一定要在系統路徑中能夠找到該程式，否則不能執行。我們取請求的總數量n等於100，壓力測試完成後，我們從Managed Server的控制檯上可以看到，nodeA，nodeB，nodeC，nodeD（即四個Managed Server）分別打印出了27、23、24、26個“OK”字樣，這說明，在併發請求的情況下，叢集能夠將請求進行分發，達到了負載平衡的目的。 另外，我們編寫了一個簡單的購物車程式，該系統能夠在某一臺機器宕機後把seesion轉交給其他機器，達到了故障接管的目的，增加了Web系統的高可用性。

4 系統故障分析

我們經常會遇到HTTP 請求在 WebLogic 叢集節點之間的負載平衡不均，即，叢集中一個或多個節點接收和執行的 HTTP 請求比同一叢集中的其它節點多。 發生這種情況的原因是由於 HTTP 會話分配不均。代理將不包含會話 cookie 的請求轉發到基於 round-robin 負載平衡模式的叢集節點，並在該節點上建立新會話。^[8]理想狀態下，所有叢集節點應當接收等量的 HTTP 會話。如果沒有出現這種情況，則由於負載平衡策略的“粘性”特點，接收較多會話的節點將得到比其它節點數量更多的請求。最終結果是造成叢集節點之間負載分配不均。遇到這種問題，可以檢視代理外掛的有關資訊是否正常。 另一個經常遇到的問題是會話複製失敗。會話複製失敗通常是因為網路組播問題引起的。有時候，配置問題也會導致失敗。此外，確保輸入到會話中的資料必須是可序列化的，否則複製可能會失敗。編碼的時候也應該注意，比如不要使用 http 會話的 putValue 和removeValue 方法，因為它們不受支援，並且當您在應用程式中使用這些方法時，可能會出現會話資料複製問題。相反，僅使用 HttpSession 的setAttribute和removeAttribute 方法。^[10]此外，還需要注意靜態變數的使用，快取同步，EJB、Servlet、JSP同步等，在單機環境下不會發生變化的值在叢集環境下有可能會發生變化。

5 結束語

本文提出了一種基於WebLogic的叢集Web伺服器的設計方案，通過壓力測試，系統能夠達到負載均衡的目的，該方案已經在某個大型商業網站中使用並取得了很好的效果。

參考文獻

[1] Li Chuan Chen, Hyeon Ah Choi. Approximation algorithms for data distribution with load balancing of Web servers[J]. In: Proceedings of IEEE International Conference on Cluster Computing, 2001,274-281 [2] Mark Artiges（美），袁毅, 談莉婭, 宋燕紅譯.《BEA WebLogic Server 8.1大全》[M]；機械工業出版社,2005 [3] 黃鎧，徐志偉.《可擴充套件平行計算技術、結構與程式設計》[M]；機械工業出版社,2000 [4] 李雙慶，古平，程代傑.Web系統負載均衡策略分析與研究 [J].計算機工程與應用.2002,（19）：40-43（in Chinese） [5] 柏海寰, 基於分散式查詢的Web伺服器叢集 [J] 計算機工程.2006；32:96-116 [6] 李定鎖,Web伺服器叢集中的檔案優化分配 [J] 計算機工程與應用。2004；16:79-81 [7] Joel Millecan (美),Internet資訊伺服器技術 [M].北京；清華大學出版社,1998.209 [8] 小泉修(日),Web技術:HTTP到伺服器端王浩譯 [M] 北京:科學出版社,2004 [9] 劉剛常,基於叢集分配器的Web伺服器集群系統的Web QoS研究 [O],碩士,湖南大學 2006 [10] 劉博,嵌入式Web伺服器的設計與實現 [O],碩士,西安電子科技大學,2006