本文总结了使用Azure Front Door的最佳做法。
一般最佳实践
了解何时合并流量管理器和Azure Front Door
对于大多数解决方案，我们建议使用 任一 Azure Front Door orAzure 流量管理器，但不能同时使用两者。 流量管理器是基于 DNS 的负载均衡器。 它将流量直接发送到源终结点。 相比之下，Azure Front Door 在靠近客户端的存在点（PoP）终止连接，并与源服务器之间建立单独的持久连接。 这两种产品的工作方式不同，适用于不同的用例。
如果需要内容缓存和传递、TLS 终止、高级路由功能或 Web 应用程序防火墙（WAF），请考虑使用Azure Front Door。 对于使用从客户端到终结点的直接连接进行简单的全局负载均衡，请考虑使用流量管理器。 有关选择负载均衡选项的详细信息，请参阅 负载均衡选项。
在需要高可用性的复杂架构中，您可以将流量管理器放在 Azure Front Door 前面。 如果Azure Front Door不可用，流量管理器随后可以将流量路由到备用目标，例如Azure 应用程序网关或合作伙伴内容分发网络（CDN）。
Important
不要将流量管理器置于Azure Front Door后面。 流量管理器应始终位于Azure Front Door前面。
限制发送到源的流量
当流量仅流经Azure Front Door时，Azure Front Door的功能效果最佳。 应将源配置为阻止未通过Azure Front Door发送的流量。 有关详细信息，请参阅 Secure Azure Front Door 流量发源。
使用最新的 API 版本和 SDK 版本
使用 API、Azure 资源管理器 模板、Bicep 或 Azure SDK 与 Azure Front Door 协作时，建议使用最新的可用 API 或 SDK 版本。 当新功能可用时，API 和 SDK 更新将发生，并且它们包含重要的安全修补程序和 bug 修复。
配置日志
Azure Front Door会跟踪每个请求的详细性能数据。 启用缓存时，源服务器可能不会收到每个请求。 请务必使用Azure Front Door日志来了解解决方案是如何运行和响应客户端的。
TLS 最佳做法
使用端到端 TLS
Azure Front Door从客户端终止 TCP 和 TLS 连接。 然后，它会建立从每个 PoP 到源的新连接。 最好使用 TLS 保护其中每个连接，即使对于托管在 Azure 中的源也是如此。 此方法使数据在传输过程中保持加密。
有关详细信息，请参阅
使用 HTTP 到 HTTPS 重定向
客户端最好使用 HTTPS 连接到服务。 但是，有时需要接受 HTTP 请求，以允许可能不遵循最佳做法的旧客户端或客户端。
可以将Azure Front Door配置为自动重定向 HTTP 请求以使用 HTTPS 协议。 应启用重定向所有流量以在路由上使用 HTTPS 设置。
领域最佳实践
采用自定义域
为Azure Front Door终结点采用自定义域，以确保在管理域和流量的同时获得更好的可用性和灵活性。 不要在客户端、代码库或防火墙中硬编码Azure Front Door提供的域（如 *.azurefd.z01.net）。 对此类方案使用自定义域。
在 Azure Front Door 和源上使用同一域名
Azure Front Door可以重写传入请求的 Host 标头。 管理路由到单个源的一组面向客户的自定义域名时，此功能非常有用。 当您希望避免在 Azure Front Door 和源服务器中配置自定义域名时，此功能也可以提供帮助。
但是，重写 Host 标头时，请求 Cookie 和 URL 重定向可能会中断。 具体而言，使用Azure 应用服务等平台时，session affinity 和 authentication 和 authorization 等功能可能无法正常工作。
在重写 Host 请求的标头之前，请仔细考虑应用程序是否正常工作。 有关详细信息，请参阅在反向代理及其后端 Web 应用程序之间保留原始 HTTP 主机名。
WAF 最佳做法
对于面向 Internet 的应用程序，我们建议启用 Azure Front Door WAF 并将其配置为使用托管规则。 使用 WAF 和Azure托管规则有助于保护应用程序免受各种攻击。 有关详细信息，请参阅 Azure Front Door 上的 Web 应用防火墙 (WAF)。
适用于 Azure Front Door 的 WAF 在其配置和使用方面具有一套自己的最佳实践。 有关详细信息，请参阅 Azure Front Door 中有关Web 应用程序防火墙的最佳做法。
运行状况检测的最佳实践
当源组中只有一个源时禁用运行状况探测
Azure Front Door中的健康探测可以检测源站不可用或不正常的情况。 当运行状况探测检测到源问题时，可以将Azure Front Door配置为将流量发送到源组中的另一个源。
如果只有单个源，Azure Front Door始终将流量路由到该源，即使其运行状况探测报告不正常状态。 运行状况探针的状态不会影响Azure Front Door的行为。 在此方案中，运行状况探测不提供权益，应禁用它们以减少源上的流量。
有关详细信息，请参阅 健康探测。
选择良好的终结点
请考虑您希望 Azure Front Door 的健康探测进行监控的地点。 通常最好监视专为运行状况监视设计的网页或位置。 应用程序逻辑可以考虑为生产流量提供服务所需的所有关键组件的状态，包括应用程序服务器、数据库和缓存。 这样，如果任何组件发生故障，Azure Front Door可以将流量路由到服务的另一个实例。
有关详细信息，请参阅 健康终端监控模块。
使用 HEAD 运行状况探测
运行状况探测可以使用 GET 或 HEAD HTTP 方法。 最好使用 HEAD 方法进行运行状况探测，因为它减少了源服务器上的流量负载。
有关详细信息，请参阅运行状况探测支持的 HTTP 方法。