【轉載】Windows平臺下利用APM來作負載均衡方案 - 負載均衡（下）

時間 2019-11-19

標籤轉載 windows 平臺利用 apm 來作負載均衡方案欄目 Windows 简体版

原文原文鏈接

概述

　　咱們在上一篇Windows平臺分佈式架構實踐 - 負載均衡中討論了Windows平臺下經過NLB（Network Load Balancer) 來實現網站的負載均衡，而且經過壓力測試演示了它的效果，能夠說仍是很是的理想的。同時咱們也收集到了很多的問題，好比說如何在這種分佈式的架構下使用Session，NLB中有一臺服務器掛掉了會致使對外暴露的地址沒法訪問，若是實現服務器之間的同步，若是更好的進行熱修復等等，還有咱們在上一篇中也提到了NLB所提供的功能是很是簡單的，爲了回答咱們前面提到的問題，也爲了提供一個比較全面完整的負載均衡方案，咱們來看看Windows平臺下負載均衡的另外一種實現APR (Application Request Router + Web Farm + Url Rewriter)，但願能夠爲你們解決一些實現的問題。html

安裝配置負載均衡

安裝相關組件

　　話很少說，爲了實現一個比較完整的負載均衡，咱們要引入如下5個組件。web

　安裝Web Fram 必需要先安裝Web Deploy 和Web Platform，因此我把它們倆放在最前面，你也能夠參考上面的順序來安裝，固然你首先得本身把IIS和ASP.NET 模塊給裝上。咱們此次不會對這5個組件的原理作詳細的介紹，你們知道怎麼操做就能夠了，若是有興趣的同窗能夠繼續深刻。安裝過程很是的簡單，基本上每個組件只須要點一下按鈕就能夠了，所有安裝完以後，你就會在當前那臺機器上的IIS下看到一個Server Farms的結點。正則表達式

配置負載均衡

　　若是你們還有印象，在使用NLB配置負載均衡的時候，咱們是不須要一臺單獨的機器來做爲主入口的。咱們給全部的WEB服務器都安裝上NLB，而後選擇任意一臺將其它的WEB服務器加進入同時設置一個單獨的IP做爲入口地址便可。可是換成APR，狀況就有點不同了。咱們須要一臺單獨的入口服務器來接收全部的請求，由它再把全部的請求根據配置的規則轉發給其它真實的WEB服務器。算法

