Application Request Route(文中简称为ARR)是一个寄宿于 IIS7(及以后的IIS 版本)的一个基于代理的模块,它可以通过判断 Http Headers,Server Variables 以及负载均衡算法将 HTTP 的请求转发到不同的处理服务器之上。

用处
1. 增强应用的可用性与扩展性
2. 更好的利用服务器资源
3. 使得应用程序的部署更加方便,并且支持卫星部署管理与热替换
4. 更低的管理成本,使得共享宿主的部署成为可能
ARR 是基于URL Rewrite Module 的,它通过检测客户端发来的 HTTP 请求来做出请求路由的决定。

特征
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 来实现的。至于如何实现的,其实也很简单,这里暂且不说。
5. 宿主名亲缘性
理解了上面的“客户端亲缘性”,这里就更加容易理解了。“ 宿主名亲缘性”主要使用在共享服务器中的(很多人使用一台服务器,就是站点部署的时候,购买的是“虚拟地址空间”)。
6. 服务器分组
ARR 可以管理很多的服务器组,其中每一组又包含多台服务器服。
7. 基于图形化界面的管理与健康
ARR 与 IIS 集成,并且,通过了可视化的,便于操作的可视化操作界面。
8. 制定请求失败的跟踪规则
在 ARR 中,可以定义特定的跟踪规则,当请求处理失败之后查看跟踪信息,便于诊断。

总结而言,arr主要是用于伏在均衡、服务器管理的,如果做服务器安全防护,需要用其它的软件,如ShareWAF(http://www.sharewaf.com