通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关 Azure 流量管理器的架构良好的框架透视图

  • 项目

Azure 流量管理器是一个全局负载均衡器，可以跨多个 Azure 区域、区域中的区域或这些区域中的数据中心分配流量。 它使用域名系统（DNS）协议在客户端和工作负荷的终结点之间建立通信路径。 建立连接后，客户端可以直接连接到终结点，而无需流量管理器帮助。

本文假设作为架构师，你已查看 Azure 中的 负载均衡选项，并为工作负荷选择了 Azure 流量管理器，该管理器部署在主动-主动或主动-被动模型中的多个区域。 本文中的指南提供了映射到 Well-Architected 框架支柱原则的体系结构建议。

重要

如何使用本指南

每个部分都有一个 设计清单，该清单提供关注的体系结构区域以及本地化为技术范围的设计策略。

此外，还包括有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于流量管理器及其依赖项的所有配置的详尽列表。 然而，它们列出了映射到设计视角的关键建议。 使用建议生成概念证明或优化现有环境。

演示关键建议的基础体系结构：使用流量管理器、Azure 防火墙和应用程序网关的多区域负载均衡。

技术范围

此审查重点讨论以下 Azure 资源的相互关联决策：

  • 流量管理器

示意图，展示了 Azure 流量管理器的故障转移场景。

注意

对于托管 HTTP 应用程序的工作负载，Azure Front Door 是一个自然的选择，因为它具有许多功能，例如内容分发网络、传输层安全性（TLS）终止和集成防火墙。

与 Azure Front Door 相比，流量管理器更易于设置、配置和维护。 流量管理器没有可以直接控制的终结点。 与处理客户端请求的 Front Door 不同，流量管理器仅将客户端连接到工作负荷的终结点。

但是，这种简单性带来了权衡，在体系结构中可能会带来复杂性。 例如，可能需要实施额外的安全措施来阻止 Open Worldwide Application Security Project （OWASP） 攻击类型。 Azure Front Door 或 Azure 应用程序网关中的 Web 应用程序防火墙（WAF）提供此功能。 或者，可以添加缓存，从而加快内容交付速度，但会增加复杂性，因为必须管理数据存储。

有关详细信息，请参阅有关 Azure Front Door 的架构良好的框架透视图。

可靠性

可靠性支柱的目的是通过 构建足够的复原能力和从故障中快速恢复来提供持续的功能。

可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。

设计清单

根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时牢记应用程序的性质及其组件的关键性。 扩展策略以根据需要包含更多方法。

  • 考虑潜在的故障。 流量管理器被设计为具有高度的抗逆性。 但它仍然可能是工作负载的单点故障。 若要缓解此风险，请定义备用服务的辅助路径，如果流量管理器不可用，该服务将变为活动状态。 为了避免路由问题，请勿将流量管理器和备用服务一起使用。

  • 充分了解服务级别协议（SLA）覆盖范围。 评估流量管理器 SLA 时，请了解与公布的百分位数相关的覆盖范围。 例如，DNS 查找可能会多次失败。 在发生连续 DNS 查找失败整分钟之前，这些故障不会被视为停机。

  • 在工作负荷体系结构中合并冗余。 如果服务通过公共 IP 地址公开，请使用流量管理器跨 Azure 区域、本地和其他云实现冗余。 例如，你可能有一个本地应用程序，该应用程序在云中有一个辅助实例。 如果本地系统发生故障，云实例可能会处于活动状态，这有助于确保连续性。

  • 使用可靠的部署体系结构来支持冗余。 作为负载均衡器，流量管理器根据配置其路由方法的方式在工作负荷终结点之间分配流量。 在流量管理器配置文件中定义此配置。 配置文件是部署策略的核心组件。 你可以使用适当的配置文件配置来实现一个主动-主动模型或一个采用暖备份的主动-被动模型。

    每个配置文件都指定单个流量路由方法。 某些方案需要更复杂的流量路由。 可以将流量管理器配置文件组合在一起，以利用多个流量路由方法。

    有关详细信息，请参阅 流量管理器路由方法。

  • 评估 DNS 响应的缓存持续时间。 流量管理器中 DNS 查找的生存时间（TTL）设置决定了下游 DNS 解析程序缓存 DNS 响应的时间。 默认 TTL 可能会导致缓存时间超过必要时间，这可能会导致终结点发生故障时停机。 减少 TTL 以增加缓存更新的频率。 此方法可以帮助缓解停机时间，但会增加 DNS 查找的频率。

  • 避免将流量发送到运行不正常或受损的实例。 查看流量管理器中的内置运行状况探测功能。

    对于 HTTPS 和 HTTP 应用程序，实现健康检查端点监控模式，以在应用程序中提供自定义页面。 根据特定检查，页面返回相应的 HTTPS 状态代码。 除了监控端点的可用性外，您的健康检查还应监控应用程序的所有依赖项。

    对于其他应用程序，流量管理器使用传输控制协议（TCP）来确定终结点的可用性。

    有关详细信息，请参阅运行状况终结点监视模式和了解流量管理器探测。

  • 确定停电耐受性。 如果后端变得不可用，在流量管理器识别失败并停止将流量定向到不可用的终结点之前，可能会经过一段时间。 有一段时间无法满足客户请求。 使用此容差配置探头设置，以确定您希望启动业务连续性操作的速度。

  • 在复原测试中包括终结点。 模拟不可用的终结点，了解流量管理器如何处理故障。 假设工作负荷使用负载均衡器，例如专用虚拟网络中的应用程序网关。 可以使用 Azure Chaos Studio 中的网络安全组（NSG）规则来模拟终结点的故障。 可以阻止访问应用程序网关所在的子网。

