设计地理分布式体系结构
- 10 分钟
Azure 是一个全球系统。 通过设计存在于多个 Azure 区域中的体系结构，我们可以构建一个应用程序，该应用程序可以灵活应对区域范围的灾难。
发货跟踪门户是可缩放的，因为它是使用一系列可缩放的 Azure 资源生成的。 它还能够抵抗多种故障，因为它的组件可以有多个实例。 但是，你的董事会开始担心大规模的灾难可能会导致中断，因为门户完全架构在美国东部 Azure 区域。 你希望建议一种改进了的体系结构，如果美国东部发生故障，该体系结构可以故障转移到另一个区域。
在这里，我们了解如何调整应用程序的体系结构以支持地理分布式应用程序。 我们还了解为什么此类体系结构对业务关键型应用程序有利。
原始 Web 应用体系结构
让我们看看跟踪门户的体系结构设计以及解决方案中使用的组件。 了解所有部件的使用方式后，我们可以调查如何在异地冗余方案中支持其中每个组件。
跟踪门户的设计基于下图所示的参考体系结构。
请注意应用程序如何使用单个 Azure 资源组。 通过此资源组，我们可以以逻辑方式对所有资源进行分组和管理，并简化管理。 我们选择将此资源组部署到美国东部区域。 尽管资源组不限制我们对包含的资源使用相同的 Azure 区域，但我们决定将美国东部区域用于应用程序中部署的所有资源。
我们的应用程序使用三类 Azure 资源。 让我们看看每个类别，并查看正在使用的资源。
网络组件
跟踪门户使用以下网络服务。
| 服务 | DESCRIPTION |
|---|---|
| Azure DNS | 我们已将 Azure DNS 配置为在 Azure 中托管 DNS 记录。 Azure DNS 允许我们在 Azure 门户中使用 Azure 凭据管理 DNS 记录。 |
| 应用程序网关 | 我们已将应用程序网关负载均衡器配置为平衡 Web 前端的多个实例之间的流量。 此服务已本地化为一个 Azure 区域。 |
| Azure CDN | 我们已将 Azure CDN 配置为最大程度地传送不安全的静态内容，例如网站内容的图形。 此全局服务在全球存在点缓存静态内容。 |
应用程序组件
跟踪门户使用以下服务来支持代码、缓存和中间存储要求。
| 服务 | DESCRIPTION |
|---|---|
| Microsoft Entra ID | 用户使用 Microsoft Entra 帐户访问跟踪门户。 目录和帐户会自动全局复制。 |
| Azure 应用程序服务 | 跟踪门户使用两个 Azure 应用服务。 第一个运行一组动态网页，第二个运行 Web API。 |
| Azure 函数应用 | 跟踪门户使用 Azure Function Apps 运行所有后台任务。 其中一些任务按常规计划运行，而其他任务基于队列中的消息进行操作。 |
| Azure 存储队列 | 跟踪门户将 Azure 存储队列与 Azure 函数应用配合使用。 跟踪门户对生成的消息进行排队，函数应用在队列中处理这些消息。 |
| Redis 缓存 | 跟踪门户使用前端应用服务和数据存储系统之间的 Redis 缓存，以最大限度地提高查询的性能。 |
| Azure Blob 存储服务 | 静态内容（如图形和视频文件）作为二进制大型对象（Blob）保存在 Azure 存储帐户中，并通过 Azure CDN 传递。 |
| Azure 搜索 | 我们在跟踪门户中启用了 Azure 搜索。 借助 Azure 搜索，我们可以使所有内容可搜索，并向用户提供搜索建议和模糊搜索结果。 |
数据存储组件
跟踪门户使用以下持久存储服务。
| 服务 | DESCRIPTION |
|---|---|
| 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 存储帐户中使用 Geo-Redundant 存储（GRS）选项。 GRS 将数据块复制到另一个区域。
下表显示了哪些组件是全局、区域和可配置的。
| 组件 | 支持多个区域 | 注释 |
|---|---|---|
| Azure DNS | 全球 | 无需任何更改。 |
| 应用程序网关 | 区域 | 应用程序网关的每个实例都位于单个区域中。 |
| Azure CDN | 全球 | 无需更改，默认情况下，内容将全局缓存。 |
| Microsoft Entra ID | 全球 | 无需任何更改。 |
| Azure App 服务 | 区域 | 应用的每个实例都位于单个区域中。 |
| 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 数据中心的单个地理位置的区域。 所有区域与同一地理位置中的其他区域配对。 在这些对中，一次只能在一个区域进行更新和计划内维护。 如果发生故障会影响多个区域，则每个对中至少有一个区域优先进行快速恢复。
最佳做法是将应用的两个区域体系结构放置在区域对中的两个区域。 例如，美国东部与美国西部配对。 我们的建议设计使用美国东部为其活动区域，而美国西部则使用其备用区域。