IIS負載均衡之介紹篇：Application Request Route詳解

說到負載均衡，相信你們已經再也不陌生了，本系列主要介紹在IIS中能夠採用的負載均衡的軟件：微軟的Application Request Route模塊。

   

       其實Application Request Route已經有不少文章介紹過了，可是有不少的文檔都是英文的，筆者在項目中，曾經爲了使用和測試Application Request Route，將有關的文檔已經轉爲中文，在組員之間傳閱，本系列在這些文檔的中，再加入一些使用的心得。

   

本篇議題以下：

Application Request Route介紹

Application Request Route安裝

   

   

系列文章連接：

IIS負載均衡-Application Request Route詳解第一篇： ARR介紹  

IIS負載均衡-Application Request Route詳解第二篇：建立與配置Server Farm

   

Application Request Route介紹

   

Application Request Route（後面簡稱爲ARR）是一個寄宿於IIS7（及之後的IIS版本）的一個基於代理的模塊，它能夠經過判斷Http Headers，Server Variables以及負載均衡算法將HTTP的請求轉發到不一樣的處理服務器之上。ARR的用處以下：

1. 加強應用的可用性與擴展性
2. 更好的利用服務器資源
3. 使得應用程序的部署更加方便，而且支持衛星部署管理與熱替換
4. 更低的管理成本，使得共享宿主的部署成爲可能

   

ARR是基於URL Rewrite Module的，它經過檢測客戶端發來的HTTP請求來作出請求路由的決定。

   

下面，咱們就進一步的看看ARR的一些特徵：

   

1.基於HTTP請求，作出的請求路由的決定

   

       與硬件的負載均衡不一樣（在OSI模型的IP層來決定請求的路由方式），ARR是基於應用層來進行負載均衡的，由於在應用層可用的信息更多（其實談到這裏，是頗有必要把負載均衡的原理講清楚的，可是，由於本系列主要是講述ARR，因此，對已一些底層原理性的概念，不會作過多的涉及，之後計劃爲朋友們系統的講述負載均衡的原理及其實現,能夠參看：負載均衡第一篇-介紹篇）。經過在ARR中使用URL  Rewrite Module，咱們就能夠實基於Http Headers與Server Variables來實現個更強大的路由規則。

   

2.提供多種負載均衡算法

咱們能夠本身決定使用哪種負載均衡算法來進行請求的路由，ARR提供瞭如下6種算法。

   

3.健康檢查

       咱們可使用"實時通訊"和"特定Url測試"來檢查服務器的健康情況。而且，咱們還能夠經過使用不少的參數來決定到底什麼樣的情況纔是健康的正常的服務器，例如，有人認爲只要服務器是開啓的，就是健康的；也有人認爲，服務器開啓，而且處理的請求沒有超載是健康的，等等。另外，咱們還能夠經過使用本身的提供Health Monitoring Provider來實現本身的健康檢查可能。

   

4.客戶端親緣性

       關於親緣性，相信你們再也不陌生，我這裏稍微的提一下：就是更加傾向於，或者喜歡那個。例如，在SQL Server中能夠設置CPU的親緣性，，假設如今有四個CPU，編號分別是A,B,C,D,如今咱們SQL Server的CPU親緣性設置到A上，就是說: SQL Server在處理請求的時候，更加喜歡把請求發送給編號爲A的CPU來處理，固然也會將請求發送給其餘的CPU，可是A的CPU處理請求的機會更多。

   

同理，在ARR中，能夠經過設置客戶端的親緣性，ARR主要是經過使用Cookie來實現的。至於如何實現的，其實也很簡單，這裏暫且不說。

   

這裏就來講說客戶親緣性的一些須要考慮的點：