建议

建议 好处
在流量管理器配置文件中部署多个终结点，并启用它们。 如果未启用终结点，则不会对此终结点进行运行状况检查，也不会在流量路由轮换中包含此终结点。 将这些终结点放置在不同的区域中。 冗余实例有助于确保一个终结点发生故障时的可用性。
评估各种流量路由方法。 配置一种或组合方法，使其与部署策略保持一致。 流量管理器将所选的方法应用于每个 DNS 查询，并使用该方法来确定 DNS 响应中返回的终结点。

- 加权方法 根据配置的权重系数分配流量。 此方法支持主动-主动模型。
- 基于优先级的方法 将主要区域配置为接收流量并将其作为备份发送到次要区域。 此方法支持主动-被动模型。
- 地理方法 基于 DNS 查询的地理来源路由流量。 若要覆盖所有区域，请使用 All（World） 属性配置至少一个终结点。		 优化的路由方法有助于确保有效地在终结点之间分配流量。

你可以为实现主动-主动或主动-被动部署模型目标提供支持。 高效的路由方法有助于确保次要区域可以处理流量或充当备份。

地理路由有助于根据用户的位置将用户定向到最近的终结点。 它有助于确保流量得到有效管理，且不会丢失。
将 DNS TTL 间隔 持续时间设置为低值，最好小于 60 秒。 若要优化性能，请调整运行状况探测计时和 DNS 记录 TTL。 较短的 TTL（存活时间）有助于确保下游 DNS 缓存更频繁更新和更快速切换。 它还可最大程度地减少停机时间，并提高应用程序的整体响应能力。
设置运行状况探测以监视终结点。

- 不要启用 AlwaysServe，因为这会禁用终结点监视，并在不考虑终结点运行状况的情况下发送请求。
- 设置 probing interval 值。 请考虑检测故障的速度与终结点请求数之间的权衡。 请求的数量可能很大，因为流量管理服务是一项全球性服务，可以从各种位置同时执行 ping 操作。
- 设置 probe timeout 值。 请考虑在判断端点不正常之前等待多长时间。 在失败数中包含误报。		 运行状况探测可确保只有正常的实例来满足用户请求。 它们还有助于确定故障是否为非暂时性，以及故障转移操作应该以多快的速度进行。

安全

安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。

安全设计原则 通过应用流量管理器技术设计方法来实现这些目标提供了一种高级设计策略。

设计清单

  • 查看安全基线。 若要增强安全状况，请查看流量管理器的安全基线。

  • 防止未经授权的流量路由修改。 将流量管理器配置文件视为关键工作负荷资源，因为它们包含路由流量的配置设置。 只有经过授权的标识才能访问这些配置文件。 在控制平面上实现 基于角色的访问控制（RBAC），以限制创建、删除或修改资源等任务。 只有经过授权的身份才有权启用或禁用终结点。 未经授权的访问可能会导致配置更改，并可能将流量重新路由到恶意实现。

  • 保护应用程序免受网络边缘的威胁。 流量管理器不提供内置安全功能，如 WAF。 为了帮助保护 HTTP 应用程序，应在终结点级别实现流量检查。

    典型的体系结构可能包括流量管理器和多个终结点。 对于每个终结点，处理 TLS 终止和其他安全功能的应用程序网关提供保护。 有关演示该模式的参考体系结构，请参阅 流量管理器、Azure 防火墙和应用程序网关的多区域负载均衡。

  • 强化 DNS 条目。 流量管理器可能容易受到纵 DNS 数据的攻击，这些攻击可将流量重定向到恶意站点并导致安全问题。 常见的威胁是子域接管，其中 DNS 记录指向已取消预配的 Azure 资源。 若要防止子域接管，请使用 Azure DNS 别名记录，并将 DNS 记录的生命周期与 Azure 资源结合在一起。

    有关详细信息，请参阅 防止悬空的 DNS 条目。

