将流量路由到源的方法

适用于： ✔️ Front Door 标准版 ✔️ Front Door 高级版 ✔️ Front Door 经典版

重要

Azure Front Door（经典版）将于 2027 年 3 月 31 日停用。 为了避免任何服务中断，请务必在 2027 年 3 月之前将 Azure Front Door(经典版)配置文件迁移到 Azure Front Door 标准层或高级层。 有关详细信息，请参阅 Azure Front Door（经典版）停用。

Azure Front Door 支持使用四种流量路由方法来管理 HTTP/HTTPS 流量在不同源之间的分布方式。 当用户请求抵达 Front Door 边缘位置时，配置的路由方法会确保将请求转发到最佳的后端资源。

注意

在本文中，源指的是后端，源组指的是 Azure Front Door（经典）配置中的后端池。

四种流量路由方法为：

• 延迟：将请求路由到可接受敏感度范围内延迟最低的源，确保将请求发送到网络延迟最近的源。

• 优先级：允许为源设置优先级，指定一个主源来处理所有流量，并指定一个辅助源作为主源不可用时的备份。

• 加权：为每个源分配权重，以平均分配流量或根据指定的权重系数分配流量。 如果源的延迟在可接受的敏感度范围内，则流量将根据权重值分配。

• 会话亲和性：通过为前端主机或域配置会话亲和性，确保来自同一最终用户的请求发送到同一源。

注意

在 Azure Front Door 标准层和高级层中，终结点名称 在 Azure Front Door（经典版）中称为 前端主机。

所有 Front Door 配置都包括后端运行状况监视，以及自动化全局故障转移。 有关详细信息，请参阅 Front Door 后端监控。 Azure Front Door 可以使用单一路由方法或组合多种方法来根据应用程序需求创建最佳路由拓扑。

注意

通过使用Front Door 规则引擎，你可以将规则配置为覆盖 Azure Front Door 标准和高级层中的路由配置，或在 Azure Front Door（经典版）中覆盖请求的后端池。 规则引擎设置的源组或后端池将替代本文中所述的路由过程。

总体决策流程

下图展示了总体决策流程：

决策步骤包括：

1. 可用源：选择所有启用且健康探测状态为良好（200 OK）的源。
   • 示例：如果有六个源 A、B、C、D、E 和 F，其中 C 运行状况不佳且 E 已禁用，则可用的源为 A、B、D 和 F。
2. 优先级：从可用源中选择优先级最高的源。
   • 示例：如果源 A、B 和 D 的优先级为 1，而源 F 的优先级为 2，则选定的源为 A、B 和 D。
3. 延迟信号（基于运行状况探测）：从请求到达的 Front Door 环境中，选择允许延迟范围内的源。 此范围基于源组的延迟敏感度设置和最接近的源的延迟。
   • 示例：如果到源 A 的延迟时间为 15 毫秒，到源 B 的延迟时间为 30 毫秒，到源 D 的延迟时间为 60 毫秒，且延迟敏感度设置为 30 毫秒，则选定的源为 A 和 B，因为 D 超出了 30 毫秒的范围。
4. 权重：根据指定的权重比率在最终选定的源之间分配流量。
   • 示例：如果源 A 的权重为 3，源 B 的权重为 7，则流量将按 3/10 的比率分配给 A，按 7/10 的比率分配给 B。

如果启用会话相关性，则会话中的第一个请求遵循前面介绍的流。 后续请求将转到第一个请求中选择的源。

基于最低延迟的流量路由

在多个全局位置部署源可以通过将流量路由到与最终用户“最接近”的源来增强应用程序的响应能力。 延迟路由方法是 Azure Front Door 配置的默认方法。 该方法将用户请求定向到网络延迟最低的源而不是最近的地理位置，以确保最佳性能。

Azure Front Door 的任意播架构与延迟路由方法相结合，可确保每个用户根据其位置体验最佳性能。 每个 Front Door 环境都会独立度量到源的延迟，这意味着不同位置的用户会被路由到为其特定环境提供最佳性能的源。

注意

