IIS负载均衡之介绍篇：Application Request Route详解
说到负载均衡，相信大家已经不再陌生了，本系列主要介绍在IIS中可以采用的负载均衡的软件：微软的Application Request Route模块。
其实Application Request Route已经有很多文章介绍过了，但是有很多的文档都是英文的，笔者在项目中，曾经为了使用和测试Application Request Route，将有关的文档已经转为中文，在组员之间传阅，本系列在这些文档的中，再加入一些使用的心得。
本篇议题如下：
Application Request Route介绍
Application Request Route安装
系列文章链接：
IIS负载均衡-Application Request Route详解第一篇： ARR介绍
IIS负载均衡-Application Request Route详解第二篇：创建与配置Server Farm
Application Request Route介绍
Application Request Route（后面简称为ARR）是一个寄宿于IIS7（及以后的IIS版本）的一个基于代理的模块，它可以通过判断Http Headers，Server Variables以及负载均衡算法将HTTP的请求转发到不同的处理服务器之上。ARR的用处如下：
- 增强应用的可用性与扩展性
- 更好的利用服务器资源
- 使得应用程序的部署更加方便，并且支持卫星部署管理与热替换
- 更低的管理成本，使得共享宿主的部署成为可能
ARR是基于URL Rewrite Module的，它通过检测客户端发来的HTTP请求来做出请求路由的决定。
下面，我们就进一步的看看ARR的一些特征：
1.基于HTTP请求，做出的请求路由的决定
与硬件的负载均衡不同（在OSI模型的IP层来决定请求的路由方式），ARR是基于应用层来进行负载均衡的，因为在应用层可用的信息更多（其实谈到这里，是很有必要把负载均衡的原理讲清楚的，但是，因为本系列主要是讲述ARR，所以，对已一些底层原理性的概念，不会做过多的涉及，以后计划为朋友们系统的讲述负载均衡的原理及其实现,可以参看：负载均衡第一篇-介绍篇）。通过在ARR中使用URL Rewrite Module，我们就可以实基于Http Headers与Server Variables来实现个更强大的路由规则。
2.提供多种负载均衡算法
我们可以自己决定使用哪一种负载均衡算法来进行请求的路由，ARR提供了以下6种算法。
3.健康检查
我们可以使用"实时通信"和"特定Url测试"来检查服务器的健康状况。并且，我们还可以通过使用很多的参数来决定到底什么样的状况才是健康的正常的服务器，例如，有人认为只要服务器是开启的，就是健康的；也有人认为，服务器开启，并且处理的请求没有超载是健康的，等等。另外，我们还可以通过使用自己的提供Health Monitoring Provider来实现自己的健康检查可能。
4.客户端亲缘性
关于亲缘性，相信大家不再陌生，我这里稍微的提一下：就是更加倾向于，或者喜欢那个。例如，在SQL Server中可以设置CPU的亲缘性，，假设现在有四个CPU，编号分别是A,B,C,D,现在我们SQL Server的CPU亲缘性设置到A上，就是说: SQL Server在处理请求的时候，更加喜欢把请求发送给编号为A的CPU来处理，当然也会将请求发送给其他的CPU，但是A的CPU处理请求的机会更多。
同理，在ARR中，可以通过设置客户端的亲缘性，ARR主要是通过使用Cookie来实现的。至于如何实现的，其实也很简单，这里暂且不说。
这里就来说说客户亲缘性的一些需要考虑的点：
- 如果使用了客户端亲缘性，就可以在应用中使用传统的Session和Cache，而没有必要使用分布式的Session和Cache。这里，以Session为例子，因为很多的时候，我们都需要将一个站点应用部署到多个服务器上，如果在某些地方使用了Session，特别保存用户的一些数据的时候，就需要使用分布式的Session，用户登录就是一个最明显的例子（避免用户从服务器A上登录，当下一次请求在B服务器处理的时候，还需要再次登录）。使用客户端亲缘性，ARR就可以将同一个用户的请求再次转发到用户第一次请求的服务器上。
- 使用客户端亲缘性，就在一定程度上面失去了负载均衡的意义。因为设置了客户端亲缘性，即使用户初次请求的服务器现在压力很大，那么ARR还是会将用户的请求转发过去。
- 客户端亲缘性，失去了高可用性。因为很有可能现在处理用户请求的服务器已经宕机了，虽然ARR有健康检查机制，但是ARR还是可以将请求发给宕机的服务器，导致请求无法处理。
5.宿主名亲缘性
理解了上面的"客户端亲缘性"，这里就更加容易理解了。" 宿主名亲缘性"主要使用在共享服务器中的（很多人使用一台服务器，就是站点部署的时候，购买的是"虚拟地址空间"）。我们后面在提到的时候，会详细讲解。
6.服务器分组
ARR可以管理很多的服务器组，其中每一组又包含多台服务器服。
7.基于图形化界面的管理与健康
ARR与IIS集成，并且，通过了可视化的，便于操作的可视化操作界面。
8.制定请求失败的跟踪规则
在ARR中，可以定义特定的跟踪规则，当请求处理失败之后查看跟踪信息，便于诊断。
Application Request Route安装
下面，我们就介绍ARR的安装，便于大家快速上手与学习：
ARR依赖于以下组件：
- Microsoft URL Rewrite Module for IIS 7.0.
- Microsoft Web Farm Management Version 1 for IIS 7.0.
- Microsoft Application Request Routing Version 1 for IIS 7.0.
- Microsoft External Cache Version 1 for IIS 7.0.
ARR的安装，需要相关的环境，如下：
- IIS 7.0 以及以后的版本（笔者在Win 7和Server2008中都安装过，是可以的）
下面开始进入安装：
1. 下载ARR：
现在ARR已经发展了2.5的版本，可以说已经很稳定了，笔者也在一些大型项目中已经采用，效果还不错。
现在地址：http://www.iis.net/download/ApplicationRequestRouting
2. 现在ARR集成在Web 安装平台中，如下：
3.点击"Install"，开始安装
4.安装之后，打开IIS的控制窗口，如下（Win7系统的界面）：
如果看到有"Server Farms"，就说明安装OK了。
5.配置应用程序池
所有的HTTP请求都需要经过ARR。所以，我们希望在安装了ARR的服务器上的IIS要必须不停的运行，不停把请求转发到其他的服务器上面，也就是说：这台安装了ARR的服务器基本的功能就是请求转发。
假设现在我们手里有3台服务器（编号分别为A,B,C）来部署agilesharp的站点，安排如下：
现在服务器A向外面暴露的地址假设为:159.12.2.15，那么我们在A服务器上建立一个agilesharp的站点，如下：
并且，我们设置agilesharp站点的应用程序池为IIS的集成模式。这个时候，因为这个站点其实只是暴露给外面，真正的请求处理在B和C服务器。所以，我们要设置这个agilesharp的站点的应用程序池，从而它源源不断的接受HTTP请求（应用程序池默认是不会不断的介绍请求的，它有一个时间的延时，这个延时的时间往往就是默认的请求处理时间），然后由ARR转发。
设置如下：
将Idle Time-out (minutes)设置为0,然后保存就OK了。
OK，介绍就到这里，下一篇，我们就来看看一些具体的应用！
本文出自 "燕洋天" 博客，请务必保留此出处http://yanyangtian.blog.51cto.com/2310974/817136
