載均衡有很多種方法,有硬體負載均衡,軟體負載均衡,還可以從域名解析下手。小編就為大家分享一篇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負載均衡詳解就是小編分享給大家的全部內容了,希望能給大家一個參考,