高可用性多区域 Web 应用程序

此示例体系结构基于基本 Web 应用程序示例体系结构，并对其进行扩展以展示：

• 能够切实改进 Azure 应用服务 Web 应用程序的可伸缩性和性能的做法
• 如何在多个区域中运行 Azure 应用服务应用程序以实现高可用性

体系结构

下载此体系结构的 Visio 文件。

工作流

此工作流解决了体系结构的多区域问题，并在基本 Web 应用程序的基础上进行构建。

• 主要和次要区域。 此体系结构使用两个区域来实现更高的可用性。 应用程序部署到每个区域。 在正常运行期间，网络流量被路由到主要区域。 如果主要区域变得不可用，则流量将被路由到次要区域。
• Front Door。 对于多区域实现，建议使用 Azure Front Door 负载均衡器。 它集成了 Web 应用程序防火墙 (WAF) 以防止常见攻击，并使用 Front Door 自带的内容缓存功能。 在此体系结构中，Front Door 配置为优先路由，除非主要区域不可用，否则会将所有流量发送到主要区域。 如果主要区域不可用，Front Door 会将所有流量路由到次要区域。
• 存储帐户、SQL 数据库和/或 Azure Cosmos DB 的异地复制。

组件

用于实现此体系结构的关键技术：

• Microsoft Entra ID 是一种基于云的标识和访问管理服务，可让员工访问为你的组织开发的云应用。
• Azure DNS 是 DNS 域的托管服务，它使用 Microsoft Azure 基础结构提供名称解析。 通过在 Azure 中托管域，可以使用与其他 Azure 服务相同的凭据、API、工具和计费来管理 DNS 记录。 若要使用自定义域名（例如 contoso.com），请创建可将自定义域名映射到 IP 地址的 DNS 记录。 有关详细信息，请参阅在 Azure 应用服务中配置自定义域名。
• Azure 内容分发网络为全局解决方案，通过在世界各地按特定策略放置的物理节点缓存高带宽内容来分发该内容。
• Front Door 是第 7 层负载均衡器。 在此体系结构中，它将 HTTP 请求路由到 Web 前端。 Front Door 还提供一个 Web 应用程序防火墙 (WAF)，可在出现常见漏洞和攻击时保护应用程序。 在此设计中，Front Door 还用于内容分发网络 (CDN) 解决方案。
• Azure 应用服务是用于创建和部署云应用程序的完全托管平台。 通过它可为 Web 应用定义一组计算资源，来运行、部署 Web 应用和配置部署槽位。
• Azure 函数应用可用于运行后台任务。 Functions 由触发器（例如计时器事件或将消息置于队列中的事件）调用。 对于长时间运行的有状态任务，请使用 Durable Functions。
• Azure 存储是适用于现代数据存储场景的云存储解决方案，为云中的各种数据对象提供具有高可用性、可大规模缩放、持久且安全的存储。
• Azure Redis 缓存是一种高性能缓存服务，该服务基于开源实现 Redis 缓存提供内存中数据存储，以便更快地检索数据。
• Azure SQL 数据库是云中的关系数据库即服务。 SQL 数据库与 Microsoft SQL Server 数据库引擎共享其代码库。
• Azure Cosmos DB 是一种全球分布且完全托管的低延迟、多模型、多查询 API 数据库，用于大规模管理数据。
• Azure 认知搜索可用于添加搜索功能，例如搜索建议、模糊搜索、特定于语言的搜索。 Azure 搜索通常与其他数据存储结合使用，尤其是在主数据存储对一致性要求严格的情况下。 此方法将权威数据存储在其他数据存储中，将搜索索引存储在 Azure 搜索中。 也可使用 Azure 搜索合并来自多个数据存储的单一搜索索引。

方案详细信息

有多种常规方法可跨区域实现高可用性：

• 使用热备用的主动/被动：流量将前往一个区域，而另一个区域将以热备用模式等待。 热备用意味着次要区域中的应用服务已被分配并总是处于运行状态。

• 使用冷备用的主动/被动：流量将前往一个区域，而另一个区域将以冷备用模式等待。 “冷备用”意味着只有故障转移需要用到次要区域中的应用服务时才分配该应用服务。 此方法的运行成本较低，但是当发生故障时通常需要花费更长时间才能联机。

• 主动/主动：两个区域都处于活动状态，并且会在它们之间对请求进行负载均衡。 如果某个区域不可用，该区域将被取出轮用阵容。

此参考侧重于“主动/被动”（采用热备用模式）。

可能的用例

这些用例可以从多区域部署中受益：

• 为 LoB 应用程序设计业务连续性和灾难恢复计划。

