載均衡有很多種方法，有硬件負載均衡，軟件負載均衡，還可以從域名解析下手。小編就為大家分享一篇windows第七層負載均衡_基于IIS的ARR負載均衡詳解，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧

不過，今天只講軟件負載均衡。

軟件負載均衡一般分兩種，從網絡協議來講（tcp/ip），主要集中在第四層和第七層進行負載均衡。

第四層就是基于IP進行負載均衡。后面還有一篇文章講這個。

第七層就是應用層。比如各種的WEB服務器。今天就講講IIS的負載均衡。

第七層的Web負載均衡，很多web服務器都支持，比如IIS，Nginx，apache等。現在主要講一下windosw下IIS如何使用負載均衡

IIS使用ARR反向代理，實現負載均衡

什么是正向代理？

代理服務器大家可能聽說過，比如我們說的“科學上網”。就是使用代理服務器，請求經過代理服務器轉到目的服務器。這是一個正向代理。用戶知道自己使用代理，并且充許用戶隱藏客戶端自身。

什么是反向代理？

請求同樣經過代理服務器轉到目的服務器，目的服務器返回給代理服器，代理返回給客戶端。不同的時候，客戶并不知道，訪問的是一個代理服務器。客戶認為他在訪問目的服務器。

兩者的區別基本在于，正向代理是發生在客戶端。反向代理是發生在服務端。

首先，我們先安裝一個Web平臺安裝程序

打開web平臺安裝程序，搜索arr

寫WebApi程序

[Route("api/[controller]")]
public class HomeController : Controller
{
 // GET: api/<controller>
 [HttpGet,Route("GetUserChat")]
 public async Task<ActionResult> GetUserChat()
 {
 var collection = new MongoHelper().GetCollection<OAChat>("OAChat");
 var chatItems =await collection.Find(n => n.ChatType == 2).Limit(5).ToListAsync();
 return ApiJsonFormat.GetJsonResult(chatItems);
 }
}

返回結果

{"ResultCode":1000,"Message":"成功","DetailError":null,"Data":[{"Id":"595225a5bbccc61ff88e89a7","ChatName":"testttt","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-27 17:30:13","LastChatTime":"2017-11-10 17:43:17","LastChatText":"[定位]","IsDisbanded":false},{"Id":"5952445ebbccc71ff8adf671","ChatName":"測試2","ChatType":2,"CreaterUserId":13,"Members":[],"CreateTime":"2017-06-27 19:41:18","LastChatTime":"2017-06-27 19:48:47","LastChatText":"行","IsDisbanded":true},{"Id":"5952463dbbccc71ff8adf67d","ChatName":"巡視頻么么噠噠","ChatType":2,"CreaterUserId":13,"Members":[],"CreateTime":"2017-06-27 19:49:17","LastChatTime":"2017-12-20 19:47:17","LastChatText":"[定位]","IsDisbanded":false},{"Id":"59524c0ebbccc71ff8adf6ae","ChatName":"rrrffff","ChatType":2,"CreaterUserId":13,"Members":[],"CreateTime":"2017-06-27 20:14:06","LastChatTime":"2017-06-27 20:34:54","LastChatText":"6565","IsDisbanded":false},{"Id":"59531cdfbbccc414e8f6769f","ChatName":"都紛紛fee俄方熱熱","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-28 11:05:03","LastChatTime":"2017-06-28 11:05:13","LastChatText":"123","IsDisbanded":true},{"Id":"59531de5bbccc414e8f676a1","ChatName":"天賦過人托管人","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-28 11:09:25","LastChatTime":"2017-06-28 11:09:33","LastChatText":"呃呃呃","IsDisbanded":true},{"Id":"59531e40bbccc414e8f676a3","ChatName":"熱熱","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-28 11:10:56","LastChatTime":"2017-06-28 17:58:41","LastChatText":"333","IsDisbanded":false},{"Id":"59532140bbccc414e8f676a6","ChatName":"會厭結核有機會好好","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-28 11:23:44","LastChatTime":"2017-06-28 11:24:40","LastChatText":"eee","IsDisbanded":true},{"Id":"595321d3bbccc414e8f676a8","ChatName":"656565656","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-28 11:26:11","LastChatTime":"2017-06-28 18:50:08","LastChatText":"ggg","IsDisbanded":false},{"Id":"5954d0eebbccc40fecbea435","ChatName":"r","ChatType":2,"CreaterUserId":76,"Members":[],"CreateTime":"2017-06-29 18:05:34","LastChatTime":null,"LastChatText":null,"IsDisbanded":false}]}

//設置ARR

192.168.99.5 //代理服務器
192.168.99.6 //目的服務器
192.168.99.7 //目的服務器
192.168.99.8 //目的服務器
192.168.99.10 //目的服務器
192.168.99.11 //目的服務器
192.168.99.12 //目的服務器
192.168.99.13 //目的服務器

首先給服務器安裝net core 運行環境

DotNetCore.2.0.5-WindowsHosting 安裝包內置SDK和WindowsHosting，直接安裝這個，安裝成功之后，要重啟服務器才能生效。然后部署Web就可以訪問了

選擇無托管代碼

好，部署成功之后，可以正常訪問了

好，馬上試一下部署ARR，是否能實現反向代理

添加一個入口站點，默認端80。

非常簡單數據出來啦。理論就搭建成功了。

192.168.99.5 的站點，還有兩個地方要注意設置

IIS程序池的隊列長度。由于這是代理服務器很多請求都會經過這個站點，所以這個長度就設置長一點。默認值是1000。

IIS程序池的閑置超時。設置為0，將長期保持不回收狀態。

轉化服務器的網卡要目的服務器的網卡要好，這樣能支撐更大的流量需求。

下面把一些細節介紹一下，然后做一下壓力測試，就大功告成啦。

安裝ARR完成之后，會出現兩個

URL重寫充許你定則重寫規則，我沒怎么用過，特么不嫌麻煩。這就不細講了。

Server Farms可以對你的集群進行管理，健康檢查，轉化統計。

分別對應的是：緩存，健康檢查，負載均衡，監視和管理，代理，路由規則，服務器相關性

健康檢查：主要是檢查各個服務器的IIS是否正常運作。（這個也是第七層負載均衡的一個好處，能感知Web服務器是否正常運作）

負載均衡：主要作用是設置各種分發規則。比如根據權重，最小響應時間，最小請求量等

監視和管理：主要讓你看到各個服務器的健康情況，請求量，失敗量，緩存命中率等。

服務器相關性：主要提供一種服務器和客戶端之間的粘性。簡單理解就是，客戶端A的請求分配到服務器B處理之后，以后客戶端A的請求都分配到服務器B處理。（這樣設計理論會使用分配不均，當然也有好處，比如可以使用本地session）

Client Affinity:　根據客戶端的cookies處理粘性

Host Name Affinity 根據Host name處理粘性

下面試一下壓力測試，用大微軟的VS2017進行壓力測試，細節我就不講了，貼了一些結果吧。

在測試過的過程中，經常現一個502.3 Timeout Errors的問題，是ARR3.0的問題，換回ARR2.0 版本之后，就正常了。

啟動性能監視器，統計每秒請求數，也與壓力測試的結果吻合。每秒358次。

ARR測試到止結束，下班。

以上這篇windows第七層負載均衡_基于IIS的ARR負載均衡詳解就是小編分享給大家的全部內容了，希望能給大家一個參考，