Azure Front Door 是一个全局负载均衡器和内容分发网络（CDN），用于路由 HTTP 和 HTTPS 流量。 Azure Front Door 提供并分发离应用程序用户最近的流量。
本文假设作为架构师，你已查看了 负载均衡选项 并选择了 Azure Front Door 作为工作负荷的负载均衡器。 它还假定应用程序部署到主动-主动或主动-被动模型中的多个区域。 本文中的指南提供了与 Azure Well-Architected 框架支柱原则相对应的架构建议。
重要
如何使用本指南
每个部分都有一个 设计清单，其中显示了关注的体系结构区域和设计策略，这些策略已本地化为技术范围。
本文还包括关于帮助实现这些策略的技术能力的建议。 这些建议并不表示可用于 Azure Front Door 及其依赖项的所有配置的详尽列表。 然而，它们列出了映射到设计视角的关键建议。 使用建议生成概念证明或优化现有环境。
演示关键建议的基础体系结构：任务关键型基线体系结构，使用网络控制。
技术范围
此次审查重点分析以下 Azure 资源的相关决策：
- Azure Front Door（Azure 前端门）
可靠性
可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。
可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。
设计清单
根据可靠性设计评审核对清单开始实施您的设计策略。 在考虑各级别及 CDN 功能的同时，评估其与业务需求的相关性。 扩展策略以根据需要包含更多方法。
选择部署策略。 基本部署方法是 主动-主动 和 主动-被动。 主动-主动部署是指运行工作负荷的多个环境或标记为流量提供服务。 主动-被动部署意味着只有主要区域处理所有流量，但在必要时会切换到次要区域。 在多区域部署中，标记或应用程序实例在不同区域运行，通过全局负载均衡器（如 Azure Front Door）来分配流量，以提高可用性。 因此，为适当的部署方法配置负载均衡器非常重要。
Azure Front Door 支持多种路由方法，可以将这些方法配置为在主动-主动或主动-被动模型中分配流量。
上述模型有许多变体。 例如，可以使用热备用来部署主动-被动模型。 在这种情况下，辅助托管服务会以最小的计算和数据规模进行部署，并在无负载的情况下运行。 在故障转移之后，计算和数据资源将被缩放，以处理来自主要区域的负载。 有关详细信息，请参阅 多区域设计的关键设计策略。
某些应用程序需要在用户会话期间保持相同的源服务器上的用户连接。 从可靠性的角度来看，我们不建议在同一源服务器上保留用户连接。 尽可能避免会话亲和性。
在每个层使用相同的主机名。 若要确保 Cookie 或重定向 URL 正常工作，请在 Web 应用程序前面使用反向代理（如 Azure Front Door）时保留原始 HTTP 主机名。
实现健康端点监控模式。 您的应用程序应该提供健康检查端点，这些端点会汇总应用程序服务请求所需的关键服务和依赖项的状态。 Azure Front Door 健康探测使用端点来检测源服务器的健康状态。 有关详细信息，请参阅 运行状况终结点监视模式。
缓存静态内容。 Azure Front Door 的内容交付功能具有数百个边缘位置，可帮助抵御流量激增和分布式拒绝服务（DDoS）攻击。 这些功能有助于提高可靠性。
考虑冗余流量管理选项。 Azure Front Door 是一种全局分布式服务，可在环境中作为单一实例运行。 Azure Front Door 是系统中潜在的单一故障点。 如果服务失败，则客户端在停机期间无法访问应用程序。
冗余实现可能非常复杂且成本高昂。 仅针对具有非常低中断容忍度的任务关键型工作负荷考虑它们。 仔细考虑权衡。
建议
| 建议 | 好处 |
|---|---|
| 选择支持部署策略的 路由方法。 基于配置的权重系数分配流量的加权方法支持主动-主动模型。 基于优先级的值，可将主要区域配置为接收所有流量，并将流量作为备份发送到次要区域支持主动-被动模型。 将上述方法与延迟敏感度配置相结合，使源的延迟最低接收流量。 |
可以使用一系列决策步骤和设计来选择最佳源资源。 所选源按指定的权重比率在允许的延迟范围内为流量提供服务。 |
| 通过在一个或多个源组中设置多个源来支持冗余。 始终具有应用程序的冗余实例，并确保每个实例公开源。 可以将这些源放置在一个或多个源组中。 |
多个源通过跨应用程序的多个实例分配流量来支持冗余。 如果一个实例不可用，则其他源仍可以接收流量。 |
| 在源上设置运行状况探测。 将 Azure Front Door 配置为执行运行状况检查，以确定源实例是否可用，并准备好继续接收请求。 有关详细信息，请参阅有关运行状况探测的最佳做法。 |
启用的健康探测是健康监控方法实现的一部分。 运行状况探测可确保 Azure Front Door 只将流量路由到运行状况足以处理请求的实例。 |
| 设置向源转发请求的超时时间，避免请求长时间运行。 根据终结点的需要调整超时设置。 否则，Azure Front Door 可能会在源发送响应之前关闭连接。 如果所有源的超时时间较短，还可以降低 Azure Front Door 的默认超时。 有关详细信息，请参阅排除无响应请求的故障。 |
长时间运行的请求消耗系统资源。 超时可终止完成时间超过预期的请求，从而防止出现性能问题和可用性问题。 |
| 在 Azure Front Door 和源上使用相同的主机名。 Azure Front Door 可以重写传入请求的主机标头，这在有多个路由到一个源的自定义域名时很有用。 但是，重写主机标头可能会导致请求 Cookie 和 URL 重定向出现问题。 有关详细信息，请参阅[保留原始 HTTP 主机名](/azure/architecture/best-practices/host-name-preservation)，该文档讨论了反向代理及其源 Web 应用程序之间的主机名保留。 |
设置相同的主机名以防止会话相关性、身份验证和授权故障。 |
| 确定应用程序是否需要会话亲和性。 如果对可靠性要求较高，建议禁用会话亲和性。 | 通过会话亲和性，用户连接在用户会话期间就会保持在同一个源上。 在某些情况下，单个源可能会因请求而过载，而其他源处于空闲状态。 如果该源变得不可用，则用户体验可能会中断。 |
| 利用 Web 应用程序防火墙（WAF）随附的 速率限制规则。 | 限制请求以防止客户端向应用程序发送过多流量。 速率限制有助于避免重试风暴等问题。 |
安全
安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。
安全设计原则 通过应用技术设计方法来限制通过 Azure Front Door 的流量，为实现这些目标提供了高级设计策略。
设计清单
根据安全性性设计评审核对清单开始实施你的设计策略。 确定漏洞和控制以提高安全态势。 扩展策略以根据需要包含更多方法。
查看 Azure Front Door 的安全基线。
保护源服务器。 Azure Front Door 是前端，是应用程序的单一入口点。
Azure Front Door 使用 Azure 专用链接访问应用程序的源。 专用链接会创建分段，以便源不需要公开公共 IP 地址和终结点。 有关详细信息，请参阅在 Azure Front Door 高级版中使用专用链接保护源。
将后端服务配置为仅接受与 Azure Front Door 外部使用的主机名相同的请求。
只有授权人员才能访问控制平面。 使用 Azure Front Door 基于角色的访问控制 (RBAC) 将访问权限仅提供给需要权限的标识。
在边缘拦截常见威胁。 WAF 与 Azure Front Door 集成。 在前端启用 WAF 规则，以保护应用程序免受网络边缘的常见攻击和漏洞的影响，使其更接近攻击源。 请考虑进行地理筛选，以按国家或地区限制对 Web 应用程序的访问。
防止意外流量。 Azure Front Door 的体系结构提供内置的 DDoS 防护 来保护应用程序终结点免受 DDoS 攻击。 如果需要公开应用程序中的其他公共 IP 地址，请考虑为这些地址添加 Azure DDoS 防护标准计划，以用于高级保护和检测功能。
还有一些 WAF 规则集可以检测机器人流量或可能是恶意的异常大量流量。
保护传输中的数据。 启用端到端传输层安全性（TLS）、HTTP 到 HTTPS 重定向以及托管 TLS 证书（如果适用）。 有关详细信息，请参阅 Azure Front Door的 TLS 最佳做法。
监控异常活动。 定期查看日志以检查攻击和误报。 将 WAF 日志从 Azure Front Door 发送到组织的集中式安全信息和事件管理（例如 Microsoft Sentinel），以检测威胁模式，并将预防措施纳入工作负荷设计。
建议
| 建议 | 好处 |
|---|---|
| 启用用于检测和阻止潜在恶意流量的 WAF 规则集。 此功能在高级层上可用。 建议使用以下规则集： - 默认 - 机器人保护 - IP 限制 - 异地筛选 - 速率限制 |
默认规则集根据 OWASP 前 10 种攻击类型和来自Microsoft威胁智能的信息频繁更新。 专门的规则集可检测某些用例。 例如，机器人规则根据客户端 IP 地址将机器人分类为好、坏或未知。 它们还会阻止错误的机器人和已知的 IP 地址，并根据呼叫者的地理位置限制流量。 通过结合使用规则集，可以检测和阻止具有不同目的的攻击。 |
| 为托管规则集创建排除项。 在检测模式下测试 WAF 策略几周，并在部署前调整任何误报。 |
减少误报，并允许对应用程序的合法请求。 |
| 将 主机标头 发送到源。 | 后端服务应注意主机名，以便他们可以创建规则以仅接受来自该主机的流量。 |
保护从 Azure Front Door 到源的连接。 启用到支持的源的专用链接连接。 如果源不支持专用链接连接，请使用服务标记和 X-Azure-FDID 标头来验证请求的源是否为 Azure Front Door 配置文件。 |
确保所有流量都流经 Azure Front Door，并获取安全优势，例如 DDoS 保护和 WAF 检查。 |
| 启用端到端 TLS、HTTP 到 HTTPS 重定向以及托管 TLS 证书（如果适用）。 查看 Azure Front Door 的TLS 最佳做法。 将 TLS 版本 1.2 用作与应用程序相关的密码的最低允许版本。 Azure Front Door 托管证书应该是您的默认选择，以方便操作。 但是，如果要管理证书的生命周期，请在 Azure Front Door 自定义域中使用自己的证书 终结点，并将其存储在 Key Vault 中。 |
TLS 可确保对浏览器、Azure Front Door 和源之间的数据交换进行加密以防止篡改。 Key Vault 提供托管证书支持和简单的证书续订和轮换。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。
成本优化设计原则 为实现这些目标提供高级设计策略，并在与 Azure Front Door 及其环境相关的技术设计中做出权衡。
设计清单
根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
查看服务层级和定价。 使用 定价计算器 估算 Azure Front Door 每个层的实际成本。 比较方案每一层的功能和适用性。 例如，只有高级层才支持通过专用链接连接到源。
标准 SKU 更具成本效益，适用于中等流量方案。 在高级 SKU 选项中，你支付更高的单位费率，但你可以获取安全特权和更高级的功能，例如在 WAF 和私有链接中托管的规则。 根据业务需求考虑在可靠性和安全性方面的权衡。
考虑带宽成本。 Azure Front Door 的带宽成本取决于你选择的层和数据传输的类型。 若要了解 Azure Front Door 计费的详细信息，请参阅 了解 Azure Front Door 计费。
Azure Front Door 为计费指标提供内置报表。 若要评估与带宽相关的成本，以及可以集中优化工作的位置，请参阅 Azure Front Door 报表。
优化传入请求。 Azure Front Door 对传入的请求计费。 可以在设计配置中设置限制。
通过使用例如 后端为前端 和 网关聚合等设计模式，减少请求数量。 这些模式可以提高操作的效率。
WAF 规则限制传入流量，这可以优化成本。 例如，使用速率限制来防止流量异常高，或使用地理筛选仅允许从特定区域或国家/地区进行访问。
有效使用资源。 Azure Front Door 使用一种路由方法来帮助优化资源。 除非工作负荷非常延迟敏感，否则在所有环境中均匀分配流量以有效使用已部署的资源。
Azure Front Door 终结点可以为许多文件提供服务。 降低带宽成本的一种方法是使用压缩。
将 Azure Front Door 中的缓存用于不经常更改的内容。 由于内容是从缓存中提供的，因此可以节省在将请求转发到源时产生的带宽成本。
考虑使用组织提供的共享实例。 集中式服务产生的成本在工作负荷之间共享。 但是，请考虑与可靠性之间的权衡。 对于具有高可用性要求的任务关键型应用程序，我们建议使用自治实例。
注意所记录的数据量。 如果某些请求不必要或日志记录数据长时间保留，则与带宽和存储相关的成本可能会累积。
建议
| 建议 | 好处 |
|---|---|
| 对支持缓存的终结点使用缓存。 | 缓存优化数据传输成本，因为它减少了从 Azure Front Door 实例到源的调用数。 |
| 考虑启用文件压缩。 对于此配置，应用程序必须支持压缩，并且必须启用缓存。 |
压缩可降低带宽消耗并提高性能。 |
| 在只有一个源的源组中禁用运行状况。 如果在 Azure Front Door 源组中只配置了一个源，则无需进行这些调用。 |
可以通过禁用不需要进行路由决策的运行状况检查请求来节省带宽成本。 |
卓越运营
卓越运营主要侧重于开发实践、可观测性和发布管理等过程。
卓越运营设计原则 提供了一个高级设计策略，用于实现工作负荷的操作要求目标。
设计清单
根据卓越运营设计评审清单来开始实施设计策略，以定义与 Azure Front Door 相关的可观测性、测试和部署。
使用基础结构即代码 (IaC) 技术。 使用 IaC 技术，例如 Bicep 和 Azure 资源管理器模板，来配置 Azure Front Door 实例。 这些声明性方法提供一致性和简单的维护。 例如，通过使用 IaC 技术，可以轻松采用新的规则集版本。 始终使用最新的 API 版本。
简化配置。 使用 Azure Front Door 轻松管理配置。 例如，假设体系结构支持微服务。 Azure Front Door 支持 重定向功能，因此可以使用基于路径的重定向来面向单个服务。 另一个用例是通配符域的配置。
处理渐进式曝光。 Azure Front Door 提供 多个路由方法。 对于加权负载均衡方法，可以使用 Canary 部署将特定百分比的流量发送到源。 在推出新功能之前，此方法可帮助你在受控环境中测试新功能和版本。
作为工作负荷监控的一部分收集和分析运营数据。 使用 Azure Monitor 日志捕获相关的 Azure Front Door 日志和指标。 此数据可帮助你对用户行为进行故障排除、了解和优化作。
将证书管理卸载到 Azure。 减轻因与证书轮换和续期相关的操作负担。
建议
| 建议 | 好处 |
|---|---|
| 使用 HTTP 到 HTTPS 重定向 来支持转发兼容性。 | 启用重定向后，Azure Front Door 会自动将使用旧协议的客户端引导至 HTTPS，以确保安全体验。 |
| 捕获日志和指标。 包括资源活动日志、访问日志、运行状况探测日志和 WAF 日志。 设置警报。 |
监视入口流是监视应用程序的关键部分。 你想要跟踪请求并改进性能和安全性。 需要数据来调试 Azure Front Door 配置。 使用警报，您可以立即收到任何关键操作问题的通知。 |
| 查看内置分析报告。 | 通过 WAF 指标全面查看 Azure Front Door 配置文件，有助于根据流量和安全报告来推动改进。 |
| 尽可能使用托管 TLS 证书。 | Azure Front Door 可以颁发和管理证书。 此功能无需证书续订，并最大限度地减少由于 TLS 证书无效或过期而导致服务中断的风险。 |
| 使用通配符 TLS 证书。 | 无需修改配置即可单独添加或指定每个子域。 |
性能效率
性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。
设计清单
根据性能效率设计评审清单开始设计策略。 定义基于 Azure Front Door 的关键绩效指标的基线。
通过分析预期流量模式来规划容量。 进行彻底的测试，以了解应用程序在不同负载下的表现。 考虑例如并发事务、请求速率和数据传输等因素。
根据规划选择 SKU。 标准 SKU 更具成本效益，适用于中等流量方案。 如果预计负载较高，建议使用高级 SKU。
通过定期审查性能指标来分析性能数据。 Azure Front Door 报表 提供对各种技术级别性能指标的洞察。
使用 Azure Front Door 报表设置工作负荷的实际性能目标。 考虑响应时间、吞吐量和错误率等因素。 使目标与业务需求和用户期望保持一致。
优化数据传输。
使用缓存来减少提供静态内容（如图像、样式表和 JavaScript 文件）或不经常更改的内容的延迟。
针对缓存优化应用程序。 在应用程序中使用缓存过期标头，控制客户端和代理应缓存内容的时间。 较长的缓存有效性意味着对源服务器的请求频率较低，这会导致流量减少，延迟较低。
减小通过网络传输的文件的大小。 较小的文件可加快加载时间并提高用户体验。
最大程度地减少应用程序中的后端请求数。
例如，网页显示用户配置文件、最近订单、余额和其他相关信息。 不要对每组信息发出单独的请求，而是使用设计模式来构建应用程序，以便将多个请求聚合到单个请求中。
更新客户端以使用 HTTP/2 协议，它可以将多个请求合并到单个 TCP 连接中。
使用 WebSockets 来支持实时全双工通信，而不是重复 HTTP 请求或轮询。
通过聚合请求，可以在前端和后端之间发送较少的数据，并在客户端与后端之间建立更少的连接，从而减少开销。 此外，Azure Front Door 处理的请求更少，这可以防止重载。
优化运行状况探测的使用。 仅在源的状态发生更改时，才从健康探测器获取健康信息。 在监视准确性和尽量减少不必要的流量之间取得平衡。
运行状况探测通常用于评估一个组中多个源的运行状况。 如果 Azure Front Door 源组中只配置了一个源，请禁用运行状况探测以减少源服务器上的不必要的流量。 由于只有一个实例，运行状况探测状态不会影响路由。
查看源路由方法。 Azure Front Door 提供各种路由方法，包括基于延迟、基于优先级、加权路由和基于会话相关性的路由到源。 这些方法显著影响应用程序的性能。 若要详细了解方案的最佳流量路由选项，请参阅 流量路由方法到源。
查看源服务器的位置。 源服务器的位置会影响应用程序的响应能力。 源服务器应更靠近用户。 Azure Front Door 可确保来自特定位置的用户访问最近的 Azure Front Door 入口点。 性能优势包括更快的用户体验、更好地使用 Azure Front Door 的基于延迟的路由，以及通过使用缓存将内容存储在更靠近用户的缓存中来最小化数据传输时间。
有关详细信息，请参阅按位置报告的流量。
建议
| 建议 | 好处 |
|---|---|
| 启用缓存。 可以优化 查询字符串以提升缓存效率。 对于纯静态内容，请忽略查询字符串以最大化缓存的使用。 如果应用程序使用查询字符串，请考虑将它们包含在缓存密钥中。 在缓存密钥中包含查询字符串后，Azure Front Door 可以根据配置提供缓存响应或其他响应。 |
Azure Front Door 提供可靠的内容分发网络解决方案，用于缓存网络边缘的内容。 缓存可减少源服务器上的负载，并减少跨网络的数据移动，这有助于卸载带宽使用情况。 |
| 访问可下载内容时使用文件压缩。 | Azure Front Door 中的压缩有助于以最佳格式提供内容，有效负载较小，并更快地向用户提供内容。 |
在 Azure Front Door 中配置运行状况探测时，请考虑使用 HEAD 请求而不是 GET 请求。 运行状况探测仅读取状态代码，而不是内容。 |
HEAD 请求允许你查询状态更改，而无需提取其整个内容。 |
| 评估当请求来自同一用户时，是否应启用 会话相关性以将其定向到同一源服务器。 从可靠性的角度来看，我们不建议使用此方法。 如果使用此选项，应用程序应正常恢复，而不会中断用户会话。 负载均衡也有利弊，因为它限制了跨多个源均匀分配流量的灵活性。 |
优化性能并保持用户会话的连续性，尤其是在应用程序依赖于本地维护状态信息时。 |
Azure 策略
Azure 提供了一组与 Azure Front Door 及其依赖项相关的大量内置策略。 可以通过 Azure 策略审核上述一些建议。 例如，可以检查以下情况：
- 需要高级层才能支持 Azure Front Door 配置文件中的托管 WAF 规则和专用链接。
- 需要使用最低 TLS 版本，即版本 1.2。
- 需要在 Azure Front Door Premium 与 Azure PaaS 服务之间建立安全专用连接。
- 需要启用资源日志。 WAF 应启用请求正文检查。
- 需要使用策略来强制实施 WAF 规则集。 例如，应启用机器人保护并启用速率限制规则。
为了实现全面治理，请查看 Azure 内容分发网络 和其他 Azure Front Door 策略的 内置定义，这些定义列在 Azure Policy 内置策略定义中。
Azure 顾问建议
Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。 顾问建议与 Well-Architected 框架支柱保持一致。
有关详细信息，请参阅 Azure 顾问中的建议。
后续步骤
请将以下文章视为展示本文中所提建议的资源。
- 使用以下参考体系结构作为如何将本文指南应用于工作负荷的示例：
- 使用以下产品文档生成实施专业知识：