你当前正在访问 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 正常）的所有源。
- 示例：假设有 6 个源，即 A、B、C、D、E 和 F，其中 C 的状态不正常，E 已禁用。 那么，可用源的列表是 A、B、D 和 F。
- 优先级：在可用源中选择优先级最高的源。
- 示例：假设源 A、B、D 的优先级为 1，源 F 的优先级为 2。 那么，选择的源会是 A、B 和 D。
- 延迟信号（基于运行状况探测）：从请求到达的 Front Door 环境中，选择允许延迟范围内的源。 此信号基于源组的延迟敏感度设置，以及更近的源的延迟。
- 示例：假设 Front Door 测量了请求在 15 毫秒到达源 A 的环境中的延迟，而 B 的延迟为 30 毫秒，D 的延迟为 60 毫秒。 如果源组的延迟敏感度设置为 30 毫秒，则最低延迟池由源 A 和 B 组成，因为 D 距离最接近的源（即 A）超过 30 毫秒。
- 权重：最后，Azure Front Door 会根据指定的权重比，在最终选择的一组源之间轮循流量。
- 示例：如果源 A 的权重为 3，源 B 的权重为 7，则向源 A 分配 3/10 的流量，并向源 B 分配 7/10 的流量。
如果启用了会话亲和性，则会话中的第一个请求遵循上面列出的流。 后续请求将发送到第一个请求中选择的源。
基于最低延迟的流量路由
通过在全球范围内的两个或更多位置部署源，可将流量路由到“最靠近”最终用户的位置，从而提高应用程序的响应能力。 “延迟”是 Front Door 配置的默认流量路由方法。 此路由方法将最终用户的请求转发到 Azure Front Door 后面最靠近的源。 此路由机制与 Azure Front Door 的任意广播体系结构相结合，可确保根据每个最终用户的位置，为其实现最佳性能。
“最靠近”的源不一定是在地理上距离最近的源。 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 和 5 之间的值。 值越小，优先级越高。 源可以共享相同的优先级值。
加权流量路由方法
使用加权流量路由方法可以均匀分配流量，或使用预定义的权重。
在加权流量路由方法中，需将一个权重分配到源组的 Azure Front Door 配置中的每个源。 该权重是一个介于 1 到 1000 之间的整数。 此参数使用默认权重“50”。
在具有可接受的延迟敏感度的可用源列表中，流量将按指定的权重比以轮循机制分配。 如果延迟敏感度设置为 0 毫秒，则除非存在两个具有相同网络延迟的源，否则此属性不会生效。
加权方法可以实现一些有用的方案：
- 渐进式应用程序升级：分配要路由到新源的流量百分比，并随着时间的推移逐渐增加流量，使其达到与其他源相同的级别。
- 将应用程序迁移到 Azure：创建包含 Azure 源和外部源的源组。 调整源权重，以优先选择新源。 可以采用渐进式的设置方式：一开始禁用新源，然后为它们分配最低权重，再慢慢地将权重提高到接收最多流量的级别。 最后，禁用非首选的源，并从组中删除它们。
- 执行云喷发式部署以增加容量：通过将本地部署放在 Front Door 的后面，快速将其扩展到云中。 需要在云中获取更多的容量时，可以添加或启用更多源，并指定哪部分流量将流向每个源。
会话亲和性
如果未使用会话亲和性，Azure Front Door 默认会将源自同一客户端的请求转发到不同的源。 某些有状态应用程序或者从同一用户发出后续请求的某些方案更偏向于通过同一个源处理初始请求。 需要在同一源上保留某个用户会话时，可以使用基于 Cookie 的会话相关性功能。 使用托管 Cookie 并且将源 URL 的 SHA256 作为 Cookie 中的标识符时，Azure Front Door 可以将来自某个用户会话的后续流量定向到同一源进行处理。
可以为每个已配置的域（或子域）在 Azure Front Door 标准和高级层中的源组级别以及 Azure Front Door（经典）中的前端主机级别启用会话相关性。 启用后，Azure Front Door 会将一个 Cookie 添加到用户的会话。 Cookie 称为 ASLBSA 和 ASLBSACORS。 基于 Cookie 的会话亲和性让 Front Door 可以识别不同的用户（即使他们使用相同的 IP 地址），而这样又可以在不同的源之间更均匀地分配流量。
Cookie 的生存期与用户会话相同，因为 Front Door 目前仅支持会话 Cookie。
注意
无论在何处配置会话亲和性，都将在域级别通过浏览器会话 Cookie 记住会话亲和性。 只要同一用户浏览器对同一源资源发送请求，同一通配符域下的子域就可以共享会话亲和性。
公共代理可能会干扰会话关联。 这是因为，建立会话需要 Front Door 将会话关联 Cookie 添加到响应中，而如果响应可缓存，则无法做到这一点，因为这样可能会中断请求同一资源的其他客户端的 Cookie。 为防止此问题，在尝试建立会话亲和性时，如果源发送可缓存的响应，则不会建立会话亲和性。 如果已建立会话，则来自源的响应是否可缓存并不重要。
会话亲和性将在标准不可缓存场景之外的以下情况下建立：
- 响应必须包含 no-store 的
Cache-Control标头。 - 如果响应包含
Authorization标头，则它不得过期。 - 响应是一个 HTTP 302 状态代码。