• 部署在 Windows 或 Linux 上运行的任务关键型应用程序。

• 通过保持应用程序可用来优化用户体验。

建议

你的要求可能不同于此处描述的体系结构。 请使用本部分中的建议作为入手点。

区域配对

每个 Azure 区域都与同一地域内的另一个区域配对。 通常，请选择同一区域对中的区域（例如“美国东部 2”和“美国中部”）。 这样做的好处包括：

• 如果发生大范围的故障，会优先恢复每个区域对中的至少一个区域。
• 计划内 Azure 系统更新会按顺序提供给配对的区域，以尽可能减少停机时间。
• 在多数情况下，区域对位于同一地域内以满足数据驻留要求。

但请确保两个区域都支持应用程序所需的所有 Azure 服务。 请参阅服务（按区域）。 有关区域对的详细信息，请参阅业务连续性和灾难恢复 (BCDR)：Azure 配对区域。

资源组

考虑将主要区域、次要区域和 Front Door 放置到单独的资源组中。 此分配允许你将部署到每个区域的资源作为单个集合进行管理。

应用服务应用

建议以独立应用服务应用的形式创建 Web 应用程序和 Web API。 此设计允许你按独立的应用服务计划运行它们，以便对它们进行单独缩放。 如果一开始不需要该级别的可伸缩性，可以先将应用部署到同一计划中，再在以后根据需要将其移至独立的计划中。

Front Door 配置

路由。 Front Door 支持多种路由机制。 对于本文中所述的情况，请使用优先级路由。 使用此设置时，Front Door 将所有请求都发送到主要区域，除非该区域的终结点变得无法访问。 那时，它将自动故障转移到次要区域。 为源池设置不同的优先级值，活动区域为 1，备用或被动区域为 2 或更高。

运行状况探测。 Front Door 使用 HTTPS 探测来监视每个后端的可用性。 该探针对 Front Door 进行通过/失败测试，以便向次要区域进行故障转移。 它通过将请求发送到指定的 URL 路径来执行工作。 如果它在超时期间内收到一个非-200 响应，则探测失败。 可以配置运行状况探测频率、评估所需的样本数，以及将源标记为正常所需的成功样本数。 如果 Front Door 将源标记为“已降级”，则它将故障转移到其他源。 有关详细信息，请参阅运行状况探测。

最佳做法是在应用程序源中创建运行状况探测路径，用于报告应用程序的总体运行状况。 此运行状况探测应当检查关键依赖项，例如应用服务应用、存储队列和 SQL 数据库。 否则，探测可能会在应用程序的关键部分实际上已出现故障时报告源运行状况正常。 另一方面，请不要使用运行状况探测来检查较低优先级的服务。 例如，如果某个电子邮件服务发生故障，则应用程序可以切换到辅助提供程序或者只是稍后再发送电子邮件。 有关此设计模式的进一步讨论，请参阅运行状况终结点监视模式。

保护来自 Internet 的源是实现可公开访问的应用的关键部分。 请参阅网络安全入口实现，了解 Microsoft 建议用于保护应用与 Front Door 的入口通信的设计和实现模式。

CDN。 使用 Front Door 的本机 CDN 功能缓存静态内容。 CDN 的主要优势是降低用户的延迟，因为内容缓存在靠近用户的边缘服务器上。 CDN 还可以减轻应用程序的负载，因为相应的流量不是由应用程序处理。 Front Door 还提供动态站点加速功能，能帮助你为 Web 应用提供比仅采用静态内容缓存更好的整体用户体验。

SQL 数据库

使用活动异地复制和自动故障转移组使数据库具有复原能力。 使用活动异地复制可将数据库从主要区域复制到一个或多个（最多四个）其他区域。 自动故障转移组是基于活动异地复制构建的，可用于故障转移到辅助数据库，而无需对应用进行任何代码更改。 可以根据创建的策略定义手动或自动执行故障转移。 若要使用自动故障转移组，需要使用为故障转移组自动创建的故障转移连接字符串（而不是单个数据库的连接字符串）来配置你的连接字符串。

Azure Cosmos DB

Azure Cosmos DB 支持以主动-主动模式在多个写入区域中跨区域异地复制。 也可将一个区域指定为可写区域，将其他区域指定为只读副本。 如果发生区域性中断，可以通过选择另一个区域作为写入区域来进行故障转移。 客户端 SDK 会自动将写入请求发送到当前写入区域，因此，在故障转移后不需要更新客户端配置。 有关详细信息，请参阅使用 Azure Cosmos DB 全局分配数据。

存储

