设计地理分散式体系结构
- 10 分钟
Azure 是一个全球系统。 通过设计存在于多个 Azure 区域的体系结构，我们可以生成即使在发生区域性灾难时也能复原的应用程序。
你的货运跟踪门户是可缩放的，因为它是使用一系列可缩放的 Azure 资源生成的。 它还可以从许多故障中复原，因为其组件可以有多个实例。 但是，你的董事会开始担心大规模的灾难可能会导致中断，因为门户完全架构在美国东部 Azure 区域。 你希望建议一种改进了的体系结构，如果美国东部发生故障，该体系结构可以故障转移到另一个区域。
在这里，我们将了解如何调整应用程序的体系结构，以支持地理分散式应用程序。 还将了解为什么此类体系结构对于关键业务应用程序是有利的。
原有 Web 应用体系结构
让我们看看跟踪门户的体系结构设计以及解决方案中使用的组件。 了解如何使用所有部件后，可以调查如何在异地冗余方案中支持其中的每个组件。
跟踪门户的设计基于以下关系图中所示的参考体系结构。
请注意应用程序如何使用单个 Azure 资源组。 此资源组允许以逻辑方式对所有资源进行分组和管理，简化了管理。 选择将此资源组部署到美国东部区域。 尽管资源组不限定使用同一个 Azure 区域来存储包含的资源，我们还是决定使用美国东部区域存储在应用程序中部署的所有资源。
应用程序使用三个类别的 Azure 资源。 让我们看看每个类别，并了解正在使用哪些资源。
网络组件
跟踪门户使用以下网络服务。
| 服务 | 说明 |
|---|---|
| Azure DNS | 已将 Azure DNS 配置为在 Azure 中托管 DNS 记录。 Azure DNS 允许在 Azure 门户中使用 Azure 凭据管理 DNS 记录。 |
| 应用程序网关 | 已将应用程序网关负载均衡器配置为在多个 Web 前端实例之间均衡流量。 此服务局限于单个 Azure 区域。 |
| Azure CDN | 已将 Azure CDN 配置为最大限度地提供不安全的静态内容（例如图形）作为网站内容。 此全局服务将静态内容缓存在世界各地的接入点。 |
应用程序组件
跟踪门户使用以下服务来支持代码、缓存以及中间存储要求。
| 服务 | 说明 |
|---|---|
| Microsoft Entra ID | 用户使用 Microsoft Entra 帐户访问跟踪门户。 目录和帐户将自动进行全球复制。 |
| Azure 应用服务 | 跟踪门户使用两个 Azure 应用服务。 第一个运行一组动态网页，第二个运行 Web API。 |
| Azure 函数应用 | 跟踪门户使用 Azure 函数应用运行所有后台任务。 其中一些任务定期运行，其他任务则在队列中对消息进行操作。 |
| Azure 存储队列 | 跟踪门户将 Azure 存储队列与 Azure 函数应用结合使用。 跟踪门户对生成的消息进行排队，函数应用在队列中处理这些消息。 |
| Redis 缓存 | 跟踪门户在前端应用服务和数据存储系统之间使用 Redis 缓存，以最大程度地提高查询性能。 |
| Azure Blob 存储 | 静态内容（例如图形和视频文件）作为二进制大型对象 (Blob) 保存在 Azure 存储帐户中，并通过 Azure CDN 传递。 |
| Azure 搜索 | 已在跟踪门户上启用 Azure 搜索。 通过 Azure 搜索，可以对所有内容进行搜索，并向用户提供搜索建议和模糊搜索结果。 |
数据存储组件
跟踪门户使用以下持久存储服务。
| 服务 | 说明 |
|---|---|
| Azure SQL 数据库 | 我们在 Azure SQL 数据库中存储关系数据，例如订单和客户详细信息。 |
| Cosmos DB | 我们将半结构化数据（包括产品目录）存储在 Cosmos DB 中。 |
原有体系结构的问题
跟踪门户的现有体系结构设计允许实现可伸缩性和可用性。
例如，如果需求较高而对用户 Web 请求的响应较慢，可以考虑在应用服务中添加前端 Web 应用的更多实例。 在这里，应用程序网关可以将请求路由到这些新创建的实例。
但是，在某些情况下，体系结构设计会面临需要克服的挑战，甚至是失败。 让我们看看每个方案，以便更好地了解对跟踪门户的影响。
区域故障
某些重要事件可能会使整个 Azure 区域出现中断。 Azure 数据中心采用高度可复原的设计，但大规模自然灾害（例如飓风或洪水）可能会使该区域的服务中断。
这些都是偶发事件，许多公司认为他们可以承受这种风险。 然而，如果区域故障导致跟踪门户不能正常运行，将带来很高的风险，因此公司的行政团队决定消除这种风险。
服务级别协议
大多数 Azure 服务都提供服务级别协议 (SLA) 或运行时间保证。 设计包含多个 Azure 服务的应用程序体系结构时，我们将复合计算涉及的所有服务的 SLA，以得出应用的整体 SLA。
通过将组件服务的 SLA 相乘来计算此 SLA。 例如，假设应用包含 Azure 应用服务 (99.95% SLA) 和 Microsoft Entra ID (99.9% SLA)。 最终计算得出的 SLA 为 99.85%。
如果此百分比运行时间不足以满足应用程序的需要，可以安排应用程序故障转移到另一个区域。
全球、区域和可配置组件
在我们的设计中，某些组件默认全球分布，不易受到区域故障的影响。
某些组件局限于单个区域，例如应用程序网关。 必须为这些类型的组件选择备用服务。
某些组件可以配置为支持多个区域。 例如，可以在存储静态内容的 Azure 存储帐户中使用异地冗余存储 (GRS) 选项。 GRS 将 Blob 复制到另一个区域。
下表显示了全球分布的组件、局限于区域的组件和可配置的组件。
| 组件 | 多区域支持 | 注释 |
|---|---|---|
| Azure DNS | 全球 | 无需进行任何更改。 |
| 应用程序网关 | 区域 | 应用程序网关的每个实例都位于单个区域中。 |
| Azure CDN | 全球 | 无需进行任何更改，默认在全球缓存内容。 |
| Microsoft Entra ID | 全球 | 无需进行任何更改。 |
| Azure 应用服务 | 区域 | 应用的每个实例都位于单个区域中。 |
| Azure 函数应用 | 区域 | 函数应用的每个实例都位于单个区域中。 |
| Azure 存储队列 | 可配置 | 可选择将 Azure 存储帐户复制到多个区域。 |
| Azure Redis 缓存 | 区域 | 缓存的每个实例都位于单个区域中。 |
| Azure Blob 存储 | 可配置 | 可选择将 Azure 存储帐户复制到多个区域。 |
| Azure 搜索 | 区域 | 搜索服务的每个实例都位于单个区域中。 |
| Azure SQL 数据库 | 可配置 | 可使用异地复制将数据同步到多个区域。 |
| Azure Cosmos DB | 可配置 | 可使用异地复制将数据同步到多个区域。 |
建议的分散式体系结构
经过调查，你建议使用以下关系图中所示的体系结构。
在此设计中，有一个活动区域（美国东部）和一个备用区域（美国西部）。 在一般情况下，由美国东部区域处理所有组件的请求。 如果灾难导致区域性故障，则应用程序会故障转移到美国西部区域。
我们大概检查一下你怎样修改了原体系结构。 在后面的单元，我们将更详细地探讨这些更改。
网络
Azure DNS 和 Azure CDN 默认是全球系统，本身就可以从区域故障中复原。 将保留这些更改。
创建 Azure 应用程序网关时，要将该服务分配到单个区域。 我们使用 Azure Front Door 替换此服务来消除这一漏洞。 Front Door 可以轮询多个应用程序服务，并处理从美国东部区域到美国西部区域的应用服务故障转移。
应用程序服务
Microsoft Entra ID 是一个全球系统，无需修改。
可将 Azure 存储帐户配置为将内容复制到多个区域。 我们使用其中一个异地冗余存储选项来更改配置。
其他组件（包括应用服务、函数应用、Redis 缓存和 Azure 搜索）是区域性的。 在新的体系结构设计中，我们在美国西部区域创建这些组件的重复实例。 在此设计中，新区域可以在发生故障转移时进行接管。
数据存储
Azure SQL 数据库和 Azure Cosmos DB 都支持将数据异地复制到其他区域。 我们配置这些服务，将美国东部的数据复制到美国西部的对等服务。
区域对
Azure 区域指包含一个或多个 Azure 数据中心的单个地理区域。 所有区域都与同一地理区域中的其他区域成对。 在这些对中，一次只能在一个区域进行更新和计划内维护。 如果出现影响多个区域的故障，每个对中至少有一个区域将优先快速恢复。
最佳做法是，在区域对中的两个区域为应用配置双区域体系结构。 例如，美国东部与美国西部成对。 建议设计是将美国东部作为其活动区域，将美国西部作为其备用区域。