此架構的核心元件是 提供用戶端要求的 Web 前端 ，以及 執行資源密集型工作、長時間執行的工作流程或批次作業的背景工作 。 Web 前端會透過 消息佇列與背景工作角色通訊。
通常併入此架構的其他元件包括：
- 一或多個資料庫。
- 快取，用來儲存資料庫中的值以進行快速讀取。
- 提供靜態內容的CDN
- 遠端服務，例如電子郵件或簡訊服務。 這些功能通常是由第三方提供。
- 用於驗證的識別提供者。
Web 和背景工作角色都是無狀態的。 會話狀態可以儲存在分散式快取中。 背景工作會以異步方式完成任何長時間執行的工作。 背景工作角色可由佇列上的訊息觸發，或依排程執行批處理。 背景工作角色是選擇性元件。 如果沒有長時間執行的作業，則可以省略背景工作角色。
前端可能包含 Web API。 在用戶端上，Web API 可以透過單頁應用程式來取用，讓AJAX呼叫，或由原生用戶端應用程式取用。
使用此架構的時機
Web-Queue-Worker 架構通常會使用受控計算服務來實作，Azure App 服務 或 Azure 雲端服務。
請考慮下列架構樣式：
- 具有相對簡單網域的應用程式。
- 具有某些長時間執行工作流程或批次作業的應用程式。
- 當您想要使用受控服務，而不是基礎結構即服務時（IaaS）。
福利
- 相對簡單的架構很容易理解。
- 容易部署及管理。
- 清楚區分關注點。
- 前端會使用異步傳訊與背景工作角色分離。
- 前端和背景工作角色可以獨立調整。
挑戰
- 如果沒有仔細的設計，前端和背景工作角色可能會變成難以維護和更新的大型整合型元件。
- 如果前端和背景工作角色共用數據架構或程式碼模組，可能會有隱藏的相依性。
- Web 前端在成功保存至資料庫之後，但在將訊息發出至佇列之前，可能會故障。 這可能會導致可能的一致性問題，因為背景工作角色不會執行其邏輯的一部分。 交易式寄件匣模式等技術可用來協助減輕此問題，但需要將傳出訊息的路由變更為透過個別佇列的第一個「回送」。 提供這項技術支援的其中一個連結庫是 NServiceBus 交易式會話。
最佳作法
- 將設計良好的 API 公開給用戶端。 請參閱 API 設計最佳做法。
- 自動調整以處理負載中的變更。 請參閱 自動調整最佳做法。
- 快取半靜態數據。 請參閱 快取最佳做法。
- 使用CDN來裝載靜態內容。 請參閱 CDN最佳做法。
- 適當時使用polyglot持續性。 請參閱 [使用作業的最佳數據存放區][polyglot]。
- 分割數據以改善延展性、減少爭用，以及優化效能。 請參閱 數據分割最佳做法。
Azure App 服務 上的Web-Queue-Worker
本節描述使用 Azure App 服務 的建議 Web-Queue-Worker 架構。
工作流程
前端會實作為 Azure App 服務 Web 應用程式，而背景工作角色會實作為 Azure Functions 應用程式。 Web 應用程式和函式應用程式都與提供 VM 實例的 App Service 方案相關聯。
您可以使用消息佇列的 Azure 服務匯流排 或 Azure 儲存體 佇列。 （圖表顯示 Azure 儲存體 佇列。
Azure Cache for Redis 會儲存會話狀態和其他需要低延遲存取的數據。
Azure CDN 可用來快取靜態內容，例如影像、CSS 或 HTML。
針對記憶體，請選擇最符合應用程式需求的記憶體技術。 您可以使用多個儲存技術（polyglot 持續性）。 為了說明這個想法，此圖顯示 Azure SQL 資料庫 和 Azure Cosmos DB。
如需詳細資訊，請參閱 App Service Web 應用程式參考架構，以及如何使用 NServiceBus 和 Azure 服務匯流排 建置訊息驅動商務應用程式。
其他考量
並非所有交易都必須通過佇列和背景工作角色至記憶體。 Web 前端可以直接執行簡單的讀取/寫入作業。 背景工作是針對需要大量資源的工作或長時間執行的工作流程所設計。 在某些情況下，您完全不需要背景工作角色。
使用 App Service 的內建自動調整功能來相應放大 VM 實例數目。 如果應用程式的負載遵循可預測的模式，請使用以排程為基礎的自動調整。 如果負載無法預測，請使用以計量為基礎的自動調整規則。
請考慮將 Web 應用程式和函式應用程式放入個別的 App Service 方案。 如此一來，就可以獨立調整它們。
使用個別的 App Service 方案進行生產與測試。 否則，如果您使用相同的生產與測試計劃，這表示您的測試是在生產 VM 上執行。
使用部署位置來管理部署。 這個方法可讓您將更新的版本部署到預備位置，然後交換至新版本。 如果更新發生問題，它也可讓您交換回舊版。