Microsoft AZ-104: Azure 负载均衡和流量管理 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

属于 Microsoft Azure Administrator Associate AZ-104 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 提供了一个分层产品组合来分发和保护流量：Azure Load Balancer (第 4 层, TCP/UDP)、Application Gateway (第 7 层, HTTP/S)、Azure Front Door (全局第 7 层边缘)、Azure Traffic Manager (基于 DNS) 和 Azure CDN (边缘缓存)。每项服务都针对请求路径的特定部分——从全局 DNS 决策和边缘 POP，到区域性 HTTP 路由和私有的东西向流量。精通的关键在于根据协议和受众选择正确的服务，正确地组合它们，并配置健康探测和规则以实现可靠的故障转移。

Azure Load Balancer (L4)：SKU、构建块、NAT/出站和浮动 IP

Standard Load Balancer 是生产级的 L4 负载均衡器。它具备区域感知/区域冗余特性，支持 HA 端口、高级诊断/指标、默认安全（除非定义规则，否则无入站流量）、可配置的出站规则以及大规模后端。Basic 是一个旧版 SKU，其规模/功能有限且不具备区域冗余；它即将停用，不应为新工作负载选择。

核心组件定义了流量的流向：

• 前端 IP：暴露给客户端的 VIP。外部 LB 使用公共 IP 或公共 IP 前缀；内部 LB 使用来自子网的私有静态 IP。Standard SKU 支持多个前端和区域冗余的公共 IP。
• 后端池：同一区域/VNet 中的 NIC、NIC 上的 IP 配置或虚拟机规模集实例。单个池可以服务于多条规则。Standard SKU 支持一个区域内的跨区域后端。
• 健康探测：确定哪些后端实例是健康的。TCP 探测完成一次握手；HTTP/HTTPS 探测对一个路径执行 GET 请求，并将 200–399 状态码视为成功。您可以控制协议、端口、路径 (对于 HTTP/S)、间隔和不健康阈值（在标记为宕机前连续失败的次数）。
• 负载均衡规则：将一个前端（IP/端口/协议）与一个后端池和健康探测绑定。规则设置包括后端端口、协议 (TCP/UDP)、会话保持、空闲超时和浮动 IP (直接服务器返回)。

入站 NAT 规则是针对单个虚拟机的转换，它将特定的前端端口转发到单个后端 NIC/端口（例如，在不进行负载均衡的情况下向一个虚拟机暴露 RDP 或 SSH）。它们不使用健康探测，也不是一种横向扩展机制。

出站规则为通过 LB 的公共前端发起互联网连接的 Standard Load Balancer 后端定义 SNAT 行为。它们允许您控制由哪个前端提供 SNAT 端口，以及为每个后端实例分配多少端口，从而帮助避免在高并发的出站连接下出现 SNAT 端口耗尽。如果子网上附加了 NAT Gateway，它将取代 LB SNAT；对于一致且可扩展的出站连接，应首选 NAT Gateway。

浮动 IP (直接服务器返回) 是一个规则选项，当目标 IP/端口必须在端到端保持不变时使用。它对于集群场景是必需的，例如 SQL Server Always On 可用性组侦听器。对于 SQL AG，请使用内部 Standard Load Balancer，通过 TCP 探测（而非 HTTP）访问集群的探测端口，并在 LB 规则上启用浮动 IP；不要用 HTTP 探测 1433 端口，因为 SQL 不是一个 HTTP 工作负载。

内部与外部负载均衡器的选择取决于受众和安全边界。当在 VNet 内部或通过私有连接 (VPN/ExpressRoute) 为业务线应用、数据库和 NVA 暴露私有 VIP 时，请使用内部 LB。对于面向互联网的 L4 服务，请使用外部 LB。对于内部 LB，在目标子网中分配一个静态私有前端；对于外部 LB，绑定一个 Standard 公共 IP，并可选择使用多个前端。

