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