1. 若是使用了客戶端親緣性，就能夠在應用中使用傳統的Session和Cache，而沒有必要使用分佈式的Session和Cache。這裏，以Session爲例子，由於不少的時候，咱們都須要將一個站點應用部署到多個服務器上，若是在某些地方使用了Session，特別保存用戶的一些數據的時候，就須要使用分佈式的Session，用戶登陸就是一個最明顯的例子（避免用戶從服務器A上登陸，當下一次請求在B服務器處理的時候，還須要再次登陸）。使用客戶端親緣性，ARR就能夠將同一個用戶的請求再次轉發到用戶第一次請求的服務器上。
2. 使用客戶端親緣性，就在必定程度上面失去了負載均衡的意義。由於設置了客戶端親緣性，即便用戶初次請求的服務器如今壓力很大，那麼ARR仍是會將用戶的請求轉發過去。
3. 客戶端親緣性，失去了高可用性。由於頗有可能如今處理用戶請求的服務器已經宕機了，雖然ARR有健康檢查機制，可是ARR仍是能夠將請求發給宕機的服務器，致使請求沒法處理。 

5.宿主名親緣性

理解了上面的"客戶端親緣性"，這裏就更加容易理解了。" 宿主名親緣性"主要使用在共享服務器中的（不少人使用一臺服務器，就是站點部署的時候，購買的是"虛擬地址空間"）。咱們後面在提到的時候，會詳細講解。

   

6.服務器分組

ARR能夠管理不少的服務器組，其中每一組又包含多臺服務器服。

   

7.基於圖形化界面的管理與健康

ARR與IIS集成，而且，經過了可視化的，便於操做的可視化操做界面。

   

   

8.制定請求失敗的跟蹤規則

在ARR中，能夠定義特定的跟蹤規則，當請求處理失敗以後查看跟蹤信息，便於診斷。

   

Application Request Route安裝

下面，咱們就介紹ARR的安裝，便於你們快速上手與學習：

ARR依賴於如下組件：

1. Microsoft URL Rewrite Module for IIS 7.0.
2. Microsoft Web Farm Management Version 1 for IIS 7.0.
3. Microsoft Application Request Routing Version 1 for IIS 7.0.
4. Microsoft External Cache Version 1 for IIS 7.0.

                

ARR的安裝，須要相關的環境，以下：

1. IIS 7.0 以及之後的版本（筆者在Win 7和Server2008中都安裝過，是能夠的）

   

下面開始進入安裝：

   

1. 下載ARR：

如今ARR已經發展了2.5的版本，能夠說已經很穩定了，筆者也在一些大型項目中已經採用，效果還不錯。

如今地址：http://www.iis.net/download/ApplicationRequestRouting

   

   

2. 如今ARR集成在Web 安裝平臺中，以下：

3.點擊"Install"，開始安裝

4.安裝以後，打開IIS的控制窗口，以下（Win7系統的界面）：

若是看到有"Server Farms"，就說明安裝OK了。

   

5.配置應用程序池

全部的HTTP請求都須要通過ARR。因此，咱們但願在安裝了ARR的服務器上的IIS要必須不停的運行，不停把請求轉發到其餘的服務器上面，也就是說：這檯安裝了ARR的服務器基本的功能就是請求轉發。

   

假設如今咱們手裏有3臺服務器（編號分別爲A,B,C）來部署agilesharp的站點，安排以下：

 

如今服務器A向外面暴露的地址假設爲:159.12.2.15，那麼咱們在A服務器上創建一個agilesharp的站點，以下：

而且，咱們設置agilesharp站點的應用程序池爲IIS的集成模式。這個時候，由於這個站點其實只是暴露給外面，真正的請求處理在B和C服務器。因此，咱們要設置這個agilesharp的站點的應用程序池，從而它源源不斷的接受HTTP請求（應用程序池默認是不會不斷的介紹請求的，它有一個時間的延時，這個延時的時間每每就是默認的請求處理時間），而後由ARR轉發。

   

設置以下：

將Idle Time-out (minutes)設置爲0,而後保存就OK了。 

OK，介紹就到這裏，下一篇，咱們就來看看一些具體的應用！

本文出自 "燕洋天" 博客，請務必保留此出處http://yanyangtian.blog.51cto.com/2310974/817136