默认情况下，延迟敏感度属性设置为 0 毫秒。 通过此设置，请求始终会被转发到最快的可用源。 仅当两个源具有相同的网络延迟时，源上的权重才会生效。

有关详细信息，请参阅 Azure Front Door 路由体系结构。

基于优先级的流量路由

若要确保高可用性，请部署备份服务以在主服务发生故障时接管。 此设置称为主动/待机或主动/被动部署。 Azure Front Door中的 Priority 流量路由方法可帮助你实现此故障转移模式。

默认情况下，Azure Front Door 将流量路由到具有最高优先级（最低优先级值）的源。 如果这些主要源变得不可用，它会将流量路由到次要源（下一个最低优先级值）。 如果主要源和次要源均不可用，则使用第三个源继续该过程。 运行状况探测器根据源的配置状态和运行状况监视源的可用性。

配置源的优先级

Azure Front Door源组中的每个源都有一个 Priority 属性，可以设置为介于 1 和 5 之间的值。 值越低，优先级越高。 多个源可以共享相同的优先级值。

加权流量路由方法

注意

对于每秒请求数非常低的客户，由于 AFD POP 节点和计算机的分布特性，Azure Front Door 无法保证所配置的权重能够严格遵循，负载均衡可能会不均匀。

加权流量路由方法根据预定义的权重分配流量。

在此方法中，可为 Azure Front Door 源组中的每个源分配一个权重。 权重是介于 1 和 1,000 之间的整数，默认值为 50。

如果源满足可接受的延迟敏感度，则流量通过使用基于指定权重比率的轮循机制在可用源之间分布。 如果将延迟敏感度设置为 0 毫秒，则仅当两个源具有相同的网络延迟时，权重才会生效。

加权方法支持多种方案：

• 逐步应用程序升级：将一定比例的流量路由到新的源，并随着时间的推移逐渐增加该比例。
• 将应用程序迁移到 Azure：创建包含 Azure 源和外部源的源组。 调整权重以优先选择新的源，逐渐增加其流量份额直到它们处理大部分流量，然后禁用并删除不太受欢迎的源。
• 通过云突发获取额外容量：通过添加或启用更多源并指定流量分配，将本地部署扩展到云中。

会话亲和性

默认情况下，Azure Front Door 将来自同一客户端的请求转发到不同的源。 但是，会话亲和性对于有状态应用程序或来自同一用户的后续请求需要由同一源处理的方案很有用。 此功能可确保同一源处理用户会话，这对于客户端身份验证等方案非常有用。

Azure Front Door 使用基于 Cookie 的会话亲和性，其中使用以原始 URL 的 SHA256 作为标识符的托管 Cookie。 此方法将来自用户会话的后续流量定向到同一源。

可以在Azure Front Door标准层和高级层的源组级别以及每个配置的域或子域Azure Front Door（经典）中的前端主机级别启用会话相关性。 启用此功能时，Azure Front Door将名为 ASLBSA 和 ASLBSACORS 的 cookie 添加到用户的会话中。 这些 Cookie 有助于识别不同的用户，即使他们共享相同的 IP 地址，这允许在源之间更均匀地分布流量。

该 Cookie 的生存期与用户的会话相匹配，因为 Front Door 目前仅支持会话 Cookie。

注意

浏览器会话 Cookie 在域级别维护会话相关性。 只要用户浏览器对同一源资源发送请求，同一通配符域下的子域就可以共享会话亲和性。

公共代理可能会干扰会话相关性，因为建立会话需要 Front Door 向响应添加会话相关性 Cookie。 如果响应可缓存，则无法执行此操作，因为它会中断请求相同资源的其他客户端的 Cookie。 为防止此问题，如果源发送可缓存响应，就不会建立会话相关性。 如果已建立会话，则响应的可缓存性并不重要。

在以下非标准不可缓存情况下，建立会话粘性：

• 响应包含Cache-Control标头，并附有no-store。
• 响应包含有效的 Authorization 标头。
• 响应是一个 HTTP 302 状态代码。

后续步骤

• 了解如何创建 Azure Front Door。
• 了解 Azure Front Door 的工作原理。