你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
此体系结构的核心组件是一个 Web 前端 ，用于处理客户端请求和执行资源密集型任务、长时间运行的工作流或批处理作业 的工作器 。 Web 前端通过 消息队列与工作线程通信。
以下组件通常合并到此体系结构中：
一个或多个数据库
用于存储数据库中的值的缓存，用于快速读取
用于提供静态内容的内容分发网络
非Microsoft服务提供商通常提供的电子邮件或短信服务（SMS）等远程服务
用于身份验证的标识提供者
Web 和工作器都是无状态的，会话状态可以存储在分布式缓存中。 工作线程异步处理长时间运行的任务。 队列上的消息可以启动工作进程，或者由计划任务执行它以进行批处理。 如果应用程序没有长时间运行的操作，则工作线程是可选的。
前端可能包括 Web API。 单页应用程序可以通过调用 AJAX 来使用 Web API，或者本机客户端应用程序可以直接使用它。
何时使用此体系结构
Web-Queue-Worker 体系结构通常通过使用 Azure 应用服务或 Azure Kubernetes 服务等托管计算服务来实现。
对于以下用例，请考虑此体系结构：
具有相对简单域的应用程序
运行时间较长的工作流或批处理操作的应用程序
首选托管服务而不是基础结构即服务（IaaS）的方案
优点
简单易懂的体系结构
以最少工作量部署和管理
明确职责分离
通过异步消息传送分离前端和工作程序
前端和工作节点的独立扩展
挑战
如果不仔细设计，前端和工作程序可能会成为难以维护和更新的单体组件。
如果前端和辅助角色共享数据架构或代码模块，则可能存在隐藏的依赖项。
网页前端在数据持久化到数据库后可能会出现故障，但在将消息发送到队列之前，这会导致数据一致性问题，因为工作进程未能执行其逻辑部分。 若要缓解此问题，可以使用 事务发件箱模式等技术，这些技术要求将传出消息首先回传到独立的队列中。 NServiceBus 事务会话库支持此技术。
最佳做法
向客户端公开设计良好的 API。 有关详细信息，请参阅 API 设计最佳做法。
自动缩放以处理负载中的更改。 有关详细信息，请参阅 自动缩放最佳做法。
缓存半静态数据。 有关详细信息，请参阅 缓存最佳做法。
使用内容分发网络托管静态内容。 有关详细信息，请参阅 内容分发网络最佳做法。
适当时使用多语言持久性。 有关详细信息，请参阅 “了解数据模型”。
对数据进行分区以提高可伸缩性、减少争用并优化性能。 有关详细信息，请参阅 数据分区最佳做法。
应用服务中的Web队列工作者
本部分介绍推荐的 Web-Queue-Worker 架构，该架构使用 App Service。
下载此体系结构的 Visio 文件 。
Workflow
前端实现为 App Service web 应用，工作角色实现为 Azure Functions 应用。 Web 应用和 Functions 应用都与提供虚拟机（VM）实例的应用服务计划相关联。
可以将 Azure 服务总线 或 Azure 存储队列 用于消息队列。 上图使用存储队列。
Azure 托管 Redis 存储会话状态和其他需要低延迟访问的数据。
Azure 内容分发网络 用于缓存静态内容，如图像、CSS 或 HTML。
对于存储，请选择最适合应用程序需求的技术。 此方法称为多语言持久性，它使用同一系统中的多种存储技术来满足不同的需求。 为了说明这一想法，该图显示了 Azure SQL 数据库 和 Azure Cosmos DB。
有关详细信息，请参阅基线高度可用的区域冗余 Web 应用程序和使用 NServiceBus 和服务总线生成消息驱动的业务应用程序。
其他注意事项
并非每个交易都必须经过队列和工作者以写入存储。 Web 前端可以直接执行简单的读取和写入作。 工作进程专为资源密集型任务或长时间运行的工作流而设计。 在某些情况下，可能根本不需要辅助角色。
使用计算平台的内置自动缩放功能横向扩展实例数。 如果应用程序的负载遵循可预测的模式，请使用基于计划的自动缩放。 如果负载不可预知，请使用基于指标的自动缩放。
请考虑将 Web 应用和 Functions 应用放入单独的应用服务计划中，以便它们可以独立缩放。
使用单独的应用服务计划进行生产和测试。
使用部署槽位管理部署。 此方法允许将更新的版本部署到过渡槽，然后交换到新版本。 它还允许在更新过程中出现问题时交换回以前的版本。