建议

建议 好处
将应用程序网关添加到工作负荷终结点。

若要使用 HTTP 应用程序的防火墙实施安全检查，请将应用程序网关添加到工作负荷终结点。		 可以检查入站 HTTP 流量，以帮助保护应用程序免受常见攻击。
在 Azure DNS 中为工作负荷的顶级域名创建别名记录，以引用流量管理器配置文件。 别名记录与 Azure 资源紧密耦合 DNS 记录的生命周期。 如果工作负载被停用，此配置有助于防止出现无效引用。 如果删除了流量管理器配置文件，则 DNS 别名记录将成为空记录集。 它不再引用已删除的资源。

成本优化

成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。

成本优化设计原则 提供了一种整体设计策略，用于在与流量管理器及其环境相关的技术设计中实现这些目标并进行必要的权衡。

设计清单

根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。

  • 评估功能成本。 流量视图仪表板功能显示客户端从何处进行连接以及关联的延迟。 此信息有助于优化性能和优化设计，这有助于卓越运营和系统效率。 但是，会产生额外的费用。 有关详细信息，请参阅流量视图计费。

    另请考虑与健康探测相关的成本。 流量管理器从各个位置对定义的终结点执行 ping 操作，以检查其可用性。 可以选择慢速 ping 和快速 ping。 快速 ping 可更快地检测故障，但会产生更高的成本。 健康检查频率增加，这也给工作量带来了更多负担。

  • 评估路由策略的成本。 例如，如果大多数客户端从高延迟区域访问终结点，则可以创建离这些用户更近的另一个终结点，并在流量管理器中调整路由方法。 这种做法可降低延迟，以便可以处理容量较少的更多请求，从而节省成本。

建议

建议 好处
使用 定价计算器 来估算流量管理器功能的成本。 可以拥有更准确的成本模型，并在必要时围绕资源设置治理。
在优化过程中启用 流量视图仪表板。 此功能可帮助你更好地了解使用模式。 使用此数据进行性能优化，以帮助满足工作负荷目标。

在正确的时间启用功能，并应用适当的级别以避免资源未得到充分利用。
根据恢复指标，选择快速或慢速 ping 以进行运行状况探测。

快速 ping 可更快地检测故障，但成本更高。 慢 ping 速度较慢，但成本较低。

不要禁用 ping。		 通过减少 Ping 的频率来优化成本并减轻工作负载端点的压力。

卓越运营

卓越运营主要侧重于开发实践、可观测性和发布管理等过程。

卓越运营设计原则 提供了一种高级设计策略，以实现工作负载运营需求的目标。

设计清单

  • 在工作负荷监控中收集和分析运营数据。 捕获相关的流量管理器日志和指标。 使用此数据进行故障排除、了解流量行为和微调路由逻辑。

  • 查看配置文件的流量数据。 此数据有助于查明需要改进的领域，例如在高延迟区域扩展 Azure 服务覆盖范围。 它还重点介绍了不同区域的流量模式，以帮助确定增加或减少投资的位置。

  • 实施灾难恢复操作。 灾难恢复实现旨在将网络/Web 流量从主站点重新路由到备份站点。 可以使用 Azure DNS 和 Azure 流量管理器（DNS）实现此灾难恢复方法。 发生灾难时，如果主终结点降级，流量管理器会将流量重定向到正常的辅助终结点。 默认情况下，流量管理器优先选择主终结点，但也可以通过设置额外的故障转移终结点或负载均衡器来分配流量负载。 有关详细信息，请参阅设置灾难恢复和中断检测。

  • 避免自动故障切换操作。 执行故障回复时，请勿使用自动故障回复，主节点中的原始终结点可用时，自动故障回复会立即切换回此原始终结点。 请改为禁用原始终结点，并在切换前使用辅助终结点。 此方法为稳定提供了时间。 即时故障回复可能会造成额外的负载和延迟。

    有关详细信息，请参阅 多区域负载均衡参考体系结构。

  • 测试配置设置。 配置错误可能会影响工作负荷的所有方面，尤其是可靠性。 在各种位置使用多个客户端测试配置。 有关详细信息，请参阅验证流量管理器设置。

建议

建议 好处
为流量管理器配置文件启用诊断日志。

