我们对框架功能作了简述，演示视频请点击这里查看，
本章节，我们专门讲解一下，如何在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检测可用的网站把用户请求给分派处理，形成高可用方案。
框架设计预研中，灵感来源参考文献：/knowledgesea/p/5157565.html
经过综合分析后，我们最终采用了NLB+ARR的结合，形成如下设计图
对于此框架的设计(优点与缺点)，元芳，您怎么看？欢迎留言吐槽。
