我們對框架功能作了簡述，演示視訊請點選 這裡檢視 ，若需要檢視更多此框架的技術文章，請關注.NET框架學苑公眾號！

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

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

整體框架圖如下，

為什麼我們需要如此設計？

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

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

如果微軟的這兩款方案我們結合起來使用，即可搭建高可用網站方案。

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

1、Application Request Route方案，如下圖

缺點：

ARR可以檢測到你的iis應用是否可用，並對使用者的請求實施負載均衡方案，根據我們配置的負載均衡演算法，把使用者的請求分發到應用伺服器中。

但是，如果我們的ARR伺服器down掉之後，我們的整個應用程式就無法使用，達不到24*7用不宕機的高可用要求。

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

缺點：

NLB可以最多可以配置32臺伺服器，這32臺伺服器通過擁有自己的獨立ip之外，還共有一個虛擬IP，使用者訪問虛擬ip，nlb叢集根據配置的負載演算法來確定把使用者的請求分發給那臺應用伺服器，如果一臺NLB伺服器down掉，則不會影響訊息的分發可達到7*24小時不down機的高可用方案。

但是，NLB不能檢測應用你的iis網站是否down掉，只能檢測伺服器是否down掉，這樣一來，如果你的iis網站已經停止啦，nlb還給分發使用者請求，那樣麻煩可就來啦。

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

3、NLB+Application Request Route 方案

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

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

經過綜合分析後，我們最終採用了NLB+ARR的結合，形成如下設計圖

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

&n