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

2021-03-02 dotNET跨平臺

說到負載均衡，相信大家已經不再陌生了，本系列主要介紹在IIS中可以採用的負載均衡的軟體：微軟的Application Request Route模塊。

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

本篇議題如下：

Application Request Route介紹

Application Request Route安裝

 

Application Request Route介紹

        ApplicationRequest Route（後面簡稱為ARR）是一個寄宿於IIS7（及以後的IIS版本）的一個基於代理的模塊，它可以通過判斷Http Headers，Server Variables以及負載均衡算法將HTTP的請求轉發到不同的處理伺服器之上。ARR的用處如下：

1.      增強應用的可用性與擴展性

2.      更好的利用伺服器資源

3.      使得應用程式的部署更加方便，並且支持衛星部署管理與熱替換

4.      更低的管理成本，使得共享宿主的部署成為可能

ARR是基於URLRewrite Module的，它通過檢測客戶端發來的HTTP請求來做出請求路由的決定。


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

基於HTTP請求，做出的請求路由的決定

與硬體的負載均衡不同（在OSI模型的IP層來決定請求的路由方式），ARR是基於應用層來進行負載均衡的，因為在應用層可用的信息更多（其實談到這裡，是很有必要把負載均衡的原理講清楚的，但是，因為本系列主要是講述ARR，所以，對已一些底層原理性的概念，不會做過多的涉及，以後計劃為朋友們系統的講述負載均衡的原理及其實現）。通過在ARR中使用URL  Rewrite Module，我們就可以實基於HttpHeaders與Server Variables來實現個更強大的路由規則。

負載均衡算法

我們可以自己決定使用哪一種負載均衡算法來進行請求的路由，ARR提供了以下6種算法。

健康檢查

我們可以使用「實時通信「和」特定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來實現的。至於如何實現的，其實也很簡單，這裡暫且不說。

 

這裡就來說說客戶親緣性的一些需要考慮的點：

a.      如果使用了客戶端親緣性，就可以在應用中使用傳統的Session和Cache，而沒有必要使用分布式的Session和Cache。這裡，以Session為例子，因為很多的時候，我們都需要將一個站點應用部署到多個伺服器上，如果在某些地方使用了Session，特別保存用戶的一些數據的時候，就需要使用分布式的Session，用戶登錄就是一個最明顯的例子（避免用戶從伺服器A上登錄，當下一次請求在B伺服器處理的時候，還需要再次登錄）。使用客戶端親緣性，ARR就可以將同一個用戶的請求再次轉發到用戶第一次請求的伺服器上。

b.      使用客戶端親緣性，就在一定程度上面失去了負載均衡的意義。因為設置了客戶端親緣性，即使用戶初次請求的伺服器現在壓力很大，那麼ARR還是會將用戶的請求轉發過去。

c.       客戶端親緣性，失去了高可用性。因為很有可能現在處理用戶請求的伺服器已經宕機了，雖然ARR有健康檢查機制，但是ARR還是可以將請求發給宕機的伺服器，導致請求無法處理。

 

5.       宿主名親緣性

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

 

6.      伺服器分組

ARR可以管理很多的伺服器組，其中每一組又包含多臺伺服器服。

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

ARR與IIS集成，並且，通過了可視化的，便於操作的可視化操作界面。

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

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

 

Application Request Route安裝

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

        ARR依賴於以下組件：

1.       Microsoft URL Rewrite Modulefor IIS 7.0.

2.       Microsoft Web Farm ManagementVersion 1 for IIS 7.0.

3.       Microsoft Application RequestRouting Version 1 for IIS 7.0.

4.       Microsoft External CacheVersion 1 for IIS 7.0.

       

        ARR的安裝，需要相關的環境，如下：

IIS 7.0 以及以後的版本（筆者在Win7和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安裝了ARR

進行請求路由

B安裝ARR，就是普普通通的伺服器

處理請求

C安裝ARR，就是普普通通的伺服器

處理請求

 

現在伺服器A向外面暴露的地址假設為:159.12.2.15，那麼我們在A伺服器上建立一個agilesharp的站點，如下：

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

設置如下：

 

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

 

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

相關內容

