此架構的核心元件是處理客戶端請求的 網頁前端 ，以及執行資源密集型任務、長時間執行工作流程或批次工作的工作 者 。 網頁前端透過 訊息隊列與工作者溝通。
以下元件通常會被納入此架構中：
一個或多個資料庫
一個快取，用來儲存資料庫中的數值以便快速讀取
一個內容傳遞網路，用來提供靜態內容
非 Microsoft 服務提供者通常提供的遠端服務，如電子郵件或短訊服務（SMS）
身份驗證提供者
網頁與工作者皆為無狀態，會話狀態可儲存在分散式快取中。 工作者以非同步方式處理長期工作。 佇列中的訊息可以啟動工作進程，或者可以透過排程來執行進行批次處理。 若應用程式沒有長期執行的操作，則該工作者為可選。
前端可能會包含網頁 API。 單頁應用程式可以透過呼叫 AJAX 來使用網頁 API，或是原生客戶端應用程式可以直接使用它。
使用此架構的時機
Web-Queue-Worker 架構通常透過管理運算服務如 Azure App Service 或 Azure Kubernetes Service 來實作。
請考慮以下使用情境的架構：
具有相對簡單領域的應用
具有長時間執行工作流程或批次操作的應用程式
你偏好管理服務而非基礎設施即服務（IaaS）的情境
優點
一個簡單易懂的架構
最小化工作量的部署與管理
明確的職責分離
透過非同步訊息將前端與工作端分離
前端與工人的獨立縮放
挑戰
若設計不慎，前端與工人可能成為龐大且難以維護與更新的單一元件。
如果前端和工作型共用資料結構或程式碼模組，可能會有隱藏的相依關係。
網頁前端在持續存在資料庫後，但在將訊息送入佇列前可能會失敗，這會造成一致性問題，因為工作者沒有執行其邏輯部分。 為了緩解這個問題，你可以使用例如交易型外寄匣模式（Transactional Outbox pattern）的方法，要求先將外發訊息繞回至獨立佇列。 NServiceBus 交易會話函式庫支援此技術。
最佳做法
向客戶端展示一個設計良好的 API。 欲了解更多資訊，請參閱 API 設計最佳實務。
自動調整以應對負載變化。 如需詳細資訊，請參閱 自動擴展最佳實務。
快取半靜態資料。 如需詳細資訊，請參閱 快取最佳實務。
使用內容傳遞網路來架設靜態內容。 欲了解更多資訊，請參閱 內容傳遞網路最佳實務。
適當時使用多語持續性。 欲了解更多資訊，請參閱 「了解資料模型」。
分割資料以提升可擴展性、減少爭用並優化效能。 欲了解更多資訊，請參閱 資料分割最佳實務。
Web（網頁）- App Service 上的 Queue-Worker（佇列工作者）
本節描述一種推薦的 WebQueue-Worker 架構，採用 App Service。
下載此架構的 Visio 檔案。
Workflow
前端是以 App Service 網頁應用程式實作，工作端則是以 Azure Functions 應用程式實作。 網頁應用程式與函式應用程式皆與提供虛擬機（VM）實例的 App Service 計畫相關聯。
你可以使用 Azure Service Bus 或 Azure Storage 佇列 來做訊息佇列。 前一圖使用儲存佇列。
Azure Managed Redis 儲存會話狀態及其他需要低延遲存取的資料。
Azure 內容傳遞網路 用於快取靜態內容，如圖片、CSS 或 HTML。
儲存方面，選擇最適合你應用需求的技術。 這種方法稱為 多語持續性，在同一系統中使用多種儲存技術以滿足不同需求。 為了說明這個概念，圖中同時展示了 Azure SQL 資料庫 和 Azure Cosmos DB。
欲了解更多資訊，請參閱 基線高可用的區域冗餘網頁應用程式，以及 使用 NServiceBus 與服務匯流排建構訊息導向的商業應用程式。
其他考慮
並非每筆交易必須經過排隊和工作程序才能儲存。 網頁前端可以直接執行簡單的讀寫操作。 Workers 是為資源密集型任務或長時間工作流程而設計的。 有時候，你甚至根本不需要工人。
利用你計算平台內建的自動縮放功能，來縮小實例數量。 如果應用程式負載遵循可預測的模式，則使用基於排程的自動縮放。 如果負載無法預測，就使用基於指標的自動縮放。
考慮將網頁應用程式和功能應用程式分成不同的應用程式服務方案，讓它們能夠獨立擴展。
在生產和測試時使用不同的 App Service 計畫。
使用部署插槽來管理部署。 這種方法可以讓你先部署更新版本到暫存槽，然後切換到新版本。 如果更新過程中出現問題，也能切換回先前版本。