适用于： ✔️ Front Door 标准 ✔️ Front Door Premium
Azure Front Door 支持使用四种流量路由方法来管理 HTTP/HTTPS 流量在不同源之间的分布方式。 当用户请求抵达 Front Door 边缘位置时，配置的路由方法会确保将请求转发到最佳的后端资源。
Note
在本文中， 源 是指后端， 源组 引用 Azure Front Door 配置中的后端池。
四种流量路由方法为：
延迟： 将请求路由到在可接受的敏感度范围内延迟最低的源，确保在网络延迟方面将请求发送到最近的源。
优先级： 允许为源设置优先级，指定主源以处理所有流量和辅助源作为备份（如果主节点不可用）。
加权： 为每个源分配权重以均匀分配流量，或根据指定的权重系数分配流量。 如果源的延迟在可接受的敏感度范围内，则流量将根据权重值分配。
会话相关性： 通过为前端主机或域配置会话相关性，确保来自同一最终用户的请求发送到同一源。
所有 Front Door 配置都包括后端运行状况监视，以及自动化全局故障转移。 有关详细信息，请参阅 Front Door 后端监视。 Azure Front Door 可以使用单一路由方法或组合多种方法来根据应用程序需求创建最佳路由拓扑。
Note
使用 Front Door 规则引擎，可以配置规则来替代请求的 Azure Front Door 标准和高级层中的 路由配置 。 规则引擎设置的源组或后端池将替代本文所述的路由过程。
总体决策流程
下图展示了总体决策流程：
决策步骤包括：
-
可用源： 根据健康探测选择已启用且健康状态正常（200 正常）的所有源。
- 示例：如果有六个源 A、B、C、D、E 和 F，其中 C 运行状况不佳且 E 已禁用，则可用的源为 A、B、D 和 F。
-
优先权： 从可用源中选择优先级最高的源。
- 示例：如果源 A、B 和 D 的优先级为 1，而源 F 的优先级为 2，则选定的源为 A、B 和 D。
- 延迟信号（基于运行状况探测）：从请求到达的 Front Door 环境中，选择允许延迟范围内的源。 此信号基于源组的延迟敏感度设置，以及更近的源的延迟。
- 示例：如果到源 A 的延迟时间为 15 毫秒，到源 B 的延迟时间为 30 毫秒，到源 D 的延迟时间为 60 毫秒，且延迟敏感度设置为 30 毫秒，则选定的源为 A 和 B，因为 D 超出了 30 毫秒的范围。
-
权重： 根据指定的权重比率在最终选定的源之间分配流量。
- 示例：如果源 A 的权重为 3，源 B 的权重为 7，则流量将按 3/10 的比率分配给 A，按 7/10 的比率分配给 B。
如果启用了会话亲和性，则会话中的第一个请求将遵循前面解释的流程。 后续请求将发送到第一个请求中选择的源。
基于最低延迟的流量路由
通过将流量路由到距离最终用户“最近”的源，在多个全局位置部署源可以增强应用程序的响应能力。 延迟路由方法是 Azure Front Door 配置的默认方法。 该方法将用户请求定向到网络延迟最低的源而不是最近的地理位置，以确保最佳性能。
Azure Front Door 的任意播架构与延迟路由方法相结合，可确保每个用户根据其位置体验最佳性能。 每个 Front Door 环境都会独立度量到源的延迟，这意味着不同位置的用户会被路由到为其特定环境提供最佳性能的源。
Note
默认情况下，延迟敏感度属性设置为 0 毫秒。 通过此设置，请求始终会被转发到最快的可用源。 仅当两个源具有相同的网络延迟时，源上的权重才会生效。
有关详细信息，请参阅 Azure Front Door 路由体系结构。
基于优先级的流量路由
为了确保高可用性，组织通常会部署备份服务，以便在主服务出现故障时接管操作。 此设置称为主动/待机或主动/被动部署。 使用 Azure Front Door 中的 优先级 流量路由方法可以有效地实现此故障转移模式。
默认情况下，Azure Front Door 将流量路由到具有最高优先级（最低优先级值）的源。 如果这些主要源变得不可用，它会将流量路由到次要源（下一个最低优先级值）。 如果主要源和次要源均不可用，则使用第三个源继续该过程。 运行状况探测器根据源的配置状态和运行状况监视源的可用性。
配置源的优先级
Azure Front Door 源组中的每个源都有一个 Priority 属性，该属性可以设置为介于 1 和 5 之间的值。 越小的值表示优先级越高。 多个源可以共享相同的优先级值。
加权流量路由方法
Note
对于低 RPS（每秒请求数）的客户，由于分布式 AFD POP 和计算机的性质，我们无法保证客户配置的权重将严格遵循，负载均衡可能显得偏斜。
使用 加权 流量路由方法，可以根据预定义的权重分配流量。
在此方法中，可为 Azure Front Door 源组中的每个源分配一个权重。 权重是介于 1 和 1000 之间的整数，默认值为 50。
只要源满足可接受的延迟敏感度，流量就会根据指定的权重比使用循环机制在可用源之间分配。 如果延迟敏感度设置为 0 毫秒，则仅当两个源具有相同的网络延迟时，权重才会生效。
加权方法支持多种方案：
- 逐步应用程序升级：将一定比例的流量路由到新的源，并随着时间的推移逐渐增加该比例。
- 将应用程序迁移到 Azure：创建包含 Azure 源和外部源的源组。 调整权重以优先选择新的源，逐渐增加其流量份额直到它们处理大部分流量，然后禁用并删除不太受欢迎的源。
- 通过云突发获取额外容量：通过添加或启用更多源并指定流量分配，将本地部署扩展到云中。
会话相关性
默认情况下，Azure Front Door 将来自同一客户端的请求转发到不同的源。 但是，会话亲和性对于有状态应用程序或来自同一用户的后续请求需要由同一源处理的方案很有用。 此功能可确保同一源处理用户会话，这对于客户端身份验证等方案非常有用。
Azure Front Door 使用基于 Cookie 的会话亲和性，其中使用以原始 URL 的 SHA256 作为标识符的托管 Cookie。 这会将来自用户会话的后续流量定向至同一源。
可以在 Azure Front Door 标准层和高级层中的源组级别启用会话相关性。 启用后，Azure Front Door 会将名为 ASLBSA 和 ASLBSACORS 的 Cookie 添加到用户会话中。 即使用户共享相同的 IP 地址，这些 Cookie 也能帮助识别不同的用户，从而实现不同源之间更均匀的流量分配。
该 Cookie 的生存期与用户的会话相匹配，因为 Front Door 目前仅支持会话 Cookie。
Note
会话亲和性是通过域级别的浏览器会话 Cookie 来维护的。 只要用户浏览器对同一源资源发送请求，同一通配符域下的子域就可以共享会话亲和性。
公共代理可能会干扰会话亲和性，因为建立会话需要 Front Door 向响应中添加会话亲和性 Cookie。 如果响应是可缓存的，则无法执行此操作，因为它会破坏请求相同资源的其他客户端的 Cookie。 为防止这种情况，如果源发送可缓存响应，则 不会 建立会话相关性。 如果会话已经建立，则响应的可缓存性并不重要。
会话亲和性将在标准不可缓存场景之外的以下情况下建立：
- 响应包括
Cache-Control的标头。 - 响应包含有效的
Authorization标头。 - 响应是一个 HTTP 302 状态代码。