编辑人员注释：本文章由 AzureCAT 团队的
Christain Maritnez 撰写。
应用程序请求路由（简称为 ARR）可能是 Microsoft 使用的技术中讨论得最少但极为重要的技术之一，它能够支持
Windows Azure 网站、Outlook.com 和许多其他关键的高容量应用程序。那么按理说，直接在 Windows Azure 应用程序中使用该技术就更少被谈及了。我们将该技术用于云服务基础，是因为
CSF 显示的一个模式是在多个云服务中拆分工作，并根据用户以透明方式创建与云服务的关联。这种方法以过往的大客户经验为依据，将云服务用作规模单元，而具有较高的本地性（数据接近使用它的代码）, 可以提供性能优势。ARR 非常适合帮助我们达到要求。
起初，您听到多个云服务时可能会说：“稍等一下……就是说，你们有多个云服务了。那就用
Windows Azure Traffic Manager (WATM) 好了！”事实上，对于大多数路由需求，当您出于性能或业务连续性的原因在多个云服务中拆分工作时，WATM
可能是正确的选择。但在这种情况下，它不符合要求。WATM 提供了三种负载平衡方法：
· 性能
· 故障转移
· 轮循机制
这些方法都很好，但不符合根据用户身份（由 Cookie 决定）向云服务发送用户请求的要求。
要使用 ARR，需要满足以下 4 个条件：
1. 用于托管 ARR 的、由 Web Role 组成的 Windows Azure 云服务
2. 用于安装和配置 ARR 的脚本
3. 配置 ARR 规则
4. 如果用户没有之前访问留下的 Cookie, 决定要执行的操作
可以在此处找到上述条件的详细信息和代码。这些步骤对于在
Azure 上利用 ARR 的任何解决方案大多通用，因此本文中我将只讨论特定于 CSF 的两个部分：
· 按 Cookie 路由规则 – CSF 的 ARR 路由规则是怎样的？
· 不存在 Cookie – 没有 Cookie 时应该做什么，怎么做。
按 Cookie 路由规则
按用户 Cookie 路由用户的逻辑如下所示：
规则配置可能是一个比较复杂的主题，但以上逻辑的基本意思如下：
如果通过 SSL 发送请求且该请求是相对路径，并包含 userpod=(某个数字) 形式的用户 Cookie，则捕获等号后的部分 Cookie，并通过插入捕获的值重写目标 URL。
当然，这看起来有点奇怪，但过段时间就会习惯了。
不存在 Cookie
但如果未检测到 Cookie 怎么办？可能有多种解决方法，但我们决定创建一个实现两个接口（IRewriteProvider
和 IProviderDescriptor）的类。第一个接口允许您根据请求输入使用代码来返回自定义 URL，第二个接口允许您提供自定义输入的简单配置。给提供程序的代码仅获取已配置的 pod，并在没有 Cookie 的请求到达时，以循环方式在其中进行选择。这并不是一个令人振奋的代码，因为它相当于递增一个整数，然后在到达最后一个点时循环。
配置代码更为有趣一些，但相差不大：
这就形成了一个网格，在其中可以对给定 pod 输入一个 URL。因此，这一切的实际效果是，我们的代码可使用一组地址进行配置，以选择是否存在 Cookie！
最后的思考
ARR 是一款强大的工具，在 Microsoft 内应用广泛。本博客向您阐明了我们对 CSF 方案使用该技术的原因，但此方案仅触及了 ARR 用途的皮毛。例如，我们所见到的常见用法之一是在云服务内使用，以便路由和负载平衡在任何所需模式中都可用。如果 WATM 或其他一些预构建服务能够满足您的需求当然很好；如果不能，请不要忽视这个强大且灵活的选项。
本文翻译自：
http://blogs.msdn.com/b/windowsazure/archive/2013/10/31/application-request-routing-in-csf.aspx