通过

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

适用于任务关键型 Web 应用程序的全局路由冗余

重要

为任务关键型架构设计处理全局平台中断的冗余实施可能很复杂且成本高昂。 由于此设计可能出现的潜在问题，请仔细考虑 权衡。

在大多数情况下，您不需要本文中描述的架构。

任务关键型系统通过在解决方案中尽可能多地构建冗余和自我修复功能，努力最大限度地减少单点故障。 系统的任何统一入口点都可以被视为故障点。 如果此组件遇到中断，则整个系统将对用户处于脱机状态。 选择路由服务时，请务必考虑服务本身的可靠性。

在 任务关键型应用程序的基线体系结构中，选择 Azure Front Door 是因为其高运行时间服务级别协议 （SLA） 和丰富的功能集：

  • 将流量路由到主动-主动模型中的多个区域
  • 使用 TCP 任播的透明故障转移
  • 使用集成内容分发网络 （CDN） 从边缘节点提供静态内容
  • 通过集成的 Web 应用程序防火墙阻止未经授权的访问

有关 Azure Front Door 功能的详细信息，请参阅 使用 Azure Front Door 加速和保护 Web 应用程序。

Azure Front Door 旨在为我们的外部客户提供最大的复原能力和可用性，并为 Microsoft 中的多个资产提供最大的复原能力和可用性。 Azure Front Door 功能足以满足大多数业务要求，但是，对于任何分布式系统，预计会失败。 没有任何组件或系统是万无一失的。 Microsoft 为 Azure Front Door 提供行业领先的服务级别协议（SLA）。 即使其他提供商提供 100% 运行时间 SLA，请务必注意，这并不能保证零停机时间，并且 SLA 通常会在发生中断时提供服务信用额度。

如果业务要求在发生中断时需要更高的复合 SLO 或零停机时间，则需要依赖多个备用流量入口路径。 许多大型组织和知名 Web 资产都使用此方法来确保尽可能高的可用性并优化投放性能。 但是，追求更高的 SLO 会带来巨大的成本和运营开销，并且可能会降低您的整体可靠性。 请仔细考虑备用路径可能在关键路径上的其他组件中引入的 权衡 和潜在问题。 即使不可用的影响很大，复杂性也可能超过好处。

一种方法是使用备用服务定义辅助路径，该路径仅在 Azure Front Door 不可用时变为活动状态。 不应将与 Azure Front Door 的功能奇偶校验视为硬性要求。 优先考虑业务连续性绝对需要的功能，即使可能在有限的容量下运行。

本文介绍在 Azure Front Door 不可用的情况下使用 Azure 流量管理器作为备用路由器进行全局路由的一些策略。

方法

此架构图显示了具有多个冗余流量路径的通用方法。

显示流量管理器将请求定向到 Azure Front Door 或其他服务，然后定向到源服务器的图表。

通过这种方法，我们将介绍几个组件并提供指导，这些组件将对您的 Web 应用程序的交付进行重大更改：

  1. Azure 流量管理器 将流量定向到 Azure Front Door 或你选择的备用服务。

    Azure 流量管理器是基于 DNS 的全局负载均衡器。 域的 CNAME 记录指向流量管理器，流量管理器根据你配置其 路由方法的方式确定目标。 默认情况下，使用 优先级路由 将使流量流经 Azure Front Door。 如果 Azure Front Door 不可用，流量管理器可以自动将流量切换到备用路径。

    重要

    此解决方案可缓解与 Azure Front Door 或其他提供商中断相关的风险，但它容易受到 Azure 流量管理器中断的影响，这是全局故障点。 有关详细信息，请参阅 Azure 流量管理器的可用性。

    您还可以考虑使用不同的全局流量路由系统，例如全局负载均衡器。 但是，Traffic Manager 适用于许多情况。

  2. 您有两个入口路径：

    • Azure Front Door 提供主要路径，并处理和路由所有应用程序流量。

    • 另一个路由器用作 Azure Front Door 的备份。 如果 Front Door 不可用，则流量仅流经此辅助路径。

    您为辅助路由器选择的特定服务取决于许多因素。 您可以选择使用 Azure 原生服务或第三方服务。 在这些文章中，我们尽可能提供 Azure 原生选项，以避免增加解决方案的额外作复杂性。 如果您使用第三方服务，则需要使用多个 Control Plane 来管理您的解决方案。

  3. 您的源应用程序服务器需要准备好接受来自任一服务的流量。 考虑如何 保护流向源的流量，以及 Azure Front Door 和其他上游服务提供的责任。 确保您的应用程序可以处理来自流量流经的任何路径的流量。

