.NET開發框架(三)-高可用服務器端設計

咱們對框架功能做了簡述，演示視頻請點擊 這裏查看 ，若須要查看更多此框架的技術文章，請關注.NET框架學苑公衆號！

本章節，咱們專門講解一下，如何在Window服務器下，設計高可用的框架。

咱們的框架設計採用的是Window版本的服務端設計：

總體框架圖以下，

爲何咱們須要如此設計？

本文僅簡述NLB與ARR的利與弊，更多技術文章日後推出。

咱們引入NLB，相對於ARR來講，ARR是應用級別的負載均衡方案，ARR只能作請求入口的分發服務，而NLB則是服務器級別的負載均衡方案。

若是微軟的這兩款方案咱們結合起來使用，便可搭建高可用網站方案。

Application Request Route與NLB高可用方案的演進

一、Application Request Route方案，以下圖

 

缺點：

ARR能夠檢測到你的iis應用是否可用，並對用戶的請求實施負載均衡方案，根據咱們配置的負載均衡算法，把用戶的請求分發到應用服務器中。

可是，若是咱們的ARR服務器down掉以後，咱們的整個應用程序就沒法使用，達不到24*7用不宕機的高可用要求。

 

二、NLB的網路負載平衡方案

缺點：

NLB能夠最多能夠配置32臺服務器，這32臺服務器經過擁有本身的獨立ip以外，還共有一個虛擬IP，用戶訪問虛擬ip，nlb集羣根據配置的負載算法來肯定把用戶的請求分發給那臺應用服務器，若是一臺NLB服務器down掉，則不會影響消息的分發可達到7*24小時不down機的高可用方案。

可是，NLB不能檢測應用你的iis網站是否down掉，只能檢測服務器是否down掉，這樣一來，若是你的iis網站已經中止啦，nlb還給分發用戶請求，那樣麻煩可就來啦。

那麼咱們使用微軟的技術怎麼樣作到網站的高可用呢？對，就是NLB+Application Request Route .

 

三、NLB+Application Request Route 方案

優勢：用戶請求虛擬ip，接入nlb，nlb檢測一臺可用的服務器，請求轉發給arr，arr檢測可用的網站把用戶請求給分派處理，造成高可用方案。

框架設計預研中，靈感來源參考文獻：https://cnblogs.com/knowledgesea/p/5157565.html

 

通過綜合分析後，咱們最終採用了NLB+ARR的結合，造成以下設計圖

 

對於此框架的設計（優勢與缺點），元芳，您怎麼看？歡迎掃右上方二維碼，關注公衆號，留言吐槽。