您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

Front Door 路由方法

Azure Front Door 支持使用各种不同的流量路由方法来确定将 HTTP/HTTPS 流量路由到不同的服务终结点的方式。 当客户端请求抵达 Front Door 时,将会应用配置的路由方法,以确保将请求转发到最佳的后端实例。

Front Door 中提供四种流量路由方法:

  • 延迟 基于延迟的路由确保将请求发送到在敏感度范围内可接受的最低延迟的后端。 简单而言,将在考虑到网络延迟的情况下,将用户请求发送到“最靠近的”后端集。
  • 优先级:如果想要配置主后端来处理所有流量,可为后端分配优先级。 辅助后端可以作为备份,以防主后端变得不可用。
  • 权重:如果希望在一组后端中均匀分配流量或根据权重系数分配流量,则可向后端分配权重。 如果后端的延迟在后端池中可接受的延迟敏感度范围内,则流量按权重分布。
  • 会话亲和性:可为前端主机或域配置会话亲和性,以确保来自同一最终用户的请求发送到同一后端。

所有 Front Door 配置包括后端运行状况的监视,以及自动化的即时全局故障转移。 有关详细信息,请参阅 Front Door 后端监视。 Front Door 可以基于单一的路由方法运行。 但根据应用程序的需要,你还可结合多种路由方法来构建最佳路由拓扑。

基于最低延迟的流量路由

通过在全球范围内的两个或更多位置部署后端,可将流量路由到“最靠近”最终用户的位置,从而提高应用程序的响应能力。 Front Door 配置默认的流量路由方法会将最终用户的请求转发到接收请求的 Front Door 环境中最靠近的后端。 此方法与 Azure Front Door 的任意广播体系结构相结合,可确保根据每个最终用户的位置,将其个性化的性能发挥到极致。

“最靠近”的后端不一定是地理距离最近的后端。 Front Door 通过测量网络延迟来确定最靠近的后端。 详细了解 Front Door 的路由体系结构

下面是整体决策流:

可用后端 优先级 延迟信号(基于运行状况探测) 权重
首先,选择已启用的且运行状况探测对其返回了正常状态 (200 OK) 的所有后端。 如果有 6 个后端 A、B、C、D、E 和 F,其中 C 的状态不正常,E 已禁用。 那么,可用后端的列表是 A、B、D 和 F。 接下来,在可用后端中选择优先级最高的后端。 如果后端 A、B 和 D 的优先级为 1,后端 F 的优先级为 2。 那么,选择的后端将是 A、B 和 D。 选择在延迟范围内的后端(最小延迟,根据以毫秒为单位指定的延迟敏感度确定)。 如果后端 A、B 和 D 与请求抵达的 Front Door 环境之间的通信延迟分别是 15 毫秒、30 毫秒和 60 毫秒,延迟敏感度为 30 毫秒,那么,最低延迟池由后端 A 和 B 构成,因为 D 与最靠近的后端(即 A)之间的延迟差超过了 30 毫秒。 最后,Front Door 将会根据指定的权重比,在最终选择的后端池之间轮循流量。 假设后端 A 的权重为 5,后端 B 的权重为 8,则流量将按 5:8 的比在后端 A 与 B 之间分配。

备注

默认情况下,延迟敏感度属性设置为 0 毫秒,即始终将请求转发到最快的可用后端,并且后端上的权重不会生效,除非两个后端具有相同的网络延迟。

基于优先级的流量路由

组织往往会部署一个或多个备份服务来防范主服务发生故障,从而确保其服务的高可用性。 在整个行业中,此拓扑也称为“主动/后备”或“主动/被动”部署拓扑。 Azure 客户可以通过“优先级”流量路由方法来轻松实现此故障转移模式。

默认的 Front Door 包含后端的均等优先级列表。 默认情况下,Front Door 只将流量发送到最高优先级后端(优先级值最小),即主要后端集。 如果主要后端不可用,则 Front Door 会将流量路由到辅助后端集(优先级值倒数第二小)。 如果主要后端和辅助后端都不可用,流量将转到第三个后端集,依此类推。 后端可用性基于配置的状态(已启用或已禁用),持续的后端运行状况由运行状况探测确定。

配置后端的优先级

Front Door 配置的后端池内的每个后端都有一个名为“优先级”的属性,它可以是介于 1 和 5 之间的数字。 在 Azure Front Door 中,可以使用此属性为每个后端显式配置后端优先级。 此属性是介于 1 和 5 之间的值。 值越小,优先级越高。 后端可以共享优先级值。

加权流量路由方法

使用“加权”流量路由方法可以均匀分布流量,或使用预定义的权重。

在加权流量路由方法中,需将一个权重分配到后端池的 Front Door 配置中的每个后端。 该权重是从 1 到 1000 的整数。 此参数使用默认权重“50”。

在延迟敏感度可接受的可用后端列表中,流量将按指定的权重比以轮循机制分配。 如果延迟敏感度设置为 0 毫秒,则除非存在两个具有相同网络延迟的后端,否则此属性不会生效。

加权方法可以实现一些有用的方案:

  • 渐进式应用程序升级:分配要路由到新后端的流量百分比,并逐渐将流量按比例路由到其他后端。
  • 将应用程序迁移到 Azure:创建包含 Azure 后端和外部后端的后端池。 调整后端权重,以优先选择新的后端。 可以采用渐进式的设置方式:一开始禁用新后端,然后为它们分配最低权重,再慢慢地将权重提高到接收最多流量的级别。 最后,禁用优先级最低的后端,并从池中删除它们。
  • 执行云喷发式部署以增加容量:通过将本地部署放在 Front Door 的后面,快速将其扩展到云中。 需要在云中获取更多的容量时,可以添加或启用更多后端,并指定哪部分流量将流向每个后端。

会话关联

默认情况下,如果没有会话亲和性,Front Door 会将源自同一客户端的请求转发到不同的后端。 某些有状态应用程序或者从同一用户发出后续请求的某些方案更偏向于通过同一个后端处理初始请求。 需要在同一后端上保留用户会话时,基于 Cookie 的会话关联功能非常有用。 Azure Front Door 可以使用托管的 Cookie 将来自某个用户会话的后续流量定向到同一个后端进行处理。

可以在配置的每个域(或子域)的前端主机级别启用会话关联。 启用后,Front Door 会将一个 Cookie 添加到用户的会话。 基于 Cookie 的会话关联可让 Front Door 识别不同的用户(即使他们使用相同的 IP 地址),而这又可以在不同的后端之间更均匀地分配流量。

Cookie 的生存期与用户会话相同,因为 Front Door 目前仅支持会话 Cookie。

备注

公共代理可能会干扰会话关联。 这是因为,建立会话需要 Front Door 将会话关联 Cookie 添加到响应中,而如果响应可缓存,则无法做到这一点,因为这样可能会中断请求同一资源的其他客户端的 Cookie。 为防止此问题,如果后端发送可缓存的响应,则 不会 建立会话关联。 如果已建立会话,则来自后端的响应是否可缓存并不重要。 除非 响应中包含 HTTP 304 状态代码,否则,在以下情况下会建立会话关联:

  • 响应中为 Cache-Control 头设置了防止缓存的特定值,例如“private”或“no-store”。
  • 响应中包含未过期的 Authorization 标头。
  • 响应中包含 HTTP 302 状态代码。

后续步骤