使用工具重播日志并分析运行状况检查数据。		 诊断日志提供有关流量管理器配置文件行为的见解。 例如，你可以确定终结点的单项探测超时的原因。
启用流量视图仪表板。 获取有关客户端从何处进行连接以及关联的延迟的见解。 此信息有助于优化性能和成本，因为可以优化设计。
利用 热度地图 REST API，该 API 提供有关客户端位置和延迟的数据。 此方法提供灵活性，例如设置特定时间段。 可以将数据添加到自定义工具或仪表板。 还可以使用此 API 与外部工具集成。
针对操作活动禁用终结点。 例如，你可能会在故障转移之后禁用故障回复来进行维护或测试。 禁用负载均衡器中的终结点有助于执行操作任务，因为你不能中断实时流量。 在维护期间，如果禁用终结点，实例不会接收流量。 此方法可防止进行自动故障回复。

性能效率

性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。

性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。

设计清单

根据性能效率设计评审清单开始设计策略。 定义基于流量管理器的关键绩效指标的基线。

  • 测量配置的性能影响。 流量管理器不会干扰客户端和终结点之间的直接连接。 主要性能影响是初始 DNS 查找。 TTL 设置会影响此查找的频率。 较低的 TTL 意味着更频繁的 DNS 解析，这可能会影响性能。 如果将 TTL 设置为零，则每个请求都需要 DNS 查找，这会在访问终结点之前添加一个小延迟。

    由于流量管理器在 DNS 级别运行，因此它不支持会话相关性。 流量管理器可能会将用户定向到每个呼叫的不同终结点。 如果需要会话相关性，则必须将状态保存到单独的数据存储。

    有关详细信息，请参阅 流量管理器性能注意事项。

  • 调整流量路由行为以优化性能。 单个配置文件可能具有多个终结点，但你一次只能应用一个路由方法。

    对于更复杂的方案，请考虑创建配置文件层次结构来组合不同的路由方法。 例如，可以确定区域优先级，然后在区域中使用基于性能的路由。

建议

建议 好处
当具有不同地理位置的终结点时，请使用 性能路由方法。 此方法优先将流量发送到延迟最低的终结点。 此方法有助于确保为用户提供快速服务。
使用专用工具优化性能。 测量 DNS 查找的性能。 若要分析流量的性能，请使用 流量视图仪表板 或 热度地图 REST API。 DNS 延迟度量工具执行完整的 DNS 查找并提供性能数据。 可以使用此数据设置 TTL 持续时间并优化性能。
根据工作负荷要求，将流量方法与嵌套配置文件结合使用以获得最佳性能。 优化的路由方法有助于确保流量定向到响应最快且最接近的终结点。 此方法有助于提高应用程序性能和用户体验。
使用实际用户度量功能 查看 Azure 区域的网络延迟度量。 此功能无需额外付费。 可以做出数据驱动的路由决策，以将查询定向到提供最低延迟的 Azure 区域。
将 DNS TTL 间隔 设置为更高的值。 客户端可以缓存较长时间的结果，从而减少每次解析 DNS 的需求。

Azure 策略

Azure 提供了一组与流量管理器及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下情况：

  • 启用了资源日志来跟踪活动。
  • 流量管理器配置文件的日志会发送到 Azure 事件中心。

有关全面治理，请查看 Azure 网络服务 的Azure Policy 内置定义。

Azure 顾问建议

Azure 顾问 是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。 下面是一些建议，可帮助你提高 Web 应用程序实例的可靠性、安全性、成本效益、性能和卓越运营能力。

权衡

如果使用支柱清单中的方法，可能需要进行设计权衡。 下面是一些优点和缺点示例。

可靠性和性能效率

  • DNS 查找的 TTL 设置。 默认 TTL 设置可能会导致缓存时间更长。 如果终结点失败，长时间缓存时间可能会导致停机，因为应用程序在 TTL 持续时间内继续尝试连接到失败的终结点。

    减少 TTL 以帮助缓解此问题。 较低的 TTL 会导致更新更频繁，故障转移更迅速，但这也会增加 DNS 查找的频率。 此方法可能会影响性能并增加 DNS 服务器上的负载。

可靠性和成本优化

  • 运行状况探测。 流量管理器使用运行状况探测从各个位置 Ping 终结点，以检查其可用性。 可以选择慢速 ping 或快速 ping。 快速 ping 可更快地检测故障，但增加了成本。 慢速 ping 检测故障所需的时间更长，但其成本较低。 将故障检测和恢复速度与相关的成本进行平衡。

下一步

请考虑以下资源，这些资源演示了本文中的建议。