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