IIS負載均衡-Application Request Route詳解第四篇：使用ARR實現三層部署架構
系列文章鏈接：
IIS負載均衡-Application Request Route詳解第一篇： ARR介紹
IIS負載均衡-Application Request Route詳解第二篇：創建與配置Server Farm
IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（上）
IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（下）
IIS負載均衡-Application Request Route詳解第四篇：使用ARR實現三層部署架構
本篇的主要目的是帶領大家一起來使用ARR來實現一個三層部署架構。這里的三層部署架構主要是由：服務層，應用程序服務器層已經數據層實現。如下圖所示：
每次一提到“層”這個字的時候，似乎感覺這個字特別的惹火。很多朋友開始討論起來，於是很多的見解和理解就出來了：有人說：架構就是分層；三層就是指：顯示層，業務層，數據訪問層…
不管上述的理解和爭論對錯與否，這里不會對這些理論和概念進行過多的闡釋，這里有一點提到的就是：不要將物理層Tier和邏輯層Layer混在一起講，或者說，不要將應用程序的邏輯層與物理的部署層混為一談！
注：在自己的學習和工作的經歷中有這樣的感覺：很多時候，所學的東西會攪在一起，並且甚至感覺他們相互矛盾，還會顛覆自己之前很多的理解和看法，有時候確實感覺非常痛苦，但是也是像是鳳凰的重生。其實這不是什么壞事，知識和經驗就是在這過程中，不斷的思考，總結，提煉出來的！其實到后來大家就可以發現：我們沒有必要死扣一些概念，什么層啊，模式，都不是關鍵，鍛煉出一種思維才是最有價值的。
我們這里講的是物理層的部署。
正如之前一樣，我們來做一些准備工作：
- 准備三台服務器（可以用虛擬機），其中一台用來處理對靜態內容的請求，例如圖片，腳本，html頁面等，我們把這一台服務器放在第一層。
- 再用一台服務器放在第二層，作用應用程序服務器，用來處理動態內容的請求。
- 另外一台服務器用來部署數據庫。
另外，我也把三台服務器的相關配置說明一下：
- 三台服務器安裝了Win Server 2008和IIS
- 在那台處理靜態文件的服務器上，我們安裝ARR，也就說，此時這一台服務器做兩件事情：負責轉發請求；處理對靜態文件的請求。
第一步：准備工作
一般而言，我們判斷是否是對靜態文件進行請求，主要是通過檢查請求的中是否包含文件的擴展名，例如.js，.png等。當然，在一些情況下，我們還以動態的方式來對靜態文件的請求進行處理，例如，我們站點中寫了一個類似FileHandler的HttpHandler，然后通過類似的www.agilesharp.com/file?fileid=xxxxx的方式來 處理所有對文件的請求。這兩種方式各有優缺點和各自的用途，我們這里不做討論。
很多時候，我們在靜態文件放在站點的文件夾中，例如/images/，/css/,/js/等。下面，我們開始演示，我們為了確認對靜態文件的請求是由安裝了ARR所在的服務器處理的，我們分別在三服務器的站點中放置三張名字一樣但是內容不同的圖片，如下：
其他服務器上面的站點結果和這個類似，只是把圖片的內容改為了“安捷雨希“而已。
第二步：在ARR中配置對靜態文件的請求
我們進行這一步操作的主要目的就是:使得ARR所在的服務器來處理所有對站點靜態文件的請求（為了起到演示作用，這里對靜態文件的請求，我們不會包括html的文件）。
下面，我們就開始操作：
- 啟動IIS
- 創建一個Server Farm，並且添加兩台服務器，如圖所示：
這個205服務器就是我們安裝了ARR的服務器，因為此時我的demo站點部署在8080端口，所以這里要開啟“Advance setting“。
再添加第二台服務器，其上的站點是部署在80端口。
添加的結果就如下：
大家到這里就可能有點納悶了：怎么只是添加了兩台服務器呢，不是准備了三台服務器嗎？
理由很簡單，有一台服務器是作為數據庫服務器，而不是作為http請求處理的服務器（換句話說，http請求不會發送到數據庫服務器上去），並且數據庫服務器是我們在應用程序中通過連接字符串來連接的。
在我還沒有配置Server Farm之前，我分別在兩台服務器上瀏覽了站點：http://localhost:8080/images/logo.png，此時看到的結果如下：
從圖中可以看到，我請求logo.png的時候，是應用程序的服務器（沒有安裝ARR的那個服務器）處理了這個請求。
下面我們開始配置。
1. 選中創建的Server Farm
2. 選中“Routing Rules“，如下：
3. 雙擊“Routing Rules“，如下：
主要注意圖中標紅的兩個地方：第一個是配置哪些擴展名的文件不轉發請求。在圖中，我們配置了*.png，就說明，如果ARR客戶端要請求.png文件，那么ARR就不將這個請求轉發給Server Farm中的其他服務器，而是有本機直接處理。
配置好了之后，我們就點擊“Apply“，然后再次運行瀏覽器，來看效果。
大家看到上面的圖，右邊圖是我在ARR所在的服務器發送請求得到的結果，而左邊是我直接在應用程序服務器上面查看圖片。
還記得在之前沒有配置的時候，我在ARR服務器上面發送請求的時候，看到的是“安捷雨希“，說明ARR轉發了對png文件的請求；而當我們配置之后，此時ARR就不在轉發這個請求，而是自己處理，所以我們看到了”agilesharp“的圖片。
這里，依然給大家留一個作業：大家可以把對html文件的請求也不轉發，看看效果！