【Azure架构】azure上高可用的多区域web应用程序

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

• 在Azure App Service web应用程序中改进可扩展性和性能的行之有效的做法
• 如何在多个地区运行Azure App Service应用程序以实现高可用性

架构

 

图显示了具有高可用性的web应用程序的参考体系结构。

Download a Visio file of this architecture.

流

此工作流解决了体系结构的多区域方面，并建立在基本web应用程序的基础上。

• Primary and secondary regions。此体系结构使用两个区域来实现更高的可用性。应用程序部署到每个区域。在正常操作期间，网络流量被路由到主区域。如果主区域变得不可用，则流量将路由到辅助区域。
• Front Door。Azure Front Door是建议用于多区域实现的负载均衡器。它与web应用程序防火墙（WAF）集成，以防止常见的漏洞利用，并使用Front Door的本地内容缓存功能。在该体系结构中，Front Door被配置为优先路由，它将所有流量发送到主区域，除非它变得不可用。如果主要区域不可用，Front Door会将所有流量路由到次要区域。
• Geo-replication 。存储帐户、SQL数据库和/或Azure Cosmos数据库的地理复制。

笔记
有关将Azure Front Door用于多区域架构（包括在网络安全配置中）的详细概述，请参阅网络安全入口实现。

组件

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

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

场景详细信息

有几种通用方法可以实现跨区域的高可用性：

• 带热备用的主动/被动【Active/Passive with hot standby】：流量流向一个区域，而另一个区域在热备用状态下等待。热备用意味着辅助区域中的应用程序服务已分配并且始终在运行。
• 主动/被动冷待机【Active/Passive with cold standby】：流量流向一个区域，而另一个区域在冷待机状态下等待。冷备用意味着辅助区域中的应用程序服务在需要进行故障切换之前不会分配。这种方法运行成本较低，但在出现故障时通常需要更长的时间才能联机。
• 活动/活动【Active/Active】：两个区域都处于活动状态，请求在它们之间实现负载平衡。如果某个区域不可用，则该区域将退出旋转。

本参考主要介绍带热备用功能的主动/被动。

潜在用例

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

• 为业务范围应用程序设计业务连续性和灾难恢复计划。
• 部署在Windows或Linux上运行的任务关键型应用程序。
• 通过保持应用程序可用性来改善用户体验。

 

建议

您的需求可能与此处描述的体系结构不同。以本节中的建议为起点。

区域配对【Regional pairing】

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

• 如果出现大范围停电，则优先恢复每对中至少一个区域。
• 计划的Azure系统更新按顺序推出到成对的区域，以最大限度地减少可能的停机时间。
• 在大多数情况下，区域对位于同一地理位置，以满足数据驻留要求。
  但是，请确保这两个区域都支持应用程序所需的所有Azure服务。请参阅按地区提供的服务。有关区域配对的更多信息，请参阅业务连续性和灾难恢复（BCDR）：Azure配对区域。

资源组

考虑将主要区域、次要区域和Front Door放置到单独的资源组中。通过此分配，您可以将部署到每个区域的资源作为一个集合进行管理。

应用服务应用

我们建议将web应用程序和web API创建为单独的应用程序服务应用程序。此设计允许您在单独的应用程序服务计划中运行它们，以便它们可以独立扩展。如果您最初不需要这种级别的可扩展性，您可以将应用程序部署到同一计划中，然后在必要时将它们移动到不同的计划中。

笔记
对于“基本”、“标准”、“高级”和“独立”计划，您将按计划中的VM实例计费，而不是按应用计费。请参阅应用程序服务定价

前门配置【Front Door configuration】

• 路由。前门支持多种布线机制。对于本文中描述的场景，请使用优先级路由。使用此设置，Front Door将所有请求发送到主区域，除非该区域的端点无法访问。此时，它会自动故障转移到次要区域。设置具有不同优先级值的源池，1用于主动区域，2或更高用于备用或被动区域。
• 健康探头。Front Door使用HTTPS探测器来监控每个后端的可用性。探针为Front Door（前门）提供故障转移到辅助区域的合格/不合格测试。它通过向指定的URL路径发送请求来工作。如果在超时时间内得到非200响应，则探测失败。您可以配置健康探测频率、评估所需的样本数量以及将来源标记为健康所需的成功样本数量。如果Front Door将原点标记为降级，则故障转移到另一个原点。有关详细信息，请参阅Health Probes。

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

确保来源于互联网是实现可公开访问的应用程序的关键部分。请参阅网络安全入口实现，了解Microsoft为保护应用程序与前门的入口通信而推荐的设计和实现模式。