　3 臺Web 服務器咱們仍是用咱們上次作過實驗的那三臺，咱們再添加一臺配置同樣的虛擬機，而後給這4臺服務器所有安裝上APR(包括咱們上面列出的5個組件）以後，咱們就能夠開始配置了。咱們首先在咱們的入口服務器上建立一個Web Farm。在IIS中右擊Server Farms -> Create Server Farm，數據庫

　　咱們勾上「Server farm is available for load balancing(在Web Fram中使用負載均衡)」，下面的「Provision server farm」，咱們也勾上，併爲它輸入一個帳戶，這個帳戶要求有權限能夠訪問這個Web Farm裏面的全部服務器。Provision 主要是用來實現主-從服務器同步的，咱們暫時先忽略它，後面再具體講。swift

　　咱們將192.168.1.130設置咱們的主Web 服務器，一會咱們結合Provision(俺不知道這個翻成中文該叫什麼，直譯「提供」好像很彆扭) 功能就能夠實如今主服務器上部署和更改配置就會被自動同步到其它的服務器上。完成建立Web Farm以後，咱們就能夠在IIS中進行後面的配置了。咱們經過點擊每個Web Farm下的Servers來查看每個Web服務器的狀態，是否是鏈接正常等等。windows

　　同時咱們還能夠點擊每個Web farm來進行如下功能的管理，這裏咱們就點擊Mono。緩存

配置Load Balance 算法服務器

　　咱們首先要作的就是進入「Load Balance」，在這裏你能夠選擇負載均衡的算法：輪轉調度，隨機分配，URL參數，請求頭等。若是不瞭解這些算法幹什麼的，那就去複習上一篇吧。APR爲咱們提供瞭如下7種算法：cookie

Weighted round robin 根據權重按照請求數據進行分配
Weighted total traffic 根據權重按照請求和響應字節大小進行分配
Least current request 優先轉發給那個當前處理最少請求的服務器
Least response time 優先轉發給那個當前響應最快的服務器
Server variable hash 根據服務器變量的hash來分配請求，這裏面的服務器變量包括Cookie, URL,頭信息等，詳情點這裏。
Query string hash 根據URL查詢字符串的hash來分配請求，若是查詢字符串包含多個參數（?name=jesse&location=sh），則是用整個查詢字符串的hash來做判斷。
Request hash 根據服務器變量或者是URL的hash來分配請求，好比說服務器變量是QUERY_STRING，那麼hash的值就是query string中對應的那個值。

　　你們能夠已經猜到，後面3種算法是能夠利用來實現這種分佈式環境下session的訪問的，可是因爲要涉及到其它的配置，因此咱們後面再講，讓咱們先專一於把這個負載均衡配置完，因此咱們就裏就先選擇比較簡單的Least response time，誰當前返回響應最快咱們就把請求給它，驗證了那句話，「能者多勞啊」。

配置轉發規則

　　APR的機制是作爲一個代理服務器，它負責接收請求，可是不作任何處理，而是直接將請求分發給具體的WEB服務器。同時咱們還能夠配置一些規則，有一些請求轉發，有一些請求不轉發，這就要感謝咱們的url rewrite組件了。咱們能夠進入「Routing Rules」來進行相關的配置。

網站部署與同步

安裝程序和運行環境同步

　　在實際的環境中，若是咱們使用NLB在第一次部署的時候，就須要一個服務器一個服務器的部署，並且若是要對IIS進行其它的一些配置就會顯得很煩瑣。在APR中給咱們提供的Provision功能，就能夠幫助實現這樣的同步功能。

　　在Server Farm的功能視圖中，咱們能夠找到如下兩種類型的Provision:

Application Provisioning: 主要是用來同步網站相關包括內容，配置等等，Web Deploy就是用在這裏了。
Platform Provisioning：主要是用來同步安裝程序的，其實這裏面的Platform是指咱們上面安裝的 Web Platform Installer，也就是說咱們在主服務器上經過Web Platform安裝的程序或者組件，若是啓用了Platform Provisioning的話，其它全部的服務器也會自動安裝上。

　　咱們能夠來作一個Platform Provisioning的例子，點擊咱們的Server Farm -> 在右邊的功能視圖中雙擊Platform Provisioning -> 勾選下面兩個選項。

　　而後咱們點擊左右的Servers，選中咱們的主服務器（Primary)，在右邊的操做列表中選擇「Install Product」，在彈出的窗體中安裝的程序就會被自動安裝到當前Server Farm中的全部其它服務器中。

網站內容同步

　　和上面的思路同樣，咱們不須要每個程序都部署一遍，咱們只須要在主服務器上部署一遍就能夠了，全部的內容以及IIS的設置都會被自動同步到其它服務器上，這就是Application Provisioning來幫咱們實現的。咱們能夠經過點擊咱們的Server Farm ->在右邊的功能視圖中雙擊「Applicaiton Provisioning」而後勾選下面的兩項便可。

　　接下來，咱們只須要在咱們的主服務器上創建咱們的站點而後部署咱們的網站便可，包括對網站進行一些應用程序池的配置也是隻須要在主服務器上完成的，咱們就不須要到每一臺服務器上都去佈置一遍了。

配置入口服務器

　　既然入口服務器不作任何處理只是轉發請求的話，那咱們還須要把咱們的網站的內容放在入口服務器的IIS下麼？這個就取決於不一樣的場景了，你能夠建一個空的站點什麼也沒有，你也能夠用它來作一個簡單的文件服務器，在上一步中將靜態文件不轉發便可，讓咱們Web Farm中的服務器只處理動態的請求，也能夠減輕他們的壓力。固然若是你有單獨的文件服務器那就更好了。做爲測試用途咱們在入口服務器上就不建任何網站了，直接使用安裝IIS自帶的那個默認網站便可。

