你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
任务关键型 Web 应用程序的全局路由冗余
任务关键型系统通过尽可能多地在解决方案中构建冗余和自我修复功能，努力最大程度地减少单一故障点。 系统的任何统一入口点都可以被视为故障点。 如果此组件出现故障，则整个系统将对用户保持脱机。 选择路由服务时，请务必考虑服务本身的可靠性。
在任务关键型应用程序的基线体系结构中，之所以选择 Azure Front Door，是因为其高运行时间服务级别协议 (SLA) 和丰富的功能集：
- 在主动-主动模型中将流量路由到多个区域
- 使用 TCP 任意广播的透明故障转移
- 使用集成的内容分发网络 (CDN) 从边缘节点提供静态内容
- 使用集成的 Web 应用程序防火墙阻止未经授权的访问
Front Door 不仅为外部客户提供最大的复原能力和可用性，而且为 Microsoft 中的多个属性提供最大的复原能力和可用性。 有关 Front Door 功能的详细信息，请参阅使用 Azure Front Door 加速和保护 Web 应用程序。
Front Door 功能足以满足大多数业务需求，但是，对于任何分布式系统都会出现故障。 如果业务要求需要更高的复合 SLO 或零停机时间，以防中断，则需要依赖于备用流量入口路径。 但是，追求更高的 SLO 会带来巨大的成本、运营开销，并且可能会降低整体可靠性。 请仔细考虑权衡和备用路径可能会在关键路径上的其他组件中引入的潜在问题。 即使不可用性的影响很大，复杂性也可能超过好处。
一种方法是使用备用服务定义辅助路径，该路径仅在 Azure Front Door 不可用时变为活动状态。 不应将与 Front Door 的功能奇偶校验视为硬性要求。 优先考虑出于业务连续性目的而绝对需要的功能，它们甚至可能以有限的容量运行。
另一种方法是使用第三方技术进行全局路由。 此方法需要多云主动-主动部署，并在两个或多个云提供商之间托管标记。 尽管 Azure 可以有效地与其他云平台集成，但不建议使用此方法，因为不同云平台的操作非常复杂。
本文介绍在 Azure Front Door 不可用的情况下，使用 Azure 流量管理器作为备用路由器进行全局路由的一些策略。
方法
此体系结构图显示了具有多个冗余流量路径的常规方法。
通过此方法，我们将引入多个组件并提供指导，这些组件将执行与 Web 应用程序的交付相关联的重大更改：
Azure 流量管理器将流量定向到 Azure Front Door 或所选的备用服务。
Azure 流量管理器是基于 DNS 的全局负载均衡器。 域的 CNAME 记录指向流量管理器，流量管理器根据配置路由方法的方式确定目标。 默认情况下，使用优先级路由将使流量流经 Azure Front Door。 如果 Azure Front Door 不可用，流量管理器可以自动将流量切换到备用路径。
重要
此解决方案可缓解与 Azure Front Door 中断相关的风险，但作为全局故障点，它容易受到 Azure 流量管理器中断的影响。
还可以考虑使用不同的全局流量路由系统，例如全局负载均衡器。 但是，流量管理器适用于许多情况。
你有两个入口路径：
Azure Front Door 提供主路径、进程，并路由所有应用程序流量。
另一个路由器用作 Azure Front Door 的备份。 如果 Front Door 不可用，则流量仅流经此辅助路径。
为辅助路由器选择的特定服务取决于许多因素。 可以选择使用 Azure 本机服务或第三方服务。 在这些文章中，我们提供了 Azure 本机选项，以避免额外增加解决方案的操作复杂性。 如果使用第三方服务，则需要使用多个控制平面来管理解决方案。
源应用程序服务器需要准备好接受来自任一服务的流量。 考虑如何保护到源的流量，以及 Front Door 和其他上游服务提供哪些责任。 确保应用程序可以处理来自流量流经的路径的流量。
权衡
虽然此缓解策略可以使应用程序在平台中断期间可用，但需要做出一些重大权衡。 应权衡潜在优势与已知成本，并做出明智的决定，确定这些权益是否值得这些成本。
财务成本：将多个冗余路径部署到应用程序时，需要考虑部署和运行资源的成本。 我们针对不同的用例提供了两个示例方案，每个用例都有不同的成本配置文件。
操作复杂性：每次向解决方案添加其他组件时，都会增加管理开销。 对一个组件的任何更改都可能会影响其他组件。
假设你决定使用 Azure Front Door 的新功能。 需要检查备用流量路径是否也提供等效功能，如果没有，则需要决定如何处理两个流量路径之间的行为差异。 在实际应用中，这些复杂性可能具有较高的成本，并且可能会对系统的稳定性产生重大风险。
性能：此设计需要在名称解析期间进行其他 CNAME 查找。 在大多数应用程序中，这不是一个重大问题，但你应该评估应用程序性能是否因在入口路径中引入其他层而受到影响。
机会成本：设计和实施冗余入口路径需要大量工程投资，这最终会以功能开发和其他平台改进的机会成本为代价。
警告
如果你在设计和实施复杂的高可用性解决方案时不小心，实际上可能会使可用性变差。 增加体系结构中的组件数会增加故障点数。 这也意味着操作复杂性更高。 添加额外的组件时，需要仔细查看所做的每一项更改，以了解它如何影响整体解决方案。
Azure 流量管理器的可用性
Azure 流量管理器是一项可靠的服务，但服务级别协议不保证 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，他们也可能通过辅助路径发送恶意流量。
最好保护应用程序服务器的所有路径。
域名和 DNS
任务关键型应用程序应使用自定义域名。 你将控制流量如何流向应用程序，并减少对单个提供程序的依赖。
也最好对域名使用高质量且可复原的 DNS 服务，例如 Azure DNS。 如果域名的 DNS 服务器不可用，则用户无法访问你的服务。
建议使用多个 DNS 解析程序来进一步提高整体复原能力。
CNAME 链接
将流量管理器、Azure Front Door 和其他服务相结合的解决方案使用多层 DNS CNAME 解析过程，也称为 CNAME 链接。 例如，解析自己的自定义域时，你可能会在返回 IP 地址之前看到五条或五条以上的 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 证书，也不希望看到具有不同到期日期或指纹的 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 流量管理器在大多数情况下都适用。 使用流量管理器，可以通过指定要检查的 URL、检查该 URL 的频率以及何时根据探测响应将下游服务视为不正常，来配置终结点监视以监视下游服务。 通常，检查间隔越短，流量管理器通过备用路径定向流量以到达源服务器所需的时间就越少。
如果 Front Door 不可用，则多种因素会影响中断影响流量的时间，包括：
- DNS 记录上的生存时间 (TTL)。
- 流量管理器运行其运行状况检查的频率。
- 流量管理器在重新路由流量之前配置为查看的失败探测数。
- 客户端和上游 DNS 服务器缓存流量管理器的 DNS 响应的时长。
你还需要确定其中哪些因素在你的控制范围内，以及超出你的控制范围的上游服务是否可能会影响用户体验。 例如，即使对 DNS 记录使用低 TTL，上游 DNS 缓存仍可能提供过时响应的时间比它们应该提供的时间更长。 此行为可能会加剧中断的影响，或者使应用程序看起来不可用，即使流量管理器已切换到将请求发送到备用流量路径也是如此。
提示
任务关键型解决方案要求尽可能采用自动故障转移方法。 手动故障切换过程被认为是缓慢的，以便应用程序保持响应。
请参阅：任务关键型设计领域：运行状况建模
零停机部署
在计划如何使用冗余入口路径操作解决方案时，还应规划在服务降级时如何部署或配置服务。 对于大多数 Azure 服务，SLA 适用于服务本身的运行时间，而不是管理操作或部署。 考虑是否需要使部署和配置过程能够应对服务中断。
还应考虑需要与之交互以管理解决方案的独立控制平面的数量。 使用 Azure 服务时，Azure 资源管理器提供统一且一致的控制平面。 但是，如果使用第三方服务来路由流量，则可能需要使用单独的控制平面来配置服务，这会带来进一步的操作复杂性。
警告
使用多个控制平面会给解决方案带来复杂性和风险。 每个差异点都会增加某人意外错过配置设置或将不同配置应用于冗余组件的可能性。 确保操作过程可缓解此风险。
持续验证
对于任务关键型解决方案，无论应用程序流量流经的路径如何，测试实践都需要验证解决方案是否满足要求。 考虑解决方案的每个部分，以及如何针对每种中断类型对其进行测试。
确保测试过程包含以下元素：
- 当主路径不可用时，能否验证流量是否已正确通过备用路径重定向？
- 这两个路径是否可以支持预期接收的生产流量级别？
- 这两个路径是否都受到充分保护，以避免在处于降级状态时打开或暴露漏洞？
请参阅：任务关键型设计领域：持续验证
常见场景
下面是可以使用此设计的常见方案：
全局内容分发通常适用于静态内容分发、媒体和大规模电子商务应用程序。 在此方案中，缓存是解决方案体系结构的关键部分，缓存失败可能会导致性能或可靠性大幅下降。
全局 HTTP 入口通常适用于任务关键型动态应用程序和 API。 在此方案中，核心要求是可靠且高效地将流量路由到源服务器。 通常，WAF 是这些解决方案中使用的重要安全控件。
警告
如果你在设计和实施复杂的多入口解决方案时不小心，实际上可能会使可用性变差。 增加体系结构中的组件数会增加故障点数。 这也意味着操作复杂性更高。 添加额外的组件时，需要仔细查看所做的每一项更改，以了解它如何影响整体解决方案。
后续步骤
查看全局 HTTP 入口和全局内容分发方案，了解它们是否适用于你的解决方案。