• CDN。使用Front Door的原生CDN功能来缓存静态内容。CDN的主要好处是减少用户的延迟，因为内容缓存在地理位置靠近用户的边缘服务器上。CDN还可以降低应用程序的负载，因为应用程序不处理流量。Front Door还提供了动态网站加速功能，使您能够为web应用程序提供比仅使用静态内容缓存更好的整体用户体验。

笔记
Front Door CDN不是为提供需要身份验证的内容而设计的。

SQL数据库

使用主动地理复制和自动故障切换组使数据库具有弹性。主动地理复制允许您将数据库从主区域复制到一个或多个（最多四个）其他区域。自动故障切换组建立在活动的地理复制之上，允许您故障切换到辅助数据库，而无需对应用程序进行任何代码更改。故障切换可以手动执行，也可以根据您创建的策略定义自动执行。为了使用自动故障转移组，您需要使用为故障转移组自动创建的故障转移连接字符串而不是单个数据库的连接字符串来配置连接字符串。

Azure Cosmos数据库

Azure Cosmos DB支持多个写入区域的活动-活动模式中跨区域的地理复制。或者，您可以将一个区域指定为可写区域，将其他区域指定为只读副本。如果出现区域中断，您可以通过选择另一个区域作为写入区域进行故障转移。客户端SDK会自动向当前写入区域发送写入请求，因此故障切换后无需更新客户端配置。有关更多信息，请参阅Azure Cosmos DB的全球数据分发。

存储

对于Azure存储，请使用读访问地理冗余存储（RA-GRS）。使用RA-GRS存储，数据被复制到辅助区域。您可以通过单独的端点以只读方式访问辅助区域中的数据。地理复制存储帐户支持用户启动的到辅助区域的故障切换。启动存储帐户故障切换会自动更新DNS记录，使辅助存储帐户成为新的主存储帐户。故障切换只能在您认为必要时进行。此要求由您所在组织的灾难恢复计划定义，您应该考虑以下注意事项部分中所述的影响。

如果出现区域中断或灾难，Azure存储团队可能会决定执行到辅助区域的地理故障转移。对于这些类型的故障切换，不需要客户采取任何行动。在这些情况下，故障回复到主区域也由Azure存储团队管理。

在某些情况下，块Blob的对象复制对于您的工作负载来说是一个足够的复制解决方案。此复制功能允许您将单个块Blob从主存储帐户复制到辅助区域中的存储帐户中。这种方法的好处是可以精细地控制要复制的数据。您可以定义一个复制策略，以便对所复制的块Blob的类型进行更精细的控制。策略定义的示例包括但不限于：

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

在这种情况下，队列存储被引用为Azure Service Bus的替代消息传递选项。但是，如果您将队列存储用于消息传递解决方案，则上面提供的与地理复制相关的指导适用于此，因为队列存储驻留在存储帐户上。然而，重要的是要理解，信息不会复制到次要区域，它们的状态与该区域密不可分。

Azure服务总线

为了从Azure Service Bus提供的最高弹性中获益，请为您的命名空间使用高级层。高级层利用了可用性区域，使您的命名空间能够抵御数据中心中断。如果发生影响多个数据中心的大范围灾难，高级层中包含的地理灾难恢复功能可以帮助您进行恢复。Geo-Daster恢复功能可确保命名空间的整个配置（队列、主题、订阅和筛选器）在配对时从主命名空间连续复制到辅助命名空间。它允许您随时启动从主系统到辅助系统的一次性故障切换。故障转移移动会将为命名空间选择的别名重新指向辅助命名空间，然后断开配对。故障转移在启动后几乎是即时的。

Azure认知搜索

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

在认知搜索中，副本是索引的副本。拥有多个副本允许Azure认知搜索对一个副本进行机器重新启动和维护，而对其他副本继续执行查询。有关添加复制副本的更多信息，请参阅添加或减少复制副本和分区。

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

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

用于Redis的Azure缓存

虽然Azure Cache for Redis的所有层都提供标准复制以实现高可用性，但建议使用高级或企业级层以提供更高级别的恢复能力和可恢复性。查看高可用性和灾难恢复，以获得这些层的恢复能力和可恢复性功能及选项的完整列表。您的业务需求将决定哪一层最适合您的基础架构。

注意事项
 

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

可靠性

可靠性确保您的应用程序能够满足您对客户的承诺。有关更多信息，请参见可靠性支柱概述。在设计跨区域的高可用性时，请考虑以下几点。

Azure前门

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

• 健康探头的频率。运行状况探测发送的频率越高，Front Door检测停机时间或原点恢复正常的速度就越快。
• 样本量配置。此配置控制运行状况探测器检测到主来源无法访问所需的样本数量。如果这个值太低，您可能会从间歇性问题中得到误报。