　　有人可能會有疑問，由於我在配置Server Farm的時候一樣也有這樣的一個疑問。「全部的請求都是由入口服務器接收，而後再分發給Farm中具體的服務器的，那入口服務器的那個網站該如何配置呢？是用80仍是8080端口，若是我建了好幾個網站，那到底哪個網站的請求會被Farm拿到再進行轉發呢？」

　　我在入口服務器中沒有作任何網站的配置，也就是說本地有一個http://localhost的網站是能夠訪問的，對於外部來講它的地址就是 http://192.168.1.129/，那麼爲何當外部訪問 192.168.1.129的時候，它就會被Farm 中的服務器處理呢？這就要多虧咱們的Url Rewrite模塊了，咱們能夠點擊咱們的Farm Mono，進入到功能視圖->而後點擊 Routing Rules -> 在Routing Rules 右側的操做列表中點擊 URL Rewrite... 對Routing Rules進行更詳細的管理。

　　在咱們的URL Rewrite窗口，咱們就會看到已經爲咱們默認建立了一條入站的規則。

　　咱們能夠雙擊那條規則查看詳細，或者進行編輯，咱們能夠看到這條規則其實是用通配符匹配了全部的入站請求，而後轉發給咱們的Server Farm: Mono。原來是URL Rewrite在這裏起了做用，固然咱們也可能把 *改爲其它的通配符，以及使用正則表達式來匹配都是能夠的，這些都是URL Rewite裏面的功能，是能夠直接搬過來用的。

　　URL Rewrite幫助咱們匹配入站請求，而後轉發給Farm，在Farm層面 APR根據咱們配置的負載均衡算法將請求轉發給具體的服務器去處理請求。如今咱們再回過頭來看看咱們最開始安裝的5個組件都分別起到了什麼做用。

