IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡
在前兩篇文章中，我們已經(jīng)講述如何配置與安裝ARR，從本篇文章開始，我們將重點的來講述如何在使用ARR進行負載均衡。
??????? 本篇文章的目的主要是一步步的帶領(lǐng)大家如何配置和使用ARR來進行Http請求的負載均衡，從而實現(xiàn)高可用與高擴展性。同時，本篇文章還會著重的講述ARR是如何監(jiān)視服務器的健康狀況，同時也會講述如何設(shè)置客戶端的親緣性。
??????? 為了演示，我這里做了如下的準備工作：
1.??????配置了三臺服務器（名稱定為A,B,C），并且安裝的是Win Server 2008，IIS與.NET Framework也安裝了。
2.??????在服務器A上面安裝了ARR模塊。服務器A起到一個請求轉(zhuǎn)發(fā)的作用！
3.??????創(chuàng)建了一個Server Farm，并且將服務器B，C加入到了Farm中。
?
另外對于服務器B，我們就部署了一個默認的站點，如下：
? ? ? ? ? ? ? ? ? ? ? ??
可以看出，配置的站點相當?shù)暮唵?#xff01;大家可以自己去配置不同的站點，然后在ARR添加服務器的時候，指向服務器的其他端口！
下面，我們看看，站點中有哪些內(nèi)容：
??????? 在這里，我簡單的放置了一個網(wǎng)頁Default.html，這個頁面的內(nèi)容也非常的簡單，其中的205是服務器的編號，這樣寫主要是為了我們后面便于辨別到底是哪一個服務器處理了我們的請求！
??????? 另外需要注意的是，我們在站點中，放置了一個health.txt文件，內(nèi)容如下：
這個文件主要是給ARR進行健康檢查用的，在后面的配置中，我們就可以看到它的作用了！
服務器C的配置和服務器B類似，只是頁面文件的內(nèi)容改為了“Response come from 216”。
整個服務器的結(jié)構(gòu)如下：
配置之后的結(jié)果如圖所示：
下面開始確認相關(guān)的配置信息。
確認Url Rewrite的規(guī)則
1.??????啟動IIS
2.??????選擇建立的AppServerFarm
3.??????看到如下的界面：
4.??????雙擊“Routing Rules”圖標，確認“Use URL Rewrite to inspectincoming requests”被選中，如圖：
5.??????啟動瀏覽器，輸入: http://localhost/，得到了如下的頁面結(jié)果：
?? 很顯然，ARR的請求轉(zhuǎn)發(fā)起作用了，確認這是205服務器在處理請求！下面，為了確認，我們來查看一下。
請求監(jiān)控配置
1. 選擇AppServerFarm，然后選中“Monitoring and Management”
2. 雙擊之后，顯示如下：
??????? 發(fā)現(xiàn)：果然是205服務器在處理請求！
配置ARR健康檢查機制。
1.??????選擇AppServerFarm，然后選中右邊的“Health Test”圖標。
2.??????雙擊圖標，得到如下界面：
大家還記得我們之前在每個站點放置的health.txt文件嗎，之前說過，這個文件是用來做健康檢查的：ARR定時的去通過GET請求獲取文件的內(nèi)容，然后和配置中的“Response match”內(nèi)容進行對比，如果二者一樣，說明Server Farm中的服務器正常。這和我們常常用ping命令測試網(wǎng)絡(luò)是否連通一個道理。
??????? 注意：這里在URL中放置的:http://localhost/health.txt。為什么？
我們知道，Farm中服務器很多，這里不可能設(shè)置很多的值,例如16.187.153.205/health.txt，16.187.153.216/health.txt。 ARR不允許我們這樣設(shè)置。這里之所以讓URL為localhost，ARR在健康檢查的時候，是讓各自的站點各自的去請求自己的health.txt，而每一個站點對于各自的health.txt而言，都是local的。這里的內(nèi)幕，大家不需要太清楚，只要懂得配置就OK了。
另外，還可以設(shè)置健康檢查的周期，和過期的時間！
?
配置客戶端親緣性
選擇AppServerFarm，然后選中右邊的“Server Affnity”圖標。
2.??????雙擊，然后看到如下界面：
客戶端的親緣性是通過cookie來實現(xiàn)的?；镜牧鞒膛c原理是這樣的：
a.??????請求發(fā)送給ARR，假如此時ARR請求轉(zhuǎn)發(fā)給服務器B。
b.??????服務器B處理請求，然后將響應發(fā)送給ARR所在的服務器。
c.???????此時ARR在響應中加入一個cookie，并且記錄請求處理的服務器為B。
d.??????下一次，ARR檢查發(fā)來的請求，如果發(fā)現(xiàn)包含了之前設(shè)置的cookie，并且檢查cookie里面的服務器信息，然后將請求轉(zhuǎn)發(fā)給對應的服務器。
拒絕新的連接
??????? 在使用ServerFarm的時候，我們可以讓Farm中的一些服務器不在接受新的請求連接，處于一種離線的狀態(tài)。從而，使得我們可以之后將這些離線的服務器拿去維護等。
??????? 大家可以這里就有一個疑問了：如果客戶端設(shè)置了服務器的親緣性，而這個服務器又離線了，之前建立的session和相關(guān)的信息怎么辦？
??????? 其實這里所說的離線，并不是真的離線，斷網(wǎng)！而是說，這些服務器不在接受新的請求，之前已經(jīng)接受的請求，還是會處理完的！
??????? 操作的步驟如下：
1.??????選中“appServerFarm“
2.??????展開“Servers“節(jié)點
3.??????在右邊列出的服務器中，點擊“右鍵“，使其離線，如圖：
??????? 這里給大家留一個小作業(yè)：把Farm中的一臺服務器下線，然后發(fā)送請求到ARR部署的那個服務器，看看效果！
到這里，大家就可以開始配置和使用ARR進行負載均衡了！
之后的文章，我們講述的深入一些！
相關(guān)內(nèi)容
構(gòu)建高性能.NET應用之配置高可用IIS服務器-第一篇：IIS必須掌握的知識
構(gòu)建高性能.NET應用之配置高可用IIS服務器-第二篇 IIS請求處理模型
構(gòu)建高性能.NET應用之配置高可用IIS服務器-第三篇 IIS中三個核心組件的講解（上）
構(gòu)建高性能.NET應用之配置高可用IIS服務器-第四篇 IIS常見問題之：工作進程回收機制（上）
構(gòu)建高性能.NET應用之配高可用IIS服務器-第五篇 IIS常見問題之：工作進程回收機制（中）
IIS負載均衡-Application Request Route詳解第一篇： ARR介紹
IIS負載均衡-Application Request Route詳解第二篇：創(chuàng)建與配置Server Farm
作者介紹：汪洋，哪合伙CEO，曾大漢電子商務有限公司首席技術(shù)官，副總裁，負責公司產(chǎn)品、技術(shù)、運營，參與商業(yè)模式設(shè)計。華康移動醫(yī)療前CTO，副總裁，首席架構(gòu)師。微軟MVP
.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關(guān)注
贊賞
人贊賞
總結(jié)
以上是生活随笔為你收集整理的IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IIS负载均衡-Application
- 下一篇： 【直播预告】创享未来 2016微软开发者