前门可能是系统中的一个故障点。如果服务失败，客户端将无法在停机期间访问您的应用程序。查看Front Door服务级别协议（SLA），并确定单独使用Front Doors是否满足高可用性的业务要求。如果没有，请考虑添加另一个流量管理解决方案作为后备方案。如果Front Door服务失败，请更改DNS中的规范名称（CNAME）记录以指向其他流量管理服务。此步骤必须手动执行，在传播DNS更改之前，您的应用程序将不可用。

Azure前门标准和高级层将Azure前门（经典）、Microsoft的Azure CDN标准（经典）和Azure WAF的功能合并到一个平台中。使用Azure Front Door Standard或Premium可减少故障点，并增强控制、监控和安全性。有关更多信息，请参阅Azure Front Door层概述。

SQL数据库

SQL数据库的恢复点目标（RPO）和估计恢复时间目标（RTO）记录在Azure SQL数据库的业务连续性概述中。

请注意，主动地理复制有效地使每个复制数据库的成本翻倍。通常不建议复制沙盒、测试和开发数据库。

Azure Cosmos数据库

Azure Cosmos DB的RPO和恢复时间目标（RTO）可通过所使用的一致性级别进行配置，从而在可用性、数据持久性和吞吐量之间进行权衡。Azure Cosmos DB提供0的最低RTO，以实现与多主机的宽松一致性级别，或提供0的RPO，以实现对单个主机的强一致性。要了解有关Azure Cosmos DB一致性级别的更多信息，请参阅Azure Cosmos数据库中的一致性级别和数据持久性。

存储

RA-GRS存储提供了持久的存储，但在考虑执行故障切换时，重要的是要考虑以下因素：

• 预计数据丢失：到辅助区域的数据复制是异步执行的。因此，如果执行地理故障切换，如果对主帐户的更改尚未完全同步到辅助帐户，则应预计会出现一些数据丢失。您可以检查辅助存储帐户的“上次同步时间”属性，以查看上次将主区域中的数据成功写入辅助区域的时间。
• 相应地规划您的恢复时间目标（RTO）：到辅助区域的故障切换通常需要大约一个小时，因此您的灾难恢复计划在计算RTO参数时应将此信息考虑在内。
• 仔细规划故障恢复：重要的是要明白，当存储帐户发生故障转移时，原始主帐户中的数据就会丢失。在没有仔细规划的情况下尝试故障恢复到主区域是有风险的。故障切换完成后，将为本地冗余存储（LRS）配置故障切换区域中的新主存储。您必须手动将其重新配置为地理复制存储，以启动到主区域的复制，然后给足够的时间让帐户同步。
• 暂时性故障（如网络中断）不会触发存储故障切换。将您的应用程序设计为对瞬时故障具有弹性。缓解方案包括：
  • 从次要区域读取。
  • 临时切换到另一个存储帐户以执行新的写入操作（例如，对消息进行排队）。
  • 将数据从辅助区域复制到另一个存储帐户。
  • 提供减少的功能，直到系统故障恢复。
     

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

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

Azure服务总线

重要的是要理解，高级Azure服务总线层中包含的地理灾难恢复功能能够在相同配置下实现操作的即时连续性。但是，它不会复制队列、主题订阅或死信队列中的消息。因此，需要一种缓解策略来确保顺利故障切换到辅助区域。有关其他注意事项和缓解策略的详细说明，请参阅需要考虑的要点和灾难恢复注意事项文档。

安全

安全性提供了防止蓄意攻击和滥用您的宝贵数据和系统的保证。有关更多信息，请参阅安全支柱概述。

• 限制传入流量将应用程序配置为仅接受来自前门的流量。这样可以确保所有流量在到达应用程序之前都通过WAF。有关更多信息，请参阅如何将对后端的访问锁定为仅Azure Front Door？
• 交叉原始资源共享（CORS）如果您将网站和web API创建为单独的应用程序，则除非启用CORS，否则网站无法对API进行客户端AJAX调用。

笔记
浏览器安全性防止网页向另一个域发出AJAX请求。此限制称为同源策略，可防止恶意站点从其他站点读取敏感数据。CORS是W3C标准，
允许服务器放宽同源策略，允许一些跨源请求，同时拒绝其他请求。

App Services内置了对CORS的支持，无需编写任何应用程序代码。请参阅使用CORS从JavaScript消费API应用程序。将网站添加到API的允许来源列表中。