Web Deploy : 參與Application Provisioning（網站內容及配置同步）
Web Platform Installer: 參與Platform Provisioning( 應用環境同步）
Web Farm：主要組織者及容器
Application Request Router: 負載均衡處理
URL Rewrite: 入站請求匹配等

驗證負載均衡

　　到這裏爲止，咱們用 APR + Web Farm搭建的負載均衡就完成了，最終結果是咱們在外面訪問 http://192.168.1.129的時候，其實是由咱們Farm中的3臺Web 服務器處理的，口說無憑，咱們來驗證一下。驗證的方法很簡單，咱們在每一個服務器下放不一樣的文件用來標識當前是哪一個服務器在處理響應（記得在部署文件的時候要先把Application provisioning關閉掉，否則主服務器上的文件會被同步到其它的服務器上去的）。

　　在web-02和 web-03上，分別返回不前的服務器的名字就能夠了。可是在測試上可能會遇到一點小問題，那就是當咱們訪問http://192.168.1.129的時候，老是由web-01處理的，由於咱們的頁面幫簡單，又只有一個用戶在訪問，全部後面兩臺服務器壓根沒有發揮做用。這時候咱們就能夠把web-01和 web-02從 Farm中移除掉，那麼全部的請求就會被web-01來處理了。

　　就是這麼簡單，Web Farm給咱們提供的這個功能很是的實用，咱們能夠在運行時隨時動態的添加或移除服務器。還記得之前咱們只有一臺服務器的時候，爲了儘量的不影響用戶，發佈都選擇在晚上的10點之後，因此常常是一發布就通宵。想一想若是有這個功能，白天也能夠發佈了，只要先把一些機器從Web Farm中拿下來，發佈好測試經過以後再放上去而且把別外那一些也拿下來發布就行了。固然這種場景只適合一些中小型的網站，一旦網站大了，那發佈將會是一個很是嚴格的流程，並且通常會有專門的發佈人員或者工具。

Session在APR 分佈式環境下的應用

　　關於Session在分佈式環境下的使用實際上是有爭議的，有人說老師都不讓用Session了，可是有人又千方百計的想要使用它。咱們暫且不討論它的正確與否，由於沒有最好的架構，只有最合適的架構，正所謂存在即合理。咱們都不得不認可Session在不少管理系統，以及一些小型的網站的開發上帶來了很大的便利性，開發快速同時又能夠帶來看得見的性能提高。全部我的認爲，用仍是不用那就看場景吧。可是咱們從學習的角度出發，仍是應該考慮到各類可行性，以及他們之間的利與弊，這樣才能幫助咱們在真實狀況下作出最合適的決策。

Server Affinity（服務器關聯性）

　　在Farm的功能視圖中，有一個Server Affinity的功能能夠用來跟蹤請求或者說提供一種服務器和客戶端之間的粘性，當第一個請求被處理以後，這個請求所在客戶端後面發起的全部請求都會交給一樣的服務器來處理，這就是Server Affinity。APR爲咱們提供了兩種選項：

Client Affinity:　會給來自不一樣客戶端的請求分配一個cookie，而後根據這個cookie來識別請求應該由哪一個服務器來處理。
Host Name Affinity：根據Host name來做粘性處理，它還有兩種provider能夠採用：
- Microsoft.Web.Arr.HostNameRoundRobin: 保證儘可能平均分配到服務器
- Microsoft.Web.Arr.HostNameMemory: 根據內存使用狀況來分配，保證各個服務器的內存使用狀況達到均衡。

　　原來在APR這種分佈式架構下使用Session是這麼的簡單，並且咱們能夠根據實際狀況，Client Affinitt 和 Host Name Affinity一塊兒使用。

搭建多臺APR服務器來提高可靠性

　　還記得咱們在上一篇中提到的，引入負載均衡幫提升了兩點：可靠性和可擴展性。多臺服務器共同處理的狀況下，哪怕其中部分出了問題也不會致使整個網站沒法訪問，提升了咱們的可靠性。隨時動態的添加和移除服務器而不影響網站的訪問，提供了咱們的可擴展性。可是這裏還有一個問題，可是若是APR所在的那個服務器出了問題怎麼辦？雖然這種可能性比較低，由於咱們的APR服務器只是作了很簡單的轉發請求的功能，並無運行真實的網站，但仍然不排隊會有其它的異常致使IIS或者Web Farm中止運行，對於像這樣的問題，咱們就能夠經過部署多臺APR服務器來再一次提高咱們網站的可靠性。

　　一臺APR服務器能夠將請求分發給具體的服務器，若是是多臺APR服務器，那誰來決定請求是由哪臺APR服務器處理呢？

　　還記得咱們上篇講的NLB麼？它不須要一臺單獨的服務器配置，只須要給目標機器都裝上NLB，而後配置一個暴露給外部的地址就能夠了。因此此次當咱們訪問外部地址的時候會有接下來的幾步動做：

NLB最早拿到請求信息，而後具體的APR服務器再去響應請求
當某臺APR響應請求的時候會根據配置好的負載均衡算法交給後面具體的Web服務器去處理
Web服務器請求完以後，再把響應信息返回給客戶端

小結

　　使用APR相對於NLB來講給咱們提供了更全面的負載均衡功能，結合APR和NLB一塊兒使用帶來更高的可用性，可是因爲APR採用的是代理的方式，因此性能會比NLB低一些，可是有時候穩定更重要，不是麼？固然還有不少其它的方案咱們都是能夠去嘗試的，好比說Ngnix好久之前就已經在開源社區得到了很好的聲譽。咱們這兩篇算是讓你們對負載均衡有一個比較感性的認識，真實的項目過程當中還要考慮咱們代碼的架構，如何保證咱們的系統可以在分佈式環境下完美運行，並真正發揮分佈式的力量，咱們還有很長的一段路要走，用分佈式緩存替代Session方案，數據庫羣集，服務羣集和隊列等，咱們一個一個的攻破，歡迎你們持續關注！最後祝你們上班編碼快樂 :)

做者：Jesse 原文地址：http://www.cnblogs.com/jesse2013/p/dlws-loadbalancer2.html

《一棵樹-博客園》收集整理，轉載請註明出處！