你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
将流量路由到源的方法
重要
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（经典）中的后端池。 规则引擎设置的源组或后端池将替代本文所述的路由过程。
总体决策流程
下图展示了总体决策流程：
决策步骤包括：
- 可用源：选择已启用且已在进行运行状况探测时返回正常状态（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 环境都会独立度量到源的延迟，这意味着不同位置的用户会被路由到为其特定环境提供最佳性能的源。
注意
默认情况下，延迟敏感度属性设置为 0 毫秒。 通过此设置，请求始终会被转发到最快的可用源。 仅当两个源具有相同的网络延迟时，源上的权重才会生效。
有关详细信息，请参阅 Azure Front Door 路由体系结构。
基于优先级的流量路由
为了确保高可用性，组织通常会部署备份服务，以便在主服务出现故障时接管操作。 此设置称为主动/待机或主动/被动部署。 Azure Front Door 中的“优先级”流量路由方法允许你有效地实现此故障转移模式。
默认情况下，Azure Front Door 将流量路由到具有最高优先级（最低优先级值）的源。 如果这些主要源变得不可用，它会将流量路由到次要源（下一个最低优先级值）。 如果主要源和次要源均不可用，则使用第三个源继续该过程。 运行状况探测器根据源的配置状态和运行状况监视源的可用性。
配置源的优先级
Azure Front Door 源组中的每个源都有一个“优先级”属性，可将其设置为 1 到 5 之间的值。 值越低，优先级越高。 多个源可以共享相同的优先级值。
加权流量路由方法
“加权”流量路由方法允许根据预定义的权重分配流量。
在此方法中，可为 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（经典）中的前端主机级别启用会话相关性。 启用后，Azure Front Door 会将名为 ASLBSA 和 ASLBSACORS 的 Cookie 添加到用户会话中。 即使用户共享相同的 IP 地址，这些 Cookie 也能帮助识别不同的用户，从而实现不同源之间更均匀的流量分配。
该 Cookie 的生存期与用户的会话相匹配，因为 Front Door 目前仅支持会话 Cookie。
注意
会话亲和性是通过域级别的浏览器会话 Cookie 来维护的。 只要用户浏览器对同一源资源发送请求，同一通配符域下的子域就可以共享会话亲和性。
公共代理可能会干扰会话亲和性，因为建立会话需要 Front Door 向响应中添加会话亲和性 Cookie。 如果响应是可缓存的，则无法执行此操作，因为它会破坏请求相同资源的其他客户端的 Cookie。 为防止出现这种情况，如果源发送可缓存的响应，则不会建立会话亲和性。 如果会话已经建立，则响应的可缓存性并不重要。
会话亲和性将在标准不可缓存场景之外的以下情况下建立：
- 响应包含带有 no-store 的
Cache-Control标头。 - 响应包含有效的
Authorization标头。 - 响应是一个 HTTP 302 状态代码。