• SQL数据库加密如果需要加密数据库中的静态数据，请使用透明数据加密。此功能对整个数据库（包括备份和事务日志文件）执行实时加密和解密，并且不需要更改应用程序。加密确实会增加一些延迟，因此最好将必须安全的数据分离到自己的数据库中，并仅对该数据库启用加密。
• 标识在此体系结构中定义组件的标识时，请尽可能使用系统管理的标识，以减少管理凭据的需要以及管理凭据所固有的风险。如果无法使用系统管理的标识，请确保每个用户管理的标识只存在于一个区域中，并且永远不会跨区域共享。
• 服务防火墙为组件配置服务防火墙时，请确保只有区域本地服务可以访问这些服务，并且这些服务只允许出站连接，这是复制和应用程序功能明确要求的。考虑使用Azure专用链接来进一步增强控制和分段。有关保护web应用程序安全的更多信息，请参阅基线高可用区域冗余web应用程序。

成本优化

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

• 缓存使用缓存来减少服务器上的负载，这些服务器提供的内容不会频繁更改。页面的每个渲染周期都会影响成本，因为它会消耗计算、内存和带宽。使用缓存可以显著降低这些成本，尤其是对于静态内容服务，如JavaScript单页应用程序和媒体流内容。
• 如果您的应用程序有静态内容，请使用CDN来降低前端服务器的负载。对于不经常更改的数据，请使用Azure Cache For Redis。
• 配置为自动缩放的无状态状态应用程序比有状态应用程序更具成本效益。对于ASP。NET应用程序，使用Azure Cache for Redis将其存储在内存中。有关详细信息，请参见ASP。用于Redis的Azure缓存的.NET会话状态提供程序。另一种选择是通过会话状态提供程序将Azure Cosmos DB用作后端状态存储。请参阅将Azure Cosmos DB用作ASP。NET会话状态和缓存提供程序。
• 功能考虑将功能应用程序放入专用的应用程序服务计划中，这样后台任务就不会在处理HTTP请求的同一实例上运行。如果后台任务间歇性运行，请考虑使用消耗计划，该计划是根据执行次数和使用的资源而不是每小时计费的。

有关更多信息，请参阅Microsoft Azure架构良好的框架中的成本部分。

使用定价计算器来估计成本。本节中的这些建议可能有助于您降低成本。

Azure前门

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

Azure Cosmos数据库

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

• 提供的吞吐量或每秒请求单位（RU/s）。
• Azure Cosmos DB中可以提供两种类型的吞吐量，标准吞吐量和自动缩放吞吐量。标准吞吐量分配保证您指定的RU所需的资源。对于自动缩放，您可以提供最大吞吐量，Azure Cosmos DB会根据负载立即进行放大或缩小，最小吞吐量为最大自动缩放吞吐量的10%。标准吞吐量按每小时提供的吞吐量计费。自动缩放吞吐量按每小时消耗的最大吞吐量计费。

消耗的存储空间。您将按给定小时内数据和索引消耗的总存储量（GB）收取统一费率。

有关更多信息，请参阅Microsoft Azure架构良好的框架中的成本部分。

性能效率

Azure应用程序服务的一个主要好处是能够根据负载扩展应用程序。在计划扩展应用程序时，需要注意以下几点。

应用服务应用

如果您的解决方案包括多个应用程序服务应用程序，请考虑将它们部署到单独的应用程序服务计划中。这种方法使您能够独立地扩展它们，因为它们在单独的实例上运行。

SQL数据库

通过对数据库进行分片，提高SQL数据库的可扩展性。Sharding是指对数据库进行水平分区。Sharding允许您使用Elastic database工具横向扩展数据库。分片的潜在好处包括：

• 更好的事务吞吐量。
• 查询可以在数据的子集上运行得更快。

Azure前门

Front Door可以执行SSL卸载，还可以减少与后端web应用程序的TCP连接总数。这提高了可扩展性，因为web应用程序管理的SSL握手和TCP连接量较小。由于高级别的连接重用，即使您将请求以HTTPS转发到web应用程序，这些性能提升也适用。

Azure搜索

Azure Search消除了从主数据存储中执行复杂数据搜索的开销，并且可以扩展以处理负载。请参阅在Azure Search中扩展查询和索引工作负载的资源级别。

卓越运营

卓越运营是指部署应用程序并使其在生产中运行的运营过程，是“良好架构的框架可靠性”指南的延伸。本指南详细概述了在应用程序框架中构建弹性，以确保您的工作负载可用，并可以从任何规模的故障中恢复。此方法的一个核心原则是将您的应用程序基础架构设计为高可用性，如此设计所示，可跨多个地理区域进行优化。

 

接下来的步骤

• Deep dive on Azure Front Door - traffic routing methods

• Create health probes that report the overall health of the application based on endpoint monitoring patterns

• Enable Azure SQL auto-failover groups

• Ensure business continuity and disaster recovery using Azure Paired Regions

相关资源

• Multi-region N-tier application is a similar scenario. It shows an N-tier application running in multiple Azure regions

• Design principles for Azure applications