权衡

虽然此缓解策略可以使应用程序在平台中断期间可用，但存在一些重大权衡。 您应该权衡潜在收益与已知成本，并就这些收益是否值得这些成本做出明智的决定。

  • 财务成本：当您为应用程序部署多个冗余路径时，您需要考虑部署和运行资源的成本。 我们为不同的使用案例提供了两个示例场景，每个场景都有不同的成本配置文件。

  • 作复杂性：每次向解决方案添加其他组件时，都会增加管理开销。 对一个组件的任何更改都可能会影响其他组件。

    假设你决定使用 Azure Front Door 的新功能。 您需要检查备用流量路径是否也提供等效功能，如果没有，则需要决定如何处理两个流量路径之间的行为差异。 在实际应用程序中，这些复杂性可能具有很高的成本，并且可能会对系统的稳定性构成重大风险。

  • 性能：此设计在名称解析期间需要额外的 CNAME 查找。 在大多数应用程序中，这不是一个重大问题，但您应该评估在入口路径中引入其他层是否会影响您的应用程序性能。

  • 机会成本： 设计和实现冗余入口路径需要大量的工程投资，这最终会带来功能开发和其他平台改进的机会成本。

警告

如果您在设计和实施复杂的高可用性解决方案时不小心，您实际上可能会使您的可用性变得更糟。 增加体系结构中的组件数量会增加故障点的数量。 这也意味着您的作复杂性更高。 当您添加额外的组件时，您所做的每项更改都需要仔细检查，以了解它如何影响您的整体解决方案。

Azure 流量管理器的可用性

Azure 流量管理器是一项可靠的服务，具有 行业领先的 SLA，但没有流量管理服务可以保证 100% 的可用性。 如果流量管理器不可用，即使 Azure Front Door 和备用服务都可用，用户也可能无法访问你的应用程序。 规划解决方案在这些情况下将如何继续运行非常重要。

流量管理器返回可缓存的 DNS 响应。 如果 DNS 记录上的生存时间 （TTL） 允许缓存，则流量管理器的短暂中断可能不是问题。 这是因为下游 DNS 解析器可能已缓存以前的响应。 您应该为长时间的中断做好准备。 如果流量管理器不可用，可以选择手动重新配置 DNS 服务器，以将用户定向到 Azure Front Door。

流量路由一致性

如果您还要使用其他服务，请务必了解您使用和依赖的 Azure Front Door 功能和特性。 当您选择备用服务时，请确定您需要的最低功能，并在您的解决方案处于降级模式时省略其他功能。

在规划替代流量路径时，您应该考虑以下一些关键问题：

  • 是否使用 Azure Front Door 的缓存功能？ 如果缓存不可用，您的源服务器能否跟上您的流量？
  • 您是否使用 Azure Front Door 规则引擎来执行自定义路由逻辑或重写请求？
  • 是否使用 Azure Front Door Web 应用程序防火墙 （WAF） 来保护应用程序？
  • 您是否根据 IP 地址或地理位置限制流量？
  • 谁颁发和管理您的 TLS 证书？
  • 如何限制对源应用程序服务器的访问以确保它通过 Azure Front Door？ 你是使用专用链接，还是依赖于带有服务标记和标识符标头的公有 IP 地址？
  • 应用程序服务器是否接受来自 Azure Front Door 以外的任何位置的流量？ 如果他们接受，他们接受哪些协议？
  • 你的客户端是否使用 Azure Front Door 的 HTTP/2 支持？

Web 应用程序防火墙 (WAF)

如果使用 Azure Front Door 的 WAF 来保护应用程序，请考虑如果流量未通过 Azure Front Door 会发生什么情况。

如果您的备用路径还提供 WAF，请考虑以下问题：

  • 是否可以以与 Azure Front Door WAF 相同的方式进行配置？
  • 是否需要独立调整和测试它，以降低误报检测的可能性？

警告

