将流量路由到源的方法

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

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

四种流量路由方法为：

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

• 优先级： 允许为源设置优先级，指定主源以处理所有流量和辅助源作为备份（如果主节点不可用）。

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

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

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

总体决策流程

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

决策步骤包括：

1. 可用源： 根据健康探测选择已启用且健康状态正常（200 正常）的所有源。
   • 示例：如果有六个源 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 环境都会独立度量到源的延迟，这意味着不同位置的用户会被路由到为其特定环境提供最佳性能的源。

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

基于优先级的流量路由

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

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

配置源的优先级

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

加权流量路由方法

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

在此方法中，可为 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将名为 ASLBSA 和 ASLBSACORS 的 cookie 添加到用户的会话中。 这些 Cookie 有助于识别不同的用户，即使他们共享相同的 IP 地址，这允许在源之间更均匀地分布流量。

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

后续步骤

• 了解 Azure Front Door 的工作原理。