本篇的主要目的是帶領你們一塊兒來使用ARR來實現一個三層部署架構。這裏的三層部署架構主要是由:服務層,應用程序服務器層已經數據層實現。以下圖所示: css
每次一提到"層"這個字的時候,彷佛感受這個字特別的惹火。不少朋友開始討論起來,因而不少的看法和理解就出來了:有人說:架構就是分層;三層就是指:顯示層,業務層,數據訪問層… html
無論上述的理解和爭論對錯與否,這裏不會對這些理論和概念進行過多的闡釋,這裏有一點提到的就是:不要將物理層Tier和邏輯層Layer混在一塊兒講,或者說,不要將應用程序的邏輯層與物理的部署層混爲一談! 數據庫
注:在本身的學習和工做的經歷中有這樣的感受:不少時候,所學的東西會攪在一塊兒,而且甚至感受他們相互矛盾,還會顛覆本身以前不少的理解和見解,有時候確實感受很是痛苦,可是也是像是鳳凰的重生。其實這不是什麼壞事,知識和經驗就是在這過程當中,不斷的思考,總結,提煉出來的!其實到後來你們就能夠發現:咱們沒有必要死扣一些概念,什麼層啊,模式,都不是關鍵,鍛煉出一種思惟纔是最有價值的。 瀏覽器
咱們這裏講的是物理層的部署。 服務器
正如以前同樣,咱們來作一些準備工做: 架構
另外,我也把三臺服務器的相關配置說明一下: 學習
第一步:準備工做 spa
通常而言,咱們判斷是不是對靜態文件進行請求,主要是經過檢查請求的中是否包含文件的擴展名,例如.js,.png等。固然,在一些狀況下,咱們還以動態的方式來對靜態文件的請求進行處理,例如,咱們站點中寫了一個相似FileHandler的HttpHandler,而後經過相似的www.agilesharp.com/file?fileid=xxxxx的方式來 處理全部對文件的請求。這兩種方式各有優缺點和各自的用途,咱們這裏不作討論。 htm
不少時候,咱們在靜態文件放在站點的文件夾中,例如/images/,/css/,/js/等。下面,咱們開始演示,咱們爲了確認對靜態文件的請求是由安裝了ARR所在的服務器處理的,咱們分別在三服務器的站點中放置三張名字同樣可是內容不一樣的圖片,以下: 圖片
其餘服務器上面的站點結果和這個相似,只是把圖片的內容改成了"安捷雨希"而已。
第二步:在ARR中配置對靜態文件的請求
咱們進行這一步操做的主要目的就是:使得ARR所在的服務器來處理全部對站點靜態文件的請求(爲了起到演示做用,這裏對靜態文件的請求,咱們不會包括html的文件)。
下面,咱們就開始操做:
這個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文件的請求也不轉發,看看效果!