CSF 中的应用程序请求路由

CSF 中的应用程序请求路由

编辑人员注释： 本文章由 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 或其他一些预构建服务能够满足您的需求当然很好；如果不能，请不要忽视这个强大且灵活的选项。

本文翻译自：

https://blogs.msdn.com/b/windowsazure/archive/2013/10/31/application-request-routing-in-csf.aspx