Windows平台分布式架构实践

概述

　　我们在上一篇Windows平台分布式架构实践 - 负载均衡中讨论了Windows平台下通过NLB（Network Load Balancer) 来实现网站的负载均衡，并且通过压力测试演示了它的效果，可以说还是非常的理想的。同时我们也收集到了不少的问题，比如说如何在这种分布式的架构下使用Session，NLB中有一台服务器挂掉了会导致对外暴露的地址无法访问，如果实现服务器之间的同步，如果更好的进行热修复等等，还有我们在上一篇中也提到了NLB所提供的功能是非常简单的，为了回答我们前面提到的问题，也为了提供一个比较全面完整的负载均衡方案，我们来看看Windows平台下负载均衡的另一种实现APR (Application Request Router + Web Farm + Url Rewriter)，希望可以为大家解决一些实现的问题。

安装配置负载均衡

安装相关组件

　　话不多说，为了实现一个比较完整的负载均衡，我们要引入以下5个组件。

• Web Deploy V3.0
• Web Platform installer V5.0
• Web Fram 2 for IIS7
• Applicaiton Request Router 3 for IIS
• Url Rewriter 2 for IIS7 

　 安装Web Fram 必须要先安装Web Deploy 和Web Platform，所以我把它们俩放在最前面，你也可以参考上面的顺序来安装，当然你首先得自己把IIS和ASP.NET 模块给装上。我们这次不会对这5个组件的原理做详细的介绍，大家知道怎么操作就可以了，如果有兴趣的同学可以继续深入。安装过程非常的简单，基本上每一个组件只需要点一下按钮就可以了，全部安装完之后，你就会在当前那台机器上的IIS下看到一个Server Farms的结点。

配置负载均衡

　　如果大家还有印象，在使用NLB配置负载均衡的时候，我们是不需要一台单独的机器来作为主入口的。 我们给所有的WEB服务器都安装上NLB，然后选择任意一台将其它的WEB服务器加进入同时设置一个单独的IP作为入口地址即可。 但是换成APR，情况就有点不一样了。我们需要一台单独的入口服务器来接收所有的请求，由它再把所有的请求根据配置的规则转发给其它真实的WEB服务器。

　3 台Web 服务器我们还是用我们上次做过实验的那三台，我们再添加一台配置一样的虚拟机，然后给这4台服务器全部安装上APR(包括我们上面列出的5个组件）之后，我们就可以开始配置了。我们首先在我们的入口服务器上创建一个Web Farm。在IIS中右击Server Farms -> Create Server Farm，

　　我们勾上“Server farm is available for load balancing(在Web Fram中使用负载均衡)” ，下面的“Provision server farm”，我们也勾上，并为它输入一个账户，这个账户要求有权限可以访问这个Web Farm里面的所有服务器。Provision 主要是用来实现主-从服务器同步的，我们暂时先忽略它，后面再具体讲。

　　我们将192.168.1.130设置我们的主Web 服务器，一会我们结合Provision(俺不知道这个翻成中文该叫什么，直译“提供”好像很别扭) 功能就可以实现在主服务器上部署和更改配置就会被自动同步到其它的服务器上。完成创建Web Farm之后，我们就可以在IIS中进行后面的配置了。我们通过点击每一个Web Farm下的Servers来查看每一个Web服务器的状态，是不是连接正常等等 。

　　同时我们还可以点击每一个Web farm来进行以下功能的管理，这里我们就点击Mono。

配置Load Balance 算法

　　我们首先要做的就是进入 “Load Balance”，在这里你可以选择负载均衡的算法 ：轮转调度，随机分配，URL参数，请求头等。如果不了解这些算法干什么 的，那就去复习上一篇吧。APR为我们提供了以下7种算法：

1. Weighted round robin 根据权重按照请求数据进行分配
2. Weighted total traffic  根据权重按照请求和响应字节大小进行分配
3. Least current request 优先转发给那个当前处理最少请求的服务器
4. Least response time   优先转发给那个当前响应最快的服务器
5. Server variable hash   根据服务器变量的hash来分配请求，这里面的服务器变量包括Cookie, URL,头信息等 ，详情点这里。
6. Query string hash      根据URL查询字符串的hash来分配请求，如果查询字符串包含多个参数（?name=jesse&location=sh），则是用整个查询字符串的hash来作判断。
7. Request hash            根据服务器变量或者是URL的hash来分配请求，比如说服务器变量是QUERY_STRING，那么hash的值就是query string中对应的那个值。

　　大家可以已经猜到，后面3种算法是可以利用来实现这种分布式环境下session的访问的，但是由于要涉及到其它的配置，所以我们后面再讲，让我们先专注于把这个负载均衡配置完，所以我们就里就先选择比较简单的Least response time，谁当前返回响应最快我们就把请求给它，验证了那句话，“能者多劳啊”。

配置转发规则

　　APR的机制是做为一个代理服务器，它负责接收请求，但是不做任何处理，而是直接将请求分发给具体的WEB服务器。同时我们还可以配置一些规则，有一些请求转发，有一些请求不转发，这就要感谢我们的url rewrite组件了。我们可以进入“Routing Rules”来进行相关的配置。

网站部署与同步

安装程序和运行环境同步

　　在实际的环境中，如果我们使用NLB在第一次部署的时候，就需要一个服务器一个服务器的部署，而且如果要对IIS进行其它的一些配置就会显得很烦琐。在APR中给我们提供的Provision功能，就可以帮助实现这样的同步功能。

　　在Server Farm的功能视图中，我们可以找到以下两种类型的Provision:

• Application Provisioning: 主要是用来同步网站相关包括内容，配置等等，Web Deploy就是用在这里了。
• Platform Provisioning：主要是用来同步安装程序的，其实这里面的Platform是指我们上面安装的 Web Platform Installer，也就是说我们在主服务器上通过Web Platform安装的程序或者组件，如果启用了Platform Provisioning的话，其它所有的服务器也会自动安装上。

　　我们可以来做一个Platform Provisioning的例子，点击我们的Server Farm -> 在右边的功能视图中双击Platform Provisioning -> 勾选下面两个选项。

 

　　然后我们点击左右的Servers，选中我们的主服务器（Primary)，在右边的操作列表中选择 “Install Product”，在弹出的窗体中安装的程序就会被自动安装到当前Server Farm中的所有其它服务器中。

 

