此体系结构为使用大量数据的 Web 应用程序提供高可用性解决方案。 这是一种灵活的方法，可以提供全局解决方案来分发应用程序和数据以使其与用户保持密切关系。
该体系结构需要自定义复制软件。 这可能很难创建，具体取决于应用程序和配置。
以下是一些可能的配置：
主动/被动：有一个主要区域通常向所有用户提供服务。 当主要区域无法正常工作时，还有一个备用区域将变为主动状态。 当主系统处于主动状态时，复制服务会将数据库更改复制到备用区域。
主动/主动：有一个主要区域通常处于主动状态，可为附近的用户提供读取服务，并为所有用户提供写入服务。 一个或多个其他区域处于主动状态，并为附近的用户提供只读服务。 写入始终定向到主要区域，读取始终定向到最近的主动区域。
与主动/被动配置一样，当主要区域无法正常运行时，备用区域将变为主动状态。 当主系统处于主动状态时，复制服务会将数据库更改复制到只读区域和备用区域。 当备用区域处于主动状态时，复制服务会将数据库更改复制到只读区域。
此方法的一个缺点是写入操作延迟较高。
多主动：有多个主动区域，每个区域都能向用户提供完整服务。 用户活动始终定向到最近的主动区域。
多主动配置的实现非常具有挑战性，可能需要专家设计和实施。
由于复制是自定义实现，因此一致性级别可以是任何所需级别。
实现自定义复制可能遇到的困难和所需的时间是此体系结构的重要注意事项。
注意
在某些情况下，应用程序可能需要多个存储帐户。 请参阅注意事项，了解详细信息。
可能的用例
该体系结构可能适用于任何使用必须始终可用的大量数据的应用程序。 示例包括可实现以下操作的应用：
- 跟踪客户支出习惯和购物行为（零售业）。
- 天气预报（农业、环境和媒体/新闻行业）。
- 提供智能流量系统或实现智能流量系统，或使用智能技术来监视流量（汽车和运输业）。
- 分析制造业物联网 (IoT) 数据。
- 显示智能计量数据或使用智能技术来监视计量数据（能源行业）。
体系结构
下载此体系结构的 Visio 文件。
数据流
- 客户端通过 Microsoft Entra ID 进行身份验证，并被授予访问 Azure 应用程序服务上托管的 Web 应用程序的权限。
- Azure Front Door（防火墙和第 7 层负载均衡器）在发生区域性中断时，将用户流量切换到其他 Azure 区域。
- Azure 应用程序服务托管网站和 RESTful Web API。 浏览器客户端运行使用 API 的 AJAX 应用程序。
- Web API 委托函数应用来处理后台任务。 任务在 Azure 队列存储队列中排队。
- 由 Azure Functions 托管的函数应用执行由排队消息触发的后台任务。
- 自定义复制软件可确保表在区域之间保持不变。
- Azure Cache for Redis 缓存函数应用的表数据。 这减轻了数据库活动的负载，加快了函数应用和 Web 应用的速度。
- Azure 表存储保存 Web 应用程序使用的数据。
组件
- Microsoft Entra ID 是一种多租户标识和访问管理服务，可以与本地目录同步。 Azure DNS 是用于 DNS 域的高可用性托管服务，为应用提供快速 DNS 查询和 DNS 记录的快速更新。 管理 Azure DNS 就像管理其他 Azure 服务一样，并且使用相同的凭据、API、工具和计费。
- Azure Front Door 是一个安全的内容分发网络 (CDN) 和具有即时故障转移的负载均衡器。 它在靠近用户的边缘运行，加速内容交付，同时保护应用、API 和网站免受网络威胁。
- Azure 应用程序服务是用于构建、部署和扩展 Web 应用的完全托管服务。 可以使用.NET、.NET Core、Node.js、Java、Python 或 PHP 来构建应用。 应用可以在容器中或者在 Windows 或 Linux 上运行。 在大型机迁移中，前端屏幕或 Web 界面可以编码为基于 HTTP 的 REST API。 它们可以进行隔离，并且可以是无状态的，以编排基于微服务的系统。 有关 Web API 的详细信息，请参阅 RESTful Web API 设计。
- Azure Functions 提供了一个无需建立应用程序基础结构即可运行小段代码（称为函数）的环境。 可将其用于处理大量数据、集成系统、使用 IoT 以及生成简单的 API 和微服务。 借助微服务，你可以创建连接到 Azure 服务并始终保持最新状态的服务器。
- Azure 存储，它是适用于数据、应用和工作负载的一组云服务，可以大规模缩放，并且很安全。 其中包括 Azure 文件存储、Azure 表存储和 Azure 队列存储。 Azure 文件存储通常是迁移大型机工作负载的有效工具。
- Azure 队列存储提供简单、经济高效、持久的消息队列，适用于大型工作负载。
- Azure 表存储是一种用于使用大型半结构化数据集进行快速开发的 NoSQL 键值存储。 表是无架构的，可随着需求的变化随时进行调整。 对于许多类型的应用程序，访问快速且经济高效，通常成本低于其他类型的键控存储。
- Azure Cache for Redis 是一种完全托管的内存中缓存服务和消息中转站，用于在计算资源之间共享数据和状态。 它提供开放源代码 Redis 和 Redis 实验室提供的一款商业产品作为托管服务。 要提高高吞吐量联机事务处理应用程序的性能，可以将其设计为可缩放并利用内存中数据存储（如 Azure Cache for Redis）。
备选方法
- Azure 流量管理器根据你选择的流量路由方法来跨全球 Azure 区域引导传入的 DNS 请求。 它还提供自动故障转移和性能路由。
- Azure 内容分发网络 (CDN) 在边缘服务器中缓存静态内容以实现快速响应，并使用网络优化来改进对动态内容的响应。 如果用户群遍布全球，CDN 特别有用。
- Azure Kubernetes 服务 (AKS)，这是一项完全托管的 Kubernetes 服务，用于部署和管理容器化应用程序。 可使用它实现微服务体系结构，其组件按需独立缩放。
- Azure 容器实例提供一种快速简单的运行任务的方式，无需管理基础结构。 在开发期间或对于运行非计划任务，它非常有用。
- Azure 服务总线是一种可靠的云消息传递服务，可以实现简单的混合集成。 在此体系结构中，它可以用来代替队列存储。 有关详细信息，请参阅存储队列和服务总线队列 - 比较与对照。
注意事项
该体系结构需要自定义复制软件。 这可能很难创建，具体取决于应用程序和配置。 实现自定义复制可能遇到的困难和所需的时间是此体系结构的重要注意事项。
由于复制是自定义设计的，因此开发人员在实现数据一致性策略方面具有极大的灵活性。
有些表存储的性能限制可通过添加存储帐户来克服。 以下情况可能需要更多帐户：
- 实现多租户以支持多个客户
- 支持事务率较高的客户
- 支持有大型数据集的客户
- 通过跨多个存储帐户分布数据来加快数据访问速度
- 将数据隔离到热层、冷层和存档层
- 针对备份和报告目的创建数据副本
有关详细信息，请参阅表存储的可伸缩性和性能目标。
如果应用程序已包含数据，则需要编写例程以将旧数据复制到存储帐户。 确保你有时间戳和复制标志来跟踪数据迁移的进度。
作者
本文由 Microsoft 维护， 最初由以下贡献者撰写。
- Nabil Siddiqui | 云解决方案架构师 - 数字和应用程序创新