Web -Queue-Worker 体系结构样式
此体系结构的核心组件是一个 Web 前端 ，用于处理客户端请求，以及执行资源密集型任务、长时间运行的工作流或批处理作业 的工作器 。 Web 前端通过 消息队列与辅助角色通信。
通常合并到此体系结构中的其他组件包括：
- 一个或多个数据库。
- 用于存储数据库中的值的缓存，用于快速读取。
- 用于提供静态内容的 CDN
- 远程服务，如电子邮件或短信服务。 这些功能通常由第三方提供。
- 用于身份验证的标识提供者。
Web 和辅助角色都是无状态的。 会话状态可以存储在分布式缓存中。 任何长时间运行的工作都是由辅助角色异步完成的。 辅助角色可由队列上的消息触发，也可以按计划进行批处理。 辅助角色是一个可选组件。 如果没有长时间运行的作，则可以省略辅助角色。
前端可能包含 Web API。 在客户端上，Web API 可由进行 AJAX 调用的单页应用程序或本机客户端应用程序使用。
何时使用此体系结构
Web-Queue-Worker 体系结构通常使用托管计算服务（Azure 应用服务或 Azure 云服务）实现。
请考虑以下体系结构样式：
- 具有相对简单的域的应用程序。
- 具有一些长时间运行的工作流或批处理作的应用程序。
- 如果想要使用托管服务，而不是基础结构即服务（IaaS）。
优点
- 相对简单的体系结构，易于理解。
- 易于部署和管理。
- 明确分离关注点。
- 前端使用异步消息传送与辅助角色分离。
- 前端和辅助角色可以独立缩放。
挑战
- 如果不仔细设计，前端和辅助角色可能会变成难以维护和更新的大型整体组件。
- 如果前端和辅助角色共享数据架构或代码模块，则可能存在隐藏的依赖项。
- 成功保存到数据库后，Web 前端可能会发生故障，但在将消息发送到队列之前。 这可能会导致可能的一致性问题，因为辅助角色不会执行其部分逻辑。 事务发件箱模式等技术可用于帮助缓解此问题，但需要将传出消息的路由更改为第一个通过单独的队列“环回”。 提供此技术支持的一个库是 NServiceBus 事务会话。
最佳做法
- 向客户端公开设计良好的 API。 请参阅 API 设计最佳做法。
- 自动缩放以处理负载更改。 请参阅
自动缩放最佳做法。 - 缓存半静态数据。 请参阅 缓存最佳做法。
- 使用 CDN 托管静态内容。 请参阅 CDN 最佳做法。
- 适当时使用 polyglot 持久性。 请参阅[为作业使用最佳数据存储][polyglot]。
- 对数据进行分区以提高可伸缩性、减少争用并优化性能。 请参阅 数据分区最佳做法。
Azure 应用服务上的 Web-Queue-Worker
本部分介绍使用 Azure 应用服务的推荐 WebQueue-Worker 体系结构。
下载此体系结构的 Visio 文件。
工作流程
前端作为 Azure 应用服务 Web 应用实现，辅助角色作为 Azure Functions 应用实现。 Web 应用和函数应用都与提供 VM 实例的应用服务计划相关联。
可以将 Azure 服务总线 或 Azure 存储队列 用于消息队列。 （此图显示了 Azure 存储队列。
Azure Redis 缓存 存储会话状态和其他需要低延迟访问的数据。
Azure CDN 用于缓存静态内容，例如图像、CSS 或 HTML。
对于存储，请选择最适合应用程序需求的存储技术。 可以使用多个存储技术（polyglot 持久性）。 为了说明这一想法，此图显示了 Azure SQL 数据库 和 Azure Cosmos DB。
有关详细信息，请参阅 应用服务 Web 应用程序参考体系结构 ，以及如何 使用 NServiceBus 和 Azure 服务总线生成消息驱动的业务应用程序。
其他注意事项
并非每个事务必须经过队列和辅助角色才能存储。 Web 前端可以直接执行简单的读/写作。 辅助角色专为资源密集型任务或长时间运行的工作流而设计。 在某些情况下，可能根本不需要辅助角色。
使用应用服务的内置自动缩放功能横向扩展 VM 实例数。 如果应用程序的负载遵循可预测的模式，请使用基于计划的自动缩放。 如果负载不可预知，请使用基于指标的自动缩放规则。
请考虑将 Web 应用和函数应用放入单独的应用服务计划中。 这样，就可以独立缩放它们。
使用单独的应用服务计划进行生产和测试。 否则，如果对生产和测试使用相同的计划，则意味着测试在生产 VM 上运行。
使用部署槽位管理部署。 此方法允许将更新的版本部署到过渡槽，然后交换到新版本。 如果更新出现问题，它还允许你交换回以前的版本。