网站内容同步

　　和上面的思路一样，我们不需要每一个程序都部署一遍，我们只需要在主服务器上部署一遍就可以了，所有的内容以及IIS的设置都会被自动同步到其它服务器上，这就是Application Provisioning来帮我们实现的。我们可以通过点击我们的Server Farm ->在右边的功能视图中双击 “Applicaiton Provisioning” 然后勾选下面的两项即可。

　　接下来，我们只需要在我们的主服务器上建立我们的站点然后部署我们的网站即可，包括对网站进行一些应用程序池的配置也是只需要在主服务器上完成的，我们就不需要到每一台服务器上都去布置一遍了。 

配置入口服务器

　　既然入口服务器不做任何处理只是转发请求的话，那我们还需要把我们的网站的内容放在入口服务器的IIS下么？这个就取决于不同的场景了，你可以建一个空的站点什么也没有，你也可以用它来做一个简单的文件服务器，在上一步中将静态文件不转发即可，让我们Web Farm中的服务器只处理动态的请求，也可以减轻他们的压力。当然如果你有单独的文件服务器那就更好了。作为测试用途我们在入口服务器上就不建任何网站了，直接使用安装IIS自带的那个默认网站即可。

　　有人可能会有疑问，因为我在配置Server Farm的时候同样也有这样的一个疑问。“所有的请求都是由入口服务器接收，然后再分发给Farm中具体的服务器的，那入口服务器的那个网站该如何配置呢？ 是用80还是8080端口，如果我建了好几个网站，那到底哪一个网站的请求会被Farm拿到再进行转发呢？”

　　我在入口服务器中没有做任何网站的配置，也就是说本地有一个http://localhost的网站是可以访问的，对于外部来说它的地址就是 http://192.168.1.129/，那么为什么当外部访问 192.168.1.129的时候，它就会被Farm 中的服务器处理呢？ 这就要多亏我们的Url Rewrite模块了，我们可以点击我们的Farm Mono，进入到功能视图->然后点击 Routing Rules -> 在Routing Rules 右侧的操作列表中点击 URL Rewrite... 对Routing Rules进行更详细的管理。 

　　在我们的URL Rewrite窗口，我们就会看到已经为我们默认创建了一条入站的规则。

   

　　我们可以双击那条规则查看详细，或者进行编辑，我们可以看到这条规则实际上是用通配符匹配了所有的入站请求，然后转发给我们的Server Farm: Mono。原来是URL Rewrite在这里起了作用，当然我们也可能把 *改成 其它的通配符，以及使用正则表达式来匹配都是可以的，这些都是URL Rewite里面的功能，是可以直接搬过来用的。 

　　URL Rewrite帮助我们匹配入站请求，然后转发给Farm，在Farm层面 APR根据 我们配置的负载均衡算法将请求转发给具体的服务器去处理请求。现在我们再回过头来看看我们最开始安装的5个组件都分别起到了什么作用。