您可以选择不将 WAF 用于备用入口路径。 可以认为这种方法支持应用程序的可靠性目标。 但是，这不是一个好的安全做法，我们不建议这样做。

考虑在没有任何检查的情况下接受来自 Internet 的流量的权衡。 如果攻击者发现应用程序的未受保护的辅助流量路径，则即使主路径包含 WAF，他们也可能会通过您的辅助路径发送恶意流量。

最好保护到应用程序服务器 的所有路径 。

高可用性的其他注意事项

在设计任务关键型 Web 体系结构时，有许多因素会影响应用程序的可用性和性能。 其中许多因素超出了 Azure Front Door 配置和功能，而是与整个生态系统和解决方案设计有关。

域名和 DNS

您的任务关键型应用程序应使用自定义域名。 您将控制流量流向应用程序的方式，并减少对单个提供商的依赖。

为域名使用高质量且可复原的 DNS 服务也是一种很好的做法，例如 Azure DNS。 如果您域名的 DNS 服务器不可用，则用户无法访问您的服务。

建议您使用多个 DNS 解析器，以进一步提高整体弹性。

CNAME 链接

将流量管理器、Azure Front Door 和其他服务组合在一起的解决方案使用多层 DNS CNAME 解析过程，也称为 CNAME 链接。 例如，当您解析自己的自定义域时，您可能会在返回 IP 地址之前看到 5 个或更多 CNAME 记录。

向 CNAME 链添加其他链接可能会影响 DNS 名称解析性能。 但是，通常会缓存 DNS 响应，这会降低对性能的影响。

TLS 证书

对于任务关键型应用程序，建议预配并使用自己的 TLS 证书，而不是 Azure Front Door 提供的托管证书。 您将减少此复杂体系结构的潜在问题数量。

以下是一些好处：

  • 为了颁发和续订托管 TLS 证书，Azure Front Door 会验证您对域的所有权。 域验证过程假定域的 CNAME 记录直接指向 Azure Front Door。 但是，这种假设往往是不正确的。 在 Azure Front Door 上颁发和续订托管 TLS 证书可能无法顺利工作，并且会增加因 TLS 证书问题而中断的风险。

  • 即使您的其他服务提供托管式 TLS 证书，它们也可能无法验证域所有权。

  • 如果每个服务独立获取自己的托管 TLS 证书，则可能会出现问题。 例如，用户可能不希望看到由不同颁发机构颁发的不同 TLS 证书，或者具有不同的到期日期或指纹。

但是，在证书过期之前，将有与续订和更新证书相关的其他作。

源站安全性

将 源配置为 仅接受通过 Azure Front Door 的流量时，可以抵御第 3 层和第 4 层 DDoS 攻击。 Azure Front Door 仅响应有效的 HTTP 流量，这也有助于减少你面临许多基于协议的威胁。 如果您更改架构以允许备用入口路径，则需要评估您是否意外增加了源的威胁风险。

如果使用专用链接从 Azure Front Door 连接到源服务器，流量如何流经备用路径？ 您可以使用私有 IP 地址访问源，还是必须使用公有 IP 地址？

如果源使用 Azure Front Door 服务标记和 X-Azure-FDID 标头来验证流量是否已流经 Azure Front Door，请考虑如何重新配置源以验证流量是否已流经任一有效路径。 必须测试是否未意外打开源，以便通过其他路径（包括来自其他客户的 Azure Front Door 配置文件）传输流量。

在规划源安全性时，请检查备用流量路径是否依赖于预置专用公有 IP 地址。 这可能需要一个手动触发的进程才能使备份路径联机。

如果有专用的公共 IP 地址，请考虑是否应实施 Azure DDoS 防护 ，以降低针对源的拒绝服务攻击的风险。 此外，请考虑是否需要实施 Azure 防火墙 或其他能够保护你免受各种网络威胁的防火墙。 您可能还需要更多的入侵检测策略。 这些控制在更复杂的多路径架构中可能是重要的元素。

健康建模

任务关键型设计方法需要一个系统 运行状况模型 ，该模型为您提供解决方案及其组件的整体可观察性。 当您使用多个流量入口路径时，您需要监控每个路径的运行状况。 如果您的流量被重新路由到辅助入口路径，您的运行状况模型应反映系统仍在运行，但以降级状态运行的事实。

