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 或其他一些预构建服务能够满足您的需求当然很好;如果不能,请不要忽视这个强大且灵活的选项。

本文翻译自:

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

 

Comments (0)

Skip to main content