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