您希望了解 SOA 內服務器間 Web 服務應用程序的負載平衡么？在本文中，Judith M. Myerson 與我們一起探討了用戶在高峰流量期間所需求的快速響應的重要性，并且列舉了一些負載平衡技術的示例。此外，她還與我們一起探討了負載平衡工具——WebSphere? Application Server 和 WebSphere Edge Server，開發人員、系統管理員和網絡管理員可以使用這些工具在服務器間平衡 Web 服務應用程序的負載，從而確保網絡在高峰流量期間保持高性能、高可靠性和高可用性。
引言
在本系列第 4 部分“使用 Rational 開發工具構建 SOA 中間件應用程序”（請參閱參考資料）一文中，我講解了如何使用 Web 開發工具創建 SOA 中間件應用程序。在本系列第 5 部分“使用 WebSphere Business Integration 工具優化 Web 服務應用程序”（請參閱參考資料）一文中，我講解了如何使用業務流程工具集成和優化 Web 服務應用程序。在第 5 部分，我還講解了減少 Web 請求數量、執行時間、訪問時間和帶寬量的方法，這些方法都可以用來優化 Web 服務應用程序。
在本文中，我介紹了負載應用程序的某些問題如何影響了 Web 服務應用程序間的互操作方式。文中包含了一個流量瓶頸的實例，導致該瓶頸的原因是：在特定期間有太多的訪問者基于業務流程發送了太多的請求到一個 Web 服務應用程序。接著又講了如何從負載平衡技術中獲益。
請記住，Web 請求與訪問者的請求是不同的。Web 請求的數量不僅依賴于訪問者的請求數量，也依賴于由訪問者請求生成的、已優化的 Web 請求的類型和內容。
響應遲緩
為了更好地認清這種差異，請看接下來的這個實例。如果某個訪問者在將請求通過 Web 服務發送到一臺服務器后等了很久才得到回復，那么該訪問者很可能為了獲得更快的響應時間而轉向使用另一種 Web 服務或網站。該始發端 Web 服務將處理傳入的訪問者請求，以生成并優化傳輸到目標 Web 服務的 Web 請求。
始發端 Web 服務響應遲緩，可能表明目標服務器繁忙，或是沒有足夠的系統空間來處理多個訪問者請求（多線程處理）。處理這種負載問題的方法之一是平衡服務器間的負載，這樣訪問者就不會為得到答復而等待太久。這種技術稱為負載平衡。
加快響應
平衡服務器間負載要優于外包 Web 服務，負載平衡技術不僅全面考慮到增加的服務器容量、改善的站點設計和使用獨立磁盤冗余陣列（Redundant Array of Independent Disk，RAID）的能力，而且也提供了處理預期高峰流量所需的帶寬。在服務器的長期運行中，它們會消耗更多的服務器資源。通過使用負載平衡技術，我們有更好的機會來提高服務器的性能和可靠性，并同時減少帶寬量、執行時間和訪問時間（假定服務器中包含故障轉移機制 ）。
由于上述原因，負載平衡技術成為了大多數公司在處理大流量時（尤其在高峰流量期間經受服務器停滯時）的首選技術。這些公司希望更快地響應用戶需求，從而在較短的時間內完成更多的工作任務。
您可以將負載路由到域名系統中不同的服務器主機地址，或者將一臺服務器要處理的工作總量分攤到兩臺或多臺服務器上。您不僅需要使用另外一臺服務器智能化地選擇出將工作分配給哪臺服務器，還需要使用故障轉移和備份服務將這些服務器聯合到一起，以防某臺服務器出現故障（尤其當服務器集散于不同地理位置時）。
類比購物車
作為一個類比，請把負載平衡服務器看為超市的 4 個付款臺。讓我們瞧瞧超市是如何在 4 個付款臺間實現“負載平衡”的。
假設您排在 1 號付款臺前的長隊中，您可以粗略地估算出大概需要多久時間才能排到自己付款。如果您發現這條隊伍移動緩慢，而且此時看到一名收銀員走向 4 號付款臺打開機器準備工作，那您一定會推著購物車快速地跑到 4 號付款臺（請參見圖 1）。
接著又有一名收銀員打開了 3 號付款臺，并揮手示意第一隊排在您前面的購物者到 3 號付款臺排隊。這些購物者當然會移到 3 號付款臺。2 號付款臺此時仍然保持關閉狀態。
圖 1. 購物車的負載平衡
減少服務時間
讓我們看看另一種負載平衡方式。如果您推著一輛滿滿的購物車，里面裝著您一家十口一個月的雜貨，您可能希望將貨物分給多個付款臺結帳。在沒有家人陪同的情況下，這種想法尤為強烈。您可以將購物車中的物品分為幾份，然后分從幾個清閑可用的付款臺結帳，這樣就減少了付款時間。
雖然這在實際生活中是不可能的，但您可以使用負載平衡器實現類似的目的，它能把在線購物車（Web 服務應用程序）的請求從繁忙的服務器上轉移到其他清閑可用的服務器上（請參見圖 2）。如果其他服務器通過優化可以滿足服務需求，就沒必要再啟用新服務器。
圖 2. 在線購物車請求的負載平衡
問題
您該怎樣解決該問題？更快地跑到付款臺前（增加帶寬）？增加付款臺數量（增加服務器容量）？找其他人幫您買（外包）？這些方法都不適用。
請您回答以下這些問題：
- 您將要平衡哪種應用程序的負載？
- 在整個分布式網絡中，該應用程序是否為長期運行？
- 一臺服務器或一個服務器集群超時接收了多少請求？
- 在高峰流量期間，需要多少流量和帶寬量？
- 怎樣利用服務器平衡應用程序負載？
- 在不同時段，預計有多少訪問者？
- 訪問者最多能夠發送多少請求？
在您答完這些問題后，請與一名網絡管理員或系統管理員檢查和整理這些答案，以促進相互了解。然后使用某種算法、技術或工具開發一個負載平衡程序，實現將繁忙的服務器上的訪問者和 Web 請求重定向到清閑可用的服務器上。
負載平衡技術
負載平衡技術包括以下幾種：
- 簡單路由
- DNS Round Robin
- 復雜算法
- 智能路由
由于實際工作中的流量需要按優先級處理，所以在開發 Web 服務應用程序時，請考慮上述技術中的最后兩種技術。因為包含要求更快響應的服務器和訪問者的分布式網絡正在不斷地擴張。由于前兩種技術不需要按流量的優先級進行處理，所以我們將不在有關流量瓶頸的問題中討論它們。
當您使用復雜算法時，分發請求是基于服務器性能、服務器使用的硬件種類和處理客戶優先級的方法等等。這表明，最快的服務器將獲得更多具有最高客戶優先級的請求。智能路由基于請求的內容和（在始發端服務器發生故障時）流量重定向到另一臺服務器的方式。
基于服務器的軟件
雖然您可以使用軟件、硬件或兩者來達到負載平衡，但您最好還是在應用程序服務器集群上使用基于服務器的軟件。基于服務器的軟件的價格要遠低于基于硬件的專用服務器。硬件升級的價格要遠高于相應軟件升級的價格。
在將基于服務器的軟件添加到網絡中之前，請檢查網絡是否配置正確，負載平衡器是否“靈活”。“靈活”在這里的解釋是：雖然負載平衡器可能已為目前的 Web 服務應用程序做好了充分的配置，但它還必須能夠通過擴展滿足未來應用程序的需求。
IBM WebSphere Application Server 就是一款基于服務器的軟件，它在負載平衡和故障轉移中同時使用了復雜算法和智能路由。它的負載平衡器有能力根據 Web 服務應用程序的未來需求進行擴展。您需要為負載平衡建立一個服務器集群，并測試其故障轉移機制（請參閱參考資料）。
面向多平臺的 WebSphere Edge Server V2.0 是另一款基于服務器的軟件。它專門設計用于改善服務器選擇、負載優化和容錯。它還附帶了網絡地址轉換（Network Address Translation，NAT）和用于 Cisco CSS 交換機的 WebSphere Edge Server Consultant，并且支持內核級的基于內容路由（Content Based Routing，CSR）。（請參閱參考資料）
結束語
Web 服務應用程序的負載平衡需要提早計劃，以確定在高峰流量期間如何在服務器間平衡負載。在設計 Web 服務的過程中，請多與系統管理員交流負載平衡技術相關的問題。
解決這些問題能使您更容易地創建負載平衡的 Web 服務應用程序。您可以在 SOA 內部（或跨 SOA）基于業務流程開發 Web 服務和平衡 Web 服務負載。解決這些問題還能使管理員更容易地平衡 Web 服務應用程序的負載，并確定在 SOA 中使用哪種負載平衡方法，以及能夠平衡多少應用程序的負載。