Microsoft AZ-700: 负载均衡与流量管理 — 学习指南

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

核心 Azure 负载均衡与边缘服务

Azure 提供了多个专用的流量分发层：Azure Load Balancer (第 4 层)、Application Gateway (第 7 层)、Front Door (全球边缘交付和路由) 以及 Traffic Manager (基于 DNS 的路由)。对于需要高吞吐量、区域冗余和可预测 SNAT 行为的生产环境 TCP/UDP 东西向和南北向场景，请选择 Azure Load Balancer Standard；Basic SKU 功能受限，不建议用于关键工作负载。Application Gateway v2 支持自动缩放、区域冗余、WAF (WAF_v2) 以及针对 HTTP/S 流量的原生基于 URL 和主机的路由，而 v1 版本缺少自动缩放功能，并存在容量规划开销。Front Door (Standard/Premium) 提供全球 Anycast、边缘 TLS 终止、快速故障转移以及用于标头和路径修改的规则引擎；Premium 版本增加了高级 WAF 和私有源支持。Traffic Manager 是基于 DNS 的，适用于地理路由、故障转移和加权分发，但它不能提供 TLS 终止，也不能充当 HTTP 反向代理。在组合使用服务时，可将静态资产推送到 CDN，使用 Front Door 进行全局路由，并使用 Application Gateway 实现区域性 L7 策略和私有后端访问。选择组件时，请考虑以下 SKU 比较：

Azure Load Balancer：Basic 与 Standard (生产环境选择 Standard：区域冗余，默认安全)。
Application Gateway：v1 与 v2 (v2 支持自动缩放，WAF 更新更快)。
Front Door：Standard 与 Premium (Premium 提供高级 WAF 和到源站的 private link)。

健康探测、重写规则和 Web 应用程序防火墙行为

健康探测和 WAF 控制是弹性第 7 层操作的核心。配置健康探测时，应使用能够完整执行请求路径（如果需要，包括身份验证标头）并匹配后端行为的真实端点；设置探测间隔和不健康阈值，以在检测速度与误报之间取得平衡。Application Gateway 的健康探测可以覆盖主机标头并探测特定路径；请确保后端 HTTP 设置（基于 Cookie 的相关性、连接耗尽、空闲超时）与应用程序需求相匹配。重写规则存在于 Application Gateway 和 Front Door 的规则引擎中，应用于规范化标头、剥离或插入前缀，或为后端路由执行 URL 重写，但请记住，重写可能会破坏缓存启发式算法和签名 URL。WAF 策略因平台而异：Application Gateway WAF 通过 OWASP 托管规则和自定义排除项来保护区域后端，而 Front Door Premium WAF 在边缘提供保护，并支持全局策略、机器人防护和高级速率限制。常见的陷阱包括：探测一个静态健康页面，该页面检查通过但应用端点实际已失败；忘记在 NSG 中允许探测 IP 范围；以及错误配置主机标头导致后端拒绝探测请求。

全局流量管理：Front Door、Traffic Manager 和 CDN

Front Door 和 Traffic Manager 都解决全局分发问题，但运作方式不同。Front Door 作为一个全局、有状态的 HTTP/S 代理运行，具备边缘 TLS 终止、智能路由（延迟、优先级和动态站点加速）、内置的 CDN 缓存层以及用于标头/路径操作的规则引擎。Traffic Manager 是一个基于 DNS 的端点选择器，使用优先级、加权、性能和地理位置等路由方法；它擅长简单的故障转移和合规性路由，但无法卸载 TLS 或执行应用层重写。Azure CDN (Standard Microsoft、Standard Verizon、Premium Verizon/Akamai 选项) 针对静态和可缓存内容进行了优化，可以由 Front Door 提供前端服务或独立使用；对于复杂的规则引擎、源站盾牌和高级 SSL 选项，请选择 Premium CDN。对于多站点路由，可在 Application Gateway 中使用基于主机的侦听器进行区域隔离，并使用 Front Door 通过自定义域实现跨区域多站点前端服务。请注意，DNS 缓存会影响 Traffic Manager 的故障转移速度，Front Door 提供快速的边缘故障转移，而 CDN 源站配置应与清除和 TTL 策略保持一致，以避免内容过时。对于私有源站场景，Front Door Premium 支持通过 Private Link 保护源站；否则，请考虑在区域中心使用 Application Gateway。