对于 Azure 存储，请使用读取访问异地冗余存储 (RA-GRS)。 使用 RA-GRS 存储时，数据被复制到次要区域。 你可以通过一个单独的终结点以只读方式访问次要区域中的数据。 异地复制的存储帐户支持用户启动的到次要区域的故障转移。 启动存储帐户故障转移会自动更新 DNS 记录，使辅助存储帐户成为新的主要存储帐户。 仅在必要时才应进行故障转移。 此要求是按贵组织的灾难恢复计划定义的，并且你应考虑以下“注意事项”部分中所述的后果。

如果发生区域性中断或灾难，则 Azure 存储团队可以决定执行到次要区域的异地故障转移。 对于这种类型的故障转移，此处不需要客户操作。 在这种情况下，到主要区域的故障回复也由 Azure 存储团队管理。

在某些情况下，块 Blob 的对象复制对于工作负载而言是足以解决需求的复制解决方案。 此复制功能允许将单个块 Blob 从主要存储帐户复制到次要区域中的存储帐户。 此方法的优势是可以精细控制所要复制的数据。 可以定义复制策略，以便更精细地控制要复制的块 Blob 类型。 策略定义的示例包括但不限于：

• 仅复制在创建策略之后添加的块 Blob
• 仅复制在给定日期和时间之后添加的块 Blob
• 仅复制与给定前缀匹配的块 Blob。

在这种情况下，将队列存储作为 Azure 服务总线的替代消息传送选项引用。 但如果将队列存储用于消息传送解决方案，则上述与异地复制相关的指南也适用，因为队列存储位于存储帐户。 但请务必知道，消息不会复制到次要区域，并且其状态与该区域密不可分。

Azure 服务总线

若要受益于 Azure 服务总线的最大复原能力，请为命名空间使用高级层。 高级层利用可用性区域，使命名空间能够灵活应对数据中心服务中断。 如果发生影响多个数据中心的大范围灾难，高级层中的异地灾难恢复功能可以帮助你进行恢复。 异地灾难恢复功能可确保命名空间（队列、主题、订阅、筛选器）的整个配置在配对时将从主命名空间连续复制到辅助命名空间。 它允许你随时启动从主命名空间到辅助命名空间的一次性故障转移。 故障转移移动会将命名空间的所选别名重新指向辅助命名空间，然后中断配对。 故障转移几乎是启动后立即发生的。

Azure 认知搜索

在认知搜索中，可通过多个副本实现可用性，而业务连续性和灾难恢复 (BCDR) 通过多种搜索服务来实现。

在认知搜索中，副本是索引的副本。 使用多个副本可让 Azure 认知搜索针对一个副本执行计算机重启和维护，同时可继续针对其他副本执行查询。 有关添加副本的详细信息，请参阅添加或减少副本和分区。

可以通过将两个或多个副本添加到搜索服务来利用 Azure 认知搜索的可用性区域。 每个副本都将放置在该区域内不同的可用性区域中。

有关 BCDR 的注意事项，请参阅不同地理区域中的多个服务文档。

Azure Redis 缓存

虽然 Azure Cache for Redis 的所有层都提供标准复制以实现高可用性，但建议使用高级层或企业层来提供更高级别的复原能力和可恢复性。 请查看高可用性和灾难恢复，其中提供了这些层的复原能力和可恢复性功能与选项的完整列表。 业务要求决定了哪一层最适合你的基础结构。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。 在设计跨区域实现高可用性时，请考虑以下几点。

Azure Front Door

如果主要区域变得不可用，则 Azure Front Door 将自动进行故障转移。 当 Front Door 进行故障转移时，一段时间（通常约 20-60 秒）内客户端将无法访问应用程序。 持续时间受以下因素影响：

• 运行状况探测的频率。 运行状况探测发送的频率越高，Front Door 检测到停机或源恢复正常的速度就越快。
• 示例大小配置。 此配置控制运行状况探测检测到主要源已无法访问所需的样本数。 如果此值太低，可能会因间歇性问题而发生误报。

Front Door 是系统中的一个潜在故障点。 如果服务出现故障，则客户端在停机期间无法访问应用程序。 查看 Front Door 服务级别协议 (SLA)，然后确定仅使用 Front Door 是否能满足业务对高可用性的需求。 如果不能，请考虑添加另一个流量管理解决方案作为故障回复机制。 如果 Front Door 服务出现故障，请将 DNS 中的规范名称 (CNAME) 记录更改为指向另一个流量管理服务。 此步骤必须手动执行，并且在 DNS 更改被传播之前，应用程序将不可用。