在运行状况模型设计中包括以下问题：

  • 解决方案的不同组件如何监视下游组件的运行状况？
  • 运行状况监控器何时应将下游组件视为运行状况不佳？
  • 检测到中断需要多长时间？
  • 检测到中断后，需要多长时间才能通过备用路径路由流量？

有多个全局负载均衡解决方案，可用于监视 Azure Front Door 的运行状况，并在发生中断时触发到备份平台的自动故障转移。 Azure 流量管理器适用于大多数情况。 使用 Traffic Manager，您可以配置 终端节点监控 以监控下游服务，方法是指定要检查的 URL、检查该 URL 的频率以及何时根据探测响应将下游服务视为运行状况不佳。 通常，检查之间的间隔越短，流量管理器通过备用路径将流量定向到源服务器所需的时间就越短。

如果 Azure Front Door 不可用，则多个因素会影响中断影响流量的时间量，包括：

  • DNS 记录的生存时间 （TTL）。
  • 流量管理器运行其运行状况检查的频率。
  • 流量管理器配置为在重新路由流量之前查看的失败探测数。
  • 客户端和上游 DNS 服务器缓存 Traffic Manager 的 DNS 响应的时间。

您还需要确定哪些因素在您的控制范围内，以及您无法控制的上游服务是否会影响用户体验。 例如，即使您在 DNS 记录上使用低 TTL，上游 DNS 缓存提供过时响应的时间可能仍会超过应有的时间。 此行为可能会加剧中断的影响，或使应用程序看起来不可用，即使流量管理器已切换到向备用流量路径发送请求也是如此。

小窍门

任务关键型解决方案需要尽可能采用自动故障转移方法。 手动故障转移过程被视为缓慢，以便应用程序保持响应。

请参阅： 任务关键型设计领域：运行状况建模

零停机时间部署

在规划如何作具有冗余入口路径的解决方案时，还应规划在服务降级时如何部署或配置服务。 对于大多数 Azure 服务，SLA 适用于服务本身的运行时间，而不是管理作或部署。 考虑是否需要使您的部署和配置过程能够灵活应对服务中断。

您还应该考虑管理解决方案需要与之交互的独立控制平面的数量。 使用 Azure 服务时，Azure Resource Manager 提供统一一致的控制平面。 但是，如果您使用第三方服务来路由流量，则可能需要使用单独的控制平面来配置服务，这会进一步增加作复杂性。

警告

使用多个控制平面会给您的解决方案带来复杂性和风险。 每个差异点都会增加某人意外错过配置设置或将不同配置应用于冗余组件的可能性。 确保您的作程序降低此风险。

请参阅： 任务关键型设计领域：零停机时间部署

持续验证

对于任务关键型解决方案，您的测试实践需要验证您的解决方案是否满足您的要求，而不管您的应用程序流量流经的路径如何。 考虑解决方案的每个部分，以及如何针对每种类型的中断对其进行测试。

确保您的测试过程包括以下元素：

  • 当主路径不可用时，您能否验证流量是否通过备用路径正确重定向？
  • 两条路径能否支持您期望接收的生产流量级别？
  • 这两条路径是否都得到充分保护，以避免在处于降级状态时打开或暴露漏洞？

请参阅： 任务关键型设计领域：持续验证

常见应用场景

以下是可以使用此设计的常见方案：

  • 全球内容交付 通常适用于静态内容交付、媒体和大规模电子商务应用程序。 在这种情况下，缓存是解决方案体系结构的关键部分，缓存失败可能会导致性能或可靠性显著下降。

  • 全局 HTTP 入口 通常适用于任务关键型动态应用程序和 API。 在这种情况下，核心要求是可靠且高效地将流量路由到源服务器。 通常，WAF 是这些解决方案中使用的重要安全控制措施。

警告

如果您在设计和实施复杂的多入口解决方案时不小心，您实际上可能会使您的可用性变得更糟。 增加体系结构中的组件数量会增加故障点的数量。 这也意味着您的作复杂性更高。 当您添加额外的组件时，您所做的每项更改都需要仔细检查，以了解它如何影响您的整体解决方案。

供稿人

本文由Microsoft维护。 它最初是由以下贡献者撰写的。

主要作者：

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

查看 全局 HTTP 入口 和 全局内容交付 方案，了解它们是否适用于您的解决方案。