设计权衡、运维陷阱与监控

设计决策需要在性能、成本和弹性之间进行权衡。对于全球交付和降低客户端延迟，应优先考虑 Front Door 或 CDN；对于靠近后端的丰富 L7 策略控制，应优先考虑 Application Gateway；对于原始 TCP/UDP 吞吐量和可预测的扩展，则应优先考虑 Azure Load Balancer Standard。成本权衡包括选择 Front Door Premium/WAF 和 Application Gateway v2 自动缩放，还是选择成本更低、需手动扩展的 v1 替代方案；通过在边缘整合全局路由，同时保留区域网关用于私有流量检测，可以平衡成本。运维陷阱包括当大量后端从一小组 NAT 地址发起出站连接时，可能出现的 SNAT 端口耗尽问题——此时应使用 NAT Gateway 或调整 SNAT 设置，并避免流量通过同一 NAT 设备进行出入站转发（发夹弯）。另一个常见问题是忘记在 NSG 中为探测 IP 开放端口，或为 Front Door 和 App Gateway 错误配置自定义域和证书。在监控方面，应为每个服务（Load Balancer、App Gateway、Front Door、CDN）启用诊断日志和指标，将其传送到 Log Analytics，并使用 Network Watcher 的流量分析（Traffic Analytics）和连接监视器（Connection Monitor）来实现流级别的可见性。应针对探测失败、后端吞吐量异常和 WAF 检测配置警报，并使用受控流量测试故障转移，以验证运行手册和回滚程序。

实践问题：用例场景

场景：Contoso Manufacturing 公司运营着一个多区域 Azure 环境，其中包含两个区域中心（EastUS 和 WestEurope）、区域性的 Application Gateway v2 实例、两套 VM 规模集应用池，以及一个用于静态资产的现有 CDN。他们需要提供一个具备边缘 WAF 和快速故障转移能力的单一全局端点，同时保留私有的区域性流量检测功能。

挑战：提供一个带有边缘 WAF 和快速跨区域故障转移能力的全局 HTTPS 端点，并且能够将流量路由到私有的区域性 Application Gateway 后端，而无需公开暴露源站。

推荐方法：

部署 Azure Front Door Premium 作为全局入口点（SKU：Front Door Premium），进行 TLS 终止，启用 Front Door WAF 策略（自定义规则 + OWASP），并为每个区域配置一个后端池，该池指向已启用 Private Link 的区域性 Application Gateway v2 的公共 IP，以实现安全的源站连接。
将 Front Door 的源站配置为通过 Private Link 连接到区域性 Application Gateway 的前端，并将健康探测设置为指向 Application Gateway 暴露的一个受保护的健康端点；设置较短的探测间隔（例如 10 秒）和严格的不健康阈值（例如 3 次），以实现快速故障转移。
在每个区域保留 Application Gateway v2，用于 L7 路由、URL 重写以及符合区域策略的本地 WAF 规则；启用自动缩放并将诊断日志发送到 Log Analytics。
对可缓存的静态资产使用 Azure CDN (Standard Microsoft)，并由 Front Door 提供前端接入，以实现最佳的 TTL 和清除控制；针对 Front Door 探测失败和 WAF 阻止率实施监控和警报。

基本原理：Front Door Premium 提供了边缘 WAF 和快速的全局故障转移能力，同时 Private Link 保护了作为源站的区域网关；区域性的 Application Gateway v2 实现了精细的 L7 控制和检测，而无需暴露后端 VM，从而在性能、安全性和弹性之间取得了平衡。

← 网络安全 · 所有领域 · 网络监视与故障排除 →

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