任务关键型应用程序需要保持较高的运行时间，即使网络组件不可用或降级也是如此。 设计 Web 流量入口、路由和安全性时，可以考虑组合多个 Azure 服务以实现更高级别的可用性，并避免出现单一故障点。
Microsoft 为 Azure Front Door 提供行业领先的服务级别协议（SLA）。 即使其他提供商提供 100% 运行时间 SLA，请务必注意，这并不能保证零故障时间，并且 SLA 通常会在发生中断时提供服务信用额度。 因此，即使是Microsoft的竞争对手也建议对任务关键型工作负荷使用多个入口路径。
如果决定采用此方法，则需要为应用程序服务器实现单独的网络路径，并且需要单独配置和测试每个路径。 必须仔细考虑此方法的全部含义。
本文介绍通过 Azure Front Door 和 Azure 应用程序网关支持全球 HTTP 流量入口的方法。 如果解决方案需要，此方法可能符合你的需求：
- 用于全局流量路由的 Azure Front Door。 这可能意味着在单独的 Azure 区域中有多个应用程序的实例，或者从单个区域为所有全局用户提供服务。
- 用于保护应用程序的 Web 应用程序防火墙（WAF），无论流量遵循的路径如何到达源服务器。
网络边缘的缓存并不是应用程序交付的关键部分。 如果缓存很重要，请参阅 任务关键型全局内容交付 以获取替代方法。
注释
此用例是总体设计策略的一部分，涵盖 Azure Front Door 不可用时的备用方法。 有关上下文和注意事项的信息，请参阅 任务关键型全局 Web 应用程序。
方法
此基于 DNS 的负载均衡解决方案使用多个 Azure 流量管理器配置文件。 在 Azure Front Door 极不可能发生可用性问题的情况下，Azure Traffic Manager 会通过应用程序网关重定向流量。
该解决方案包括以下组件：
使用优先级路由模式的流量管理器 有两 个终结点。 默认情况下，流量管理器通过 Azure Front Door 发送请求。 如果 Azure Front Door 不可用，第二个流量管理器配置文件将确定请求的定向位置。 下面介绍了第二个配置文件。
Azure Front Door 处理和路由大部分应用程序流量。 Azure Front Door 将流量路由到适当的源应用程序服务器，并提供应用程序的主要路径。 Azure Front Door 的 WAF 可保护应用程序免受常见安全威胁。 如果 Azure Front Door 不可用，流量会自动通过辅助路径重定向。
使用性能路由模式的流量管理器 具有每个应用程序网关实例的终结点。 此流量管理器从客户端位置以最佳性能将请求发送到应用程序网关实例。
应用程序网关 部署到每个区域，并将流量发送到该区域内的源服务器。 应用程序网关的 WAF 可保护流经辅助路径的任何流量。
源应用程序服务器 需要随时接受来自 Azure Front Door 和 Azure 应用程序网关的流量。
注意事项
以下部分介绍此类体系结构的一些重要注意事项。 在任务关键型解决方案中使用 Azure Front Door 时，还应查看 任务关键型全局 Web 应用程序 的其他重要注意事项和权衡。
流量管理器配置
此方法使用嵌套流量管理器配置文件，结合基于优先级和基于性能的路由，为您的应用程序提供备用的流量路径。 在起源于单个区域的简单场景中，您可能只需要一个配置为使用基于优先级路由的流量管理器配置文件。
区域分布
Azure Front Door 是一项全局服务，而应用程序网关是区域服务。
Azure Front Door 的接入点全局部署，TCP 和 TLS 连接 在与客户端最接近的状态点终止。 此行为可提高应用程序的性能。 相比之下，当客户端连接到应用程序网关时，其 TCP 和 TLS 连接在接收请求的应用程序网关处终止，而不考虑流量的来源。
来自客户端的连接
作为全球多租户服务，Azure Front Door 提供针对各种威胁的固有保护。 Azure Front Door 仅接受有效的 HTTP 和 HTTPS 流量，并且不接受其他协议上的流量。 Microsoft管理 Azure Front Door 用于其入站连接的公共 IP 地址。 由于这些特征，Azure Front Door 可以帮助 保护源免受各种攻击类型的攻击，并且源可配置 为使用专用链接连接。
相比之下，应用程序网关是具有专用公共 IP 地址的面向 Internet 的服务。 必须保护网络和源服务器免受各种攻击类型的攻击。 有关详细信息，请参阅源安全性。
到源服务器的专用链接连接
Azure Front Door Premium 提供到源的专用链接连接，从而减少解决方案面向 Internet 的公共外围应用。
如果使用专用链接连接到源，请考虑将专用终结点部署到虚拟网络，并将应用程序网关配置为将专用终结点用作应用程序的后端。
扩展
部署应用程序网关时，会自动部署专用计算资源以支持应用程序网关实例的作。 如果大量流量意外到达应用程序网关，可能会发现性能或可靠性问题。
若要缓解此风险，请考虑如何 缩放应用程序网关实例。 使用自动缩放，或者确保已手动缩放它，以处理故障转移后可能收到的流量。
高速缓存
如果使用 Azure Front Door 的缓存功能，请务必注意，流量切换到备用路径并使用应用程序网关后，不再从 Azure Front Door 缓存提供内容。
如果您的解决方案依赖于缓存，请参阅 任务关键型全局内容分发 ，以查看使用备用内容分发网络（CDN）作为对 Azure Front Door 的后备的替代方法。
或者，如果使用缓存，但它不是应用程序交付策略的重要组成部分，请考虑是否可以横向扩展或纵向扩展源，以应对由于故障转移期间缓存未命中次数增加而导致的负载增加。
权衡
如果希望备用流量路径使用请求处理规则、WAF 和 TLS 卸载等功能，则这种类型的体系结构最有用。 Azure Front Door 和应用程序网关都提供类似的功能。
但是，有利弊：
操作复杂性。 使用其中任何一项功能时，需要在 Azure Front Door 和应用程序网关上配置这些功能。 例如，如果对 Azure Front Door WAF 进行配置更改，则还需要对应用程序网关 WAF 应用相同的配置更改。 需要重新配置和测试两个单独的系统时，操作复杂性会高得多。
功能对等。 虽然 Azure Front Door 和 Application Gateway 提供的功能有相似之处，但许多功能并不是完全相同。 请注意这些差异，因为它们可能会影响根据应用程序遵循的流量路径传递应用程序的方式。
应用程序网关不提供缓存。 有关此差异的详细信息，请参阅 缓存。
Azure Front Door 和应用程序网关是不同的产品，具有不同的用例。 具体而言， 这两种产品在部署到 Azure 区域的方式上有所不同。 确保了解每个产品的详细信息以及如何使用它们。
成本。 通常需要将应用程序网关实例部署到具有源的每个区域。 由于每个应用网关实例单独计费，因此当您将源位置部署到多个区域时，成本可能会变得很高。
如果成本是解决方案的一个重要因素，请参阅 任务关键型全局内容交付 ，了解使用替代内容分发网络（CDN）作为回退到 Azure Front Door 的替代方法。 某些 CDN 按消耗量计费，因此这种方法可能更具成本效益。 但是，可能会失去将应用程序网关用于解决方案的一些其他优势。
或者，可以考虑部署另一种体系结构，其中流量管理器可以将流量直接路由到平台即服务（PaaS）应用程序服务，从而避免需要应用程序网关并降低成本。 如果对解决方案使用 Azure 应用服务或 Azure 容器应用等服务，则可以考虑此方法。 但是，如果遵循此方法，需要考虑几个重要的权衡：
- WAF： Azure Front Door 和应用程序网关都提供 WAF 功能。 如果直接向 Internet 公开应用程序服务，则可能无法使用 WAF 保护应用程序。
- TLS 卸载： Azure Front Door 和应用程序网关都终止了 TLS 连接。 需要将应用程序服务配置为终止 TLS 连接。
- 路由： Azure Front Door 和应用程序网关都跨多个源或后端执行路由，包括基于路径的路由，并支持复杂的路由规则。 如果应用程序服务直接向 Internet 公开，则无法执行流量路由。
警告
如果考虑将应用程序直接公开到 Internet，请创建彻底的威胁模型，并确保体系结构满足安全、性能和复原要求。
如果使用虚拟机来托管解决方案，则不应向 Internet 公开虚拟机。
供稿人
本文由Microsoft维护。 它最初是由以下贡献者撰写的。
主要作者：
- 戴夫·伯克哈特 |Azure Front Door 的主要项目经理
- John Downs | 首席软件工程师
- Priyanka Wilkins | 首席内容开发人员
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
查看 全局内容分发 方案，了解它是否适用于解决方案。