作者介紹：汪洋，哪合夥CEO，曾大漢電子商務有限公司首席技術官，副總裁，負責公司產品、技術、運營，參與商業模式設計。華康移動醫療前CTO，副總裁，首席架構師。微軟MVP

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

相關焦點

  • IIS負載均衡-Application Request Route詳解第二篇:創建與配置Server Farm
    本系列雖然不難，但是很多的一些知識都是默認需要掌握的，例如：負載均衡的概念，原理，Web Farm等。另外，還可以設置伺服器的權重值（weight），以後之後，我們可以為在ARR中選擇基於權重的負載均衡算法。6.      添加之後，可以看到結果，如下所示：
  • Nginx+SpringBoot實現負載均衡
    前言本篇文章主要介紹的是Nginx如何實現負載均衡。負載均衡介紹介紹在介紹Nginx的負載均衡實現之前，先簡單的說下負載均衡的分類，主要分為硬體負載均衡和軟體負載均衡，硬體負載均衡是使用專門的軟體和硬體相結合的設備，設備商會提供完整成熟的解決方案，比如F5，在數據的穩定性以及安全性來說非常可靠，但是相比軟體而言造價會更加昂貴；軟體的負載均衡以Nginx這類軟體為主
  • 老司機實戰Windows Server Docker:2 docker化現有iis應用的正確姿勢
    前言上一篇老司機實戰Windows Server Docker：1 初體驗之各種填坑介紹了安裝docker服務過程中的一些小坑
  • 雲上構建高可用實例——應用負載均衡
    2 概念摘要  京東雲中應用負載均衡的具體概念和描述參見其產品文檔，這裡羅列一些筆者學習時重要的點：3 負載均衡架構圖  這裡並不畫已經存在於京東雲文檔中的架構圖，這裡描述的是本文所搭建的應用負載均衡的具體樣例架構圖，之後的部署、性能測試均已此圖為準。
  • 大型網站架構系列:負載均衡詳解
    因此軟體負載均衡在網際網路領域大量使用。常用的軟體負載均衡軟體有Nginx，Lvs，HaProxy等。本文參考大量文檔，部分為直接拷貝，參考出處文末。二、Nginx負載均衡Nginx是一款輕量級的Web伺服器/反向代理伺服器，工作在七層Http協議的負載均衡系統。具有高性能、高並發、低內存使用等特點。
  • 阿里雲MVP喬幫主:五大類型負載均衡的原理場景詳解(文末贈書)
    LVS、Nginx、HAProxy、阿里雲 SLB 及硬體負載均衡等，不同的負載均衡應用場景和功能上有很大區別，這取決於負載均衡底層的原理，原理不同導致了不同負載均衡應用場景、功能、性能的巨大差異。而相比在四層、七層的負載均衡應用得要更為廣泛，比如硬體負載均衡、Nginx、HAProxy 熱門的中間件都支持四層、七層的負載均衡。
  • 美國伺服器負載均衡的類型介紹
    美國伺服器網絡的負載均衡是一種動態均衡技術，經過一些東西實時地分析數據包，掌握網絡中的數據流量狀況，把任務合理均衡地分配出去。計算集中型的運用如電子商務網站等，美國伺服器計算負荷會很大的頻繁讀寫運用，比如網絡資料庫，存儲系統則面臨著檢測大量傳輸的運用，比如視頻，因此數據總是無法快速傳送，無法得到最好的效果，所以訪問量大的運用想要合理解決這些問題就是選用負載均衡技術，用多個設備一起完結任務。下面小編就來分享下美國伺服器負載均衡的類型。
  • Windows Server網絡負載均衡技術解析
    例如，本文介紹的網絡負載均衡(Network Load Balance，NLB)便是屬於前端的集群技術，另外尚有屬於中介層的COM+組件負載均衡(Component Load Balance，CLB)，以及後端服務的伺服器集群(Microsoft Cluster Server，MSCS)。
  • Nginx配置文件中文注釋詳解
    Nginx配置文件詳解  #運行用戶 user nobody nobody; #啟動進程 worker_processes 2; #全局錯誤日誌及PID文件 error_log logs/error.log notice; pid logs/nginx.pid;
  • 負載均衡之LVS與Nginx對比
    作者 |  等不到的口琴來源 |  urlify.cn/r26Fve76套java從入門到精通實戰課程分享今天總結一下負載均衡中LVS與Nginx的區別,好幾篇博文一開始就說LVS是單向的,Nginx是雙向的,我個人認為這是不準確的,LVS三種模式中,雖然DR模式以及TUN模式只有請求的報文經過Director,但是NAT模式,Real Server
  • 一文看懂集群、分布式與負載均衡的關係
    在「高並發，海量數據，分布式，NoSql，雲計算......」概念滿天飛的年代，相信不少朋友都聽說過甚至常與人提起「集群，負載均衡」等，但不是所有人都有機會真正接觸到這些技術，也不是所有人都真正理解了這些「聽起來很牛的」技術名詞。下面簡單解釋一下吧。
  • 分布式系統的負載均衡
    什麼是負載均衡？記得第一次接觸 Nginx 是在實驗室，那時候在伺服器部署網站需要用 Nginx 。Nginx 是一個服務組件，用來反向代理、負載平衡和 HTTP 緩存等。那麼這裡的 負載均衡 是什麼？負載均衡（LB，Load Balance），是一種技術解決方案。用來在多個資源（一般是伺服器）中分配負載，達到最優化資源使用，避免過載。
  • The request URL is invalid」的錯誤
    maxUrl="2097151" /> </requestFiltering> </security>滿懷期待的保存，運行，錯誤依舊，好像並沒有什麼卵用這個時候就開始納悶了，為啥不行，會不會沒有生效，想到這兒可能就有很多人像我一樣，想到了iis的全局設置，會不會該項設置不能被覆蓋，我們用的依舊是全部設置的值不用猜測
  • OpenSIPS-關於請求中Record Set和Loose Route再討論
    筆者雖然在以前的文章中多次做過介紹，但是那些介紹都是基於基本的SIP route做的介紹，沒有具體到軟交換層面，例如，OpenSIPS平臺的具體使用方式。本文章進一步討論關於Record Set和Loose Route的背景知識，希望能夠為讀者提供一個針對OpenSIPS的相對比較全面的理解。
  • 初識集群負載均衡的概念和意義
    初識集群負載均衡的概念和意義 本文主要針對集群負載均衡這一概念進行了分析和解說，對於初次解除負載均衡的朋友們，對於集群負載均衡一定要熟悉，因為今後的各種硬體和軟體配置都要用到這個定義。
  • 在JSP編程中Application的使用方法詳解
    ，與session相對用戶來說，application是相對應用程式的，一般來說，一個用戶有一個session,並且隨著用戶離開而消失;而application則是一直存在，類似一個servlet程序，類似整個系統的"全局變量",而且只有一個實例。
  • 負載均衡算法有哪些
    什麼是負載均衡 負載均衡建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和伺服器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。  四個分類 軟/硬體 軟體負載均衡解決方案是指在一臺或多臺伺服器相應的作業系統上安裝一個或多個附加軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
  • AscenLink負載均衡設備性能分析
    在選取大型負載均衡設備的時候，我們顧慮的因素很多。因為其昂貴的價格，我們更要謹慎對待。下文為讀者們介紹一款設備——AscenLink負載均衡設備。它的性能很突出，讓我們隨著文章一起來看看吧。AscenLink負載均衡設備性能1：VPN負載均衡及容錯採用Xtera領先的VPN負載均衡及容錯技術,兩地間可同時建多條VPN鏈路,增加兩地間VPN鏈路的帶寬和速度,當任何一條鏈路發生故障時,AscenLink可自動引導VPNTunnel至正常的鏈路上,使VPN連線不中斷,達到VPN鏈路的雙向負載均衡及容錯｡
  • 數據中心內的負載均衡-MPTCP
    數據中心最常使用的負載均衡算法為ECMP，通過根據數據流的五元組哈希，將這些數據均勻隨機的分散到權重相等的路徑上。這種隨機選路負載均衡***個問題是會產生哈希碰撞。如圖一所示，紅色路徑與藍色路徑產生了碰撞。另一個問題是，用這種***權重（如最短路徑）的方法選出的路徑，無法判斷路徑是否存在擁塞，很可能將流量繼續發送到一個已經擁塞的鏈路上。