【转载】Windows平台下利用APM来作负载均衡方案 - 负载均衡（下）

时间 2019-11-19

标签转载 windows 平台利用 apm 来作负载均衡方案栏目 Windows 繁體版

原文原文链接

概述

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

安装配置负载均衡

安装相关组件

　　话很少说，为了实现一个比较完整的负载均衡，咱们要引入如下5个组件。web

　安装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 主要是用来实现主-从服务器同步的，咱们暂时先忽略它，后面再具体讲。swift

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

　　同时咱们还能够点击每个Web farm来进行如下功能的管理，这里咱们就点击Mono。缓存

配置Load Balance 算法服务器

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

Weighted round robin 根据权重按照请求数据进行分配
Weighted total traffic 根据权重按照请求和响应字节大小进行分配
Least current request 优先转发给那个当前处理最少请求的服务器
Least response time 优先转发给那个当前响应最快的服务器
Server variable hash 根据服务器变量的hash来分配请求，这里面的服务器变量包括Cookie, URL,头信息等，详情点这里。
Query string hash 根据URL查询字符串的hash来分配请求，若是查询字符串包含多个参数（?name=jesse&location=sh），则是用整个查询字符串的hash来做判断。
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，而后配置一个暴露给外部的地址就能够了。因此此次当咱们访问外部地址的时候会有接下来的几步动做：

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

小结

　　使用APR相对于NLB来讲给咱们提供了更全面的负载均衡功能，结合APR和NLB一块儿使用带来更高的可用性，可是因为APR采用的是代理的方式，因此性能会比NLB低一些，可是有时候稳定更重要，不是么？固然还有不少其它的方案咱们都是能够去尝试的，好比说Ngnix好久之前就已经在开源社区得到了很好的声誉。咱们这两篇算是让你们对负载均衡有一个比较感性的认识，真实的项目过程当中还要考虑咱们代码的架构，如何保证咱们的系统可以在分布式环境下完美运行，并真正发挥分布式的力量，咱们还有很长的一段路要走，用分布式缓存替代Session方案，数据库群集，服务群集和队列等，咱们一个一个的攻破，欢迎你们持续关注！最后祝你们上班编码快乐 :)

做者：Jesse 原文地址：http://www.cnblogs.com/jesse2013/p/dlws-loadbalancer2.html

《一棵树-博客园》收集整理，转载请注明出处！