Azure Front Door 标准和高级层结合了 Azure Front Door（经典）和 Microsoft 标准 Azure CDN（经典）的功能，将 Azure WAF 变为单一平台。 使用 Azure Front Door 标准或高级可减少故障点并增强控制、监视和安全性。 有关详细信息，请参阅 Azure Front Door 层概述。

SQL 数据库

使用 Azure SQL 数据库确保业务连续性的相关概述中介绍了 SQL 数据库的恢复点目标 (RPO) 和估计恢复时间目标 (RTO)。

请注意，活动异地复制实际上会使每个复制数据库的成本翻倍。 通常，不建议使用沙盒、测试和开发数据库进行复制。

Azure Cosmos DB

Azure Cosmos DB 的 RPO 和恢复时间目标 (RTO) 可以通过使用的一致性级别进行配置，这在可用性、数据持续性和吞吐量之间进行权衡。 Azure Cosmos DB 提供的最小 RTO 为 0 以实现与多主数据库的宽松一致性级别，或者提供的 RPO 为 0 以实现与单主数据库的强一致性。 若要详细了解 Azure Cosmos DB 一致性级别，请参阅 Azure Cosmos DB 中的一致性级别和数据持续性。

存储

RA-GRS 存储提供持久性存储，但在规划执行故障转移时必须考虑到以下因素：

• 提前预料到数据丢失：到次要区域的数据复制是以异步方式执行的。 因此，如果执行异地故障转移，在对主帐户的更改尚未完全同步到辅助帐户的情况下，则预期会丢失一些数据。 可以检查辅助存储帐户的“上次同步时间”属性，以查看上次将主要区域的数据成功写入次要区域的时间。

• 相应地规划恢复时间目标 (RTO)：故障转移到次要区域通常需要大约一个小时，因此灾难恢复计划在计算 RTO 参数时应考虑到这一点。

• 精心规划故障回复：请务必知道，当存储帐户发生故障转移时，原始主要帐户中的数据会丢失。 在未经过精心规划的情况下尝试故障回复到主要区域会带来风险。 故障转移完成后，故障转移区域中新的主要帐户将配置为本地冗余存储 (LRS)。 必须手动将其重新配置为异地复制的存储以启动到主要区域的复制，然后留出足够的时间让帐户同步。

• 暂时性故障（例如网络中断）不会触发存储故障转移。 设计应用程序时请使其能够在发生暂时性故障时进行复原。 缓解选项包括：

  • 从次要区域中进行读取。
  • 临时切换到另一存储帐户来执行新的写入操作（例如将消息排入队列）。
  • 将数据从次要区域复制到另一个存储帐户。
  • 提供降低的功能，直到系统完成故障回复。

有关详细信息，请参阅在 Azure 存储中断时该怎么办。

请参阅对象复制的先决条件和注意事项文档，了解对块 Blob 使用对象复制时的注意事项。

Azure 服务总线

请务必知道，高级 Azure 服务总线层中的异地灾难恢复功能可以使用相同的配置实现即时操作连续性。 但它不会复制队列或主题订阅或者死信队列中保存的消息。 因此，需要采取一种缓解策略来确保顺利故障转移到次要区域。 有关其他注意事项和缓解策略的详细说明，请参阅考虑的要点和灾难恢复注意事项文档。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。

限制传入流量：将应用程序配置为仅接受来自 Front Door 的流量。 这可以确保所有流量在到达应用之前都流经 WAF。 有关详细信息，请参阅如何将对后端的访问锁定为仅限 Azure Front Door？

跨源资源共享 (CORS)：如果将网站和 Web API 作为独立应用创建，则网站不能向 API 进行客户端 AJAX 调用，除非启用 CORS。

应用服务内置了对 CORS 的支持，不需编写任何应用程序代码。 请参阅借助 CORS 从 JavaScript 使用 API 应用。 请将网站添加到 API 允许域的列表。

SQL 数据库加密：如需加密数据库中的静态数据，请使用透明数据加密。 此功能对整个数据库（包括备份和事务日志文件）执行实时加密和解密，不需对应用程序进行更改。 加密会增加一些延迟，因此最好将必须保护的数据单独放置在自己的数据库中，仅对该数据库启用加密。

标识：为该体系结构中的组件定义标识时，请尽可能使用系统管理的标识，以减少凭据管理需求，降低凭据管理固有风险。 无法使用系统管理的标识时，请确保每个用户管理的标识仅存在于一个区域中，且永远不会跨区域边界共享。

服务防火墙：为组件配置服务防火墙时，请确保只有区域本地服务才能访问服务，并确保服务仅允许复制和应用程序功能显式要求的出站连接。 考虑使用 Azure 专用链接，以进一步增强控制和分段。 有关保护 Web 应用程序的详细信息，请参阅基线高可用性区域冗余 Web 应用程序。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