跨区域负载均衡器提供跨区域的全局、anycast 第 4 层负载均衡。您在每个区域部署 Standard 公共负载均衡器（区域层），并将其公共前端放入单个全局负载均衡器（全局层）的后端。全局 LB 对每个区域 LB 使用健康探测，并根据 5 元组哈希实现流对称性，将客户端定向到（按延迟计算）最近的健康区域。它仅支持 TCP/UDP——不进行 TLS 终止——并与区域性 L7 网关互为补充。

Application Gateway (L7) 与 Azure Front Door (全局 L7)

Application Gateway 是一个区域性的第 7 层反向代理，带有 WAF 功能。它终止 HTTP/HTTPS 连接，检查标头和路径，然后将流量路由到私有或公共后端。

Application Gateway 的关键构造：

• 侦听器 (Listeners): 绑定前端 IP/端口/主机名和 SSL 设置以接收流量。SNI 支持在单个 IP 上托管多个 TLS 站点。使用基本侦听器处理单个站点，使用多站点侦听器进行基于主机的路由，使用通配符主机实现广泛覆盖。
• 路由规则和 HTTP 设置: 规则将侦听器映射到后端池，并指定应用于后端的 HTTP 设置（协议、端口、主机标头覆盖、基于 Cookie 的亲和性、连接耗尽、请求超时）。您可以重定向、重写标头或根据 URL 路径段进行路由。
• 后端池: 目标可以是 NIC IP、FQDN、应用服务或虚拟机规模集。自定义健康探测检查特定的路径/主机，并遵循成功的状态码。
• WAF: 基于 OWASP 核心规则集的保护，支持检测或阻止模式，在 v2 版本中支持自定义规则、排除列表以及按路由关联。v2 版本支持自动缩放和区域冗余。

高级 L7 模式：