• Web Deploy : 参与Application Provisioning（网站内容及配置同步）
• Web Platform Installer: 参与Platform Provisioning( 应用环境同步）
• Web Farm： 主要组织者及容器
• Application Request Router: 负载均衡处理
• URL Rewrite: 入站请求匹配等 

验证负载均衡

　　到这里为止，我们用 APR + Web Farm搭建的负载均衡就完成了，最终结果是我们在外面访问 http://192.168.1.129的时候，实际上是由我们Farm中的3台Web 服务器处理的，口说无凭，我们来验证一下。验证的方法很简单，我们在每个服务器下放不同的文件用来标识当前是哪个服务器在处理响应（记得在部署文件的时候要先把Application provisioning关闭掉，不然主服务器上的文件会被同步到其它的服务器上去的）。

　　在web-02和 web-03上，分别返回不前的服务器的名字就可以了。但是在测试上可能会遇到一点小问题，那就是当我们访问http://192.168.1.129的时候，总是由web-01处理的，因为我们的页面帮简单，又只有一个用户在访问，所有后面两台服务器压根没有发挥作用。这时候我们就可以把web-01和 web-02从 Farm中移除掉，那么所有的请求就会被web-01来处理了。

　　就是这么简单，Web Farm给我们提供的这个功能非常的实用，我们可以在运行时随时动态的添加或移除服务器。还记得以前我们只有一台服务器的时候，为了尽可能的不影响用户，发布都选择在晚上的10点以后，所以经常是一发布就通宵。想想如果有这个功能，白天也可以发布了，只要先把一些机器从Web Farm中拿下来，发布好测试通过之后再放上去并且把别外那一些也拿下来发布就好了。当然这种场景只适合一些中小型的网站，一旦网站大了，那发布将会是一个非常严格的流程，而且一般会有专门的发布人员或者工具。

 Session在APR 分布式环境下的应用

 　　关于Session在分布式环境下的使用其实是有争议的，有人说老师都不让用Session了，但是有人又想方设法的想要使用它。我们暂且不讨论它的正确与否，因为没有最好的架构，只有最合适的架构，正所谓存在即合理。我们都不得不承认Session在很多管理系统，以及一些小型的网站的开发上带来了很大的便利性，开发快速同时又可以带来看得见的性能提升。所有个人认为，用还是不用那就看场景吧。但是我们从学习的角度出发，还是应该考虑到各种可行性，以及他们之间的利与弊，这样才能帮助我们在真实情况下做出最合适的决策。

Server Affinity（服务器关联性）

　　在Farm的功能视图中，有一个Server Affinity的功能可以用来跟踪请求或者说提供一种服务器和客户端之间的粘性，当第一个请求被处理之后，这个请求所在客户端后面发起的所有请求都会交给同样的服务器来处理，这就是Server Affinity。APR为我们提供了两种选项：

• Client Affinity:　会给来自不同客户端的请求分配一个cookie，然后根据这个cookie来识别请求应该由哪个服务器来处理。
• Host Name Affinity：根据Host name来作粘性处理，它还有两种provider可以采用：
  • Microsoft.Web.Arr.HostNameRoundRobin: 保证尽量平均分配到服务器
  • Microsoft.Web.Arr.HostNameMemory: 根据内存使用情况来分配，保证各个服务器的内存使用情况达到均衡。

　　原来在APR这种分布式架构下使用Session是这么的简单，而且我们可以根据实际情况，Client Affinitt 和 Host Name Affinity一起使用。

搭建多台APR服务器来提升可靠性

　　还记得我们在上一篇中提到的，引入负载均衡帮提高了两点：可靠性和可扩展性。多台服务器共同处理的情况下，哪怕其中部分出了问题也不会导致整个网站无法访问，提高了我们的可靠性。随时动态的添加和移除服务器而不影响网站的访问，提供了我们的可扩展性。但是这里还有一个问题，但是如果APR所在的那个服务器出了问题怎么办？虽然这种可能性比较低，因为我们的APR服务器只是做了很简单的转发请求的功能，并没有运行真实的网站，但仍然不排队会有其它的异常导致IIS或者Web Farm停止运行，对于像这样的问题，我们就可以通过部署多台APR服务器来再一次提升我们网站的可靠性。

　　一台APR服务器可以将请求分发给具体的服务器，如果是多台APR服务器，那谁来决定请求是由哪台APR服务器处理呢？

　　还记得我们上篇讲的NLB么？它不需要一台单独的服务器配置，只需要给目标机器都装上NLB，然后配置一个暴露给外部的地址就可以了。所以这次当我们访问外部地址的时候会有接下来的几步动作：

1. NLB最先拿到请求信息，然后具体的APR服务器再去响应请求
2. 当某台APR响应请求的时候会根据配置好的负载均衡算法交给后面具体的Web服务器去处理
3. Web服务器请求完之后，再把响应信息返回给客户端

小结

 　　第二篇稍微来的晚了一点，对一直关注的朋友说声抱歉，最近个人的事情有点多，也是想把APR尽量呈现的全面一点:)。使用APR相对于NLB来说给我们提供了更全面的负载均衡功能，结合APR和NLB一起使用带来更高的可用性，但是由于APR采用的是代理的方式，所以性能会比NLB低一些，但是有时候稳定更重要，不是么？当然还有很多其它的方案我们都是可以去尝试的，比如说Ngnix很久以前就已经在开源社区获得了很好的声誉。我们这两篇算是让大家对负载均衡有一个比较感性的认识，真实的项目过程中还要考虑我们代码的架构，如何保证我们的系统能够在分布式环境下完美运行，并真正发挥分布式的力量，我们还有很长的一段路要走，用分布式缓存替代Session方案，数据库群集，服务群集和队列等，我们一个一个的攻破，欢迎大家持续关注！最后祝大家上班编码快乐 :)