缓存：使用缓存来减少服务器上的负载，这些服务器提供不经常更改的内容。 每个页面呈现周期都会影响成本，因为它会消耗计算、内存和带宽。 使用缓存可以显著降低这些成本，尤其是对于静态内容服务，例如 JavaScript 单页应用和媒体流内容。

如果应用包含静态内容，请使用 CDN 来减少前端服务器上的负载。 对于不经常更改的数据，请使用 Azure Cache for Redis。

状态：配置了自动缩放的无状态应用比有状态应用的成本效益更好。 对于使用会话状态的 ASP.NET 应用程序，请将它同时存储在内存中和 Azure Cache for Redis 中。 有关详细信息，请参阅 Azure Cache for Redis 的 ASP.NET 会话状态提供程序。 另一个选项是通过会话状态提供程序将 Azure Cosmos DB 用作后端状态存储。 请参阅将 Azure Cosmos DB 用作 ASP.NET 会话状态和缓存提供程序。

函数：考虑将函数应用置于专用的应用服务计划中，使后台任务不在处理 HTTP 请求的实例上运行。 如果后台任务间歇性运行，请考虑使用消耗计划，该计划按使用的执行数和资源数计费，而不是按小时计费。

有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。

请使用定价计算器估算成本。 本部分中的这些建议可以帮助你降低成本。

Azure Front Door

Azure Front Door 计费有三个定价层：出站数据传输、入站数据传输和路由规则。 有关详细信息，请参阅 Azure Front Door 定价。 定价图表不包括从源服务访问数据的成本和传输到 Front Door 的成本。 这些成本按数据传输费用计费，如带宽定价详细信息中所述。

Azure Cosmos DB

决定 Azure Cosmos DB 定价的因素有两个：

• 预配的吞吐量或每秒请求单位数（RU/秒）。

  在 Azure Cosmos DB 中可以预配两种类型的吞吐量：标准和自动缩放。 标准吞吐量分配保证指定的 RU/秒所需的资源。 对于自动缩放，预配最大吞吐量，Azure Cosmos DB 会根据负载立即纵向扩展或纵向缩减吞吐量，最小为最大自动缩放吞吐量的 10%。 标准吞吐量按每小时预配的吞吐量计费。 自动缩放吞吐量按每小时消耗的最大吞吐量计费。

• 使用的存储。 按指定时间内用于数据和索引的总存储量 (GBs) 来收取统一费用。

有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。

性能效率

Azure 应用服务的主要优势是能够根据负载缩放应用程序。 下面是在计划缩放应用程序时需要考虑的一些注意事项。

应用服务应用

如果解决方案包括多个应用服务应用，可考虑将其部署到不同的应用服务计划。 这种方法允许独立缩放应用，因为应用在不同的实例上运行。

SQL 数据库

通过数据库分片，增加 SQL 数据库的可伸缩性。 分片是指将数据库水平分区。 可以通过分片，使用弹性数据库工具横向扩展数据库。 分片的潜在好处包括：

• 提高事务吞吐量。
• 对数据子集运行查询可以提高速度。

Azure Front Door

Front Door 可以执行 SSL 卸载，还可以减少与后端 Web 应用建立的 TCP 连接总数。 这可以提高可伸缩性，因为 Web 应用管理的 SSL 握手和 TCP 连接数更少。 由于连接重用程度较高，即使你将请求作为 HTTPS 转发到 Web 应用，也能获得这些性能增益。

Azure 搜索

Azure 搜索没有在主数据存储中执行复杂的数据搜索所需的开销，并可通过缩放来处理负载。 请参阅在 Azure 搜索中缩放用于查询和索引工作负荷的资源级别。

卓越运营

卓越运营是指部署应用程序并使其在生产环境中保持运行的操作流程，也是架构良好的框架可靠性指南的延伸。 此指南详细概述了如何在应用程序框架中建立复原能力，以确保工作负载可用并可以在发生任何规模的故障后恢复。 此方法的核心原则是将应用程序基础结构设计为高度可用，最好是按此设计中所示跨多个地理区域可用。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

• Arvind Boggaram Pandurangaiah Setty | 高级顾问

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

• 深入了解 Azure Front Door - 流量路由方法

• 创建基于终结点监视模式报告应用程序整体运行状况的运行状况探测

• 启用 Azure SQL 自动故障转移组

• 使用 Azure 配对区域确保业务连续性和灾难恢复

相关资源

• 多区域 N 层应用程序是类似方案。 它显示了在多个 Azure 区域中运行的 N 层应用程序

• Azure 应用程序的设计原则