• 基于 URL 路径的路由: 将 /api/* 路由到微服务，将 /images/* 路由到静态源或 CDN，从而在一个 VIP 后面实现微服务扇出。
• 多站点托管: 使用 SNI 侦听器和基于主机标头的规则，在单个网关上托管 contoso.com 和 fabrikam.com。这对于通过每个站点的 WAF 策略实现强隔离的整合非常有用。
• SSL 终止: 在网关上卸载 TLS，以实现集中的证书管理和 WAF 检查。当后端需要加密或客户端证书验证时，使用端到端 TLS（重新加密）。

Azure Front Door 在边缘提供全局 HTTP/HTTPS 负载均衡和加速，利用 anycast、分离 TCP 和 POP 到源的优化。它最适合需要全局路由、边缘 WAF 和可选边缘缓存的面向互联网的应用。

• 全局负载均衡: 使用来自多个 POP 的健康探测，将用户路由到延迟最低的健康源。源组支持基于优先级和延迟的故障转移，并可根据需要提供会话亲和性。
• WAF: 托管规则集（含机器人防护）、自定义规则、地理/IP 筛选、速率限制以及按路由关联。
• 缓存: 在 Front Door Standard/Premium 中，边缘缓存是集成的；可以按路径定义缓存行为，控制查询字符串缓存和 TTL，并在全球范围内卸载静态内容。
• 健康探测: 每个源组的探测（HTTP/HTTPS），可配置路径、间隔和协议，并从不同的 POP 发起。路由决策综合了健康状况和延迟。

使用 Application Gateway 满足区域性 L7 需求（私有后端、东西向流量、复杂重写），而 Front Door 用于全局 L7、边缘安全和加速。它们通常组合使用：Front Door 位于边缘，每个区域部署 Application Gateway，网关后面再使用内部 LB 为 L4 服务提供支持。

Traffic Manager (基于 DNS) 与 Azure CDN

Traffic Manager 是基于 DNS 的全局流量分发服务。它不代理流量；相反，它根据策略和健康状况返回端点的 DNS 名称/IP，让客户端直接连接。健康状况通过分布式探针检查 HTTP/HTTPS/TCP 端点；低 TTL 值可以减少故障转移延迟，但会增加 DNS 查询量。

• 优先级 (Priority): 主动/被动故障转移。将主终结点放在首位；除非不健康，否则 Traffic Manager 会一直提供该终结点，然后才会故障转移到下一个优先级的终结点。
• 加权 (Weighted): 按权重分配流量，以支持逐步切换或 A/B 测试。
• 性能 (Performance): 选择从用户所在区域到终结点网络延迟最低的终结点。
• 地理 (Geographic): 根据用户的地理位置进行路由，以满足数据主权或内容本地化需求。
• 多值 (Multivalue): 为同一服务返回多个健康的终结点，以支持简单的客户端故障转移。 您可以嵌套配置文件以实现混合策略（例如，顶层使用地理路由，然后在地理区域内使用加权路由）。当需要处理非 HTTP 协议、不需要边缘代理的服务，或者需要对异构终结点（Azure、本地、第三方）进行 DNS 层控制时，应使用 Traffic Manager。

Azure CDN 将静态和可缓存内容卸载到边缘 POP，以减少源站负载和延迟。

• 配置文件 (Profiles): 一个或多个终结点的容器，与提供商/层级相关联（例如，Microsoft、Akamai 或 Verizon 系列）。配置文件有助于分离环境或成本中心。
• 终结点 (Endpoints): 定义源详细信息（主机名、源主机标头、协议/端口）和边缘主机名。每个配置文件可以有多个终结点，用于不同的应用或内容类型。
• 缓存规则: 默认和自定义规则控制 TTL、基于路径的行为、查询字符串处理（转发、忽略或缓存每个唯一查询）和压缩。使用规则可以强制缓存源站 TTL 较短的资产，或绕过对动态 API 的缓存。
• 自定义域: 使用 CDN 管理的 TLS 映射友好的主机名。通过 CNAME 验证域所有权，并使用托管证书启用 HTTPS。根据需要与地理筛选或规则引擎结合使用。

设计选择、跨区域集成和健康探测行为

内部与外部负载均衡器的选择取决于受众和路由暴露情况。如果使用者仅位于私有网络内部，应使用内部负载均衡器以避免公共暴露并简化 NSG 控制。对于互联网用户或合作伙伴，则使用公共前端。对于大规模出站连接，优先选择 NAT Gateway 而非负载均衡器的 SNAT；仅在负载均衡器的前端必须提供 SNAT 的情况下才保留出站规则。

Cross-region Load Balancer 与区域性的 Standard Public Load Balancer 集成，为 TCP/UDP 服务实现主动-主动、全局第 4 层的弹性。将区域性负载均衡器的公共前端放置在全局负载均衡器的后端池中。全局层的健康探测反映了区域的可用性；路由会将流量导向延迟最低的健康区域，并在整个区域（或其区域性负载均衡器）变为不健康时自动进行故障转移。当您需要在不同的 VIP 下同时支持多种协议时（例如，通过 Cross-region Load Balancer 支持 TCP 服务，通过 Front Door 支持 HTTP/S），可将此方案与 Front Door 结合使用。

健康探测是故障转移的真实性来源：

• TCP 探测：适用于任何 TCP 服务。完成三次握手即表示成功。适用于 SQL、SMTP 或自定义 TCP 协议。
• HTTP/HTTPS 探测：通过请求一个路径并期望得到 200–399 状态码来验证应用程序级别的健康状况。它们允许自定义主机/路径，并能区分部分应用程序故障。HTTPS 探测会验证 TLS 协商，但不会在握手之外验证证书的有效性；对于虚拟主机托管的应用程序，请使用正确的主机标头。
• 不健康阈值：Azure Load Balancer 在连续 N 次探测失败后将后端标记为故障（可配置；默认间隔较短以加速故障转移）。Application Gateway 和 Front Door 从多个探测点进行探测，当其探测集累积了足够多的连续失败时，才认为源站故障。恢复则需要连续的成功探测。调整探测间隔和阈值以平衡敏感度与抖动；确保探测能到达一个轻量级且能感知依赖关系的终结点。

实际问题场景

Adobe 需要在全球范围内暴露一个多区域 SaaS 应用，该应用由 Web 前端、微服务和一个 SQL Server Always On 可用性组构成，要求为全球用户提供严格的安全性、快速的故障转移和低延迟。他们还需要暴露一个基于 TCP 的旧式遥测数据注入服务。

1. 在边缘部署 Azure Front Door Standard，并为其配置 WAF 策略以及针对 www.adobe.com 和 api.adobe.com 的路由。源站是位于美国东部和西欧的 Application Gateway，通过基于延迟的路由和优先级故障转移进行分组。

• 原因：Front Door 提供全局任播 (anycast)、边缘 WAF 和可选的缓存功能，以加速和保护互联网 HTTP/S 流量；它会自动选择最近的健康区域。

2. 在每个区域部署带 WAF 的 Application Gateway v2。为两个主机名配置带 SNI 的多站点侦听器，配置到微服务的基于 URL 路径的路由，以及到每个服务的 /healthz 的自定义健康探测。启用端到端 SSL，并将后端主机重写为服务的 FQDN。

• 原因：Application Gateway 提供区域性的 L7 路由、靠近应用程序的 WAF 检测、基于路径的扇出和按路由的策略；它可以安全地连接到私有后端，并处理标头重写/重定向。

3. 在每个区域为 SQL AG 侦听器部署一个内部 Standard Load Balancer。配置一个静态私有前端、一个指向 Windows 故障转移群集探测端口的 TCP 健康探测，以及一条为侦听器端口启用浮动 IP (Floating IP) 的负载均衡规则。

• 原因：SQL 侦听器需要 L4 和直接服务器返回 (DSR)。浮动 IP 保留了目标语义，而 TCP 探测能准确反映 AG 的所有权。这也符合一个已知要求，即在 1433 端口上进行 HTTP 探测是无效的。

4. 使用 Azure Front Door 的缓存规则为 /static/* 路径下的 Web 静态资产提供支持，设置较长的 TTL 和重新验证。同时，为 downloads.adobe.com 上的大型媒体下载建立一个 Azure CDN 配置文件和终结点，并配置路径特定的缓存和查询字符串变体。

• 原因：Front Door 缓存与边缘路由协同工作，可降低核心 Web 静态内容的延迟，而专用的 CDN 终结点则为下载优化了大对象交付，并保证了缓存策略的独立性。

5. 通过每个区域的区域性 Standard Public Load Balancer 发布旧的 TCP 遥测注入服务，然后使用一个 Cross-region Load Balancer 作为单一的公共 VIP 置于其前端。配置到每个区域性负载均衡器的全局探测，并使用基于延迟的路由。

• 原因：该服务是 TCP 而非 HTTP；Cross-region Load Balancer 提供全局主动-主动的 L4 负载均衡，具备自动故障转移和低延迟区域选择能力。

6. 仅为一个托管在 Azure 外部的合作伙伴 SFTP 终结点添加 Azure Traffic Manager，并使用优先级 (Priority) 策略，将合作伙伴的主终结点和 Azure 托管的备份终结点列入其中。

• 原因：Traffic Manager 是基于 DNS 的，可以包含外部终结点；对于不希望使用代理的非 HTTP 和第三方目标，它能提供简单的主动/被动故障转移。

7. 对于应用子网的出站连接，附加 NAT Gateway 并移除对负载均衡器出站 SNAT 的依赖。在 Azure Monitor 中监控探测结果以及 LB/App Gateway/Front Door 的指标，并调整探测间隔/不健康阈值以消除抖动。

• 原因：NAT Gateway 能够可靠地扩展出站连接，而不会耗尽 SNAT 端口；精确的健康探测调优可以在各个层级实现更快、更稳定的故障转移行为。

← Azure 虚拟网络 · 所有领域 · Azure 存储 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →