編輯

共用方式為


Web-Queue-Worker 架構樣式

Azure App Service

此架構的核心元件是 提供用戶端要求的 Web 前端 ,以及 執行資源密集型工作、長時間執行的工作流程或批次作業的背景工作 。 Web 前端會透過 消息佇列與背景工作角色通訊。

Logical diagram of Web-Queue-Worker architecture style.

通常併入此架構的其他元件包括:

  • 一或多個資料庫。
  • 快取,用來儲存資料庫中的值以進行快速讀取。
  • 提供靜態內容的CDN
  • 遠端服務,例如電子郵件或簡訊服務。 這些功能通常是由第三方提供。
  • 用於驗證的識別提供者。

Web 和背景工作角色都是無狀態的。 會話狀態可以儲存在分散式快取中。 背景工作會以異步方式完成任何長時間執行的工作。 背景工作角色可由佇列上的訊息觸發,或依排程執行批處理。 背景工作角色是選擇性元件。 如果沒有長時間執行的作業,則可以省略背景工作角色。

前端可能包含 Web API。 在用戶端上,Web API 可以透過單頁應用程式來取用,讓AJAX呼叫,或由原生用戶端應用程式取用。

使用此架構的時機

Web-Queue-Worker 架構通常會使用受控計算服務來實作,Azure App 服務 或 Azure 雲端服務。

請考慮下列架構樣式:

  • 具有相對簡單網域的應用程式。
  • 具有某些長時間執行工作流程或批次作業的應用程式。
  • 當您想要使用受控服務,而不是基礎結構即服務時(IaaS)。

福利

  • 相對簡單的架構很容易理解。
  • 容易部署及管理。
  • 清楚區分關注點。
  • 前端會使用異步傳訊與背景工作角色分離。
  • 前端和背景工作角色可以獨立調整。

挑戰

  • 如果沒有仔細的設計,前端和背景工作角色可能會變成難以維護和更新的大型整合型元件。
  • 如果前端和背景工作角色共用數據架構或程式碼模組,可能會有隱藏的相依性。
  • Web 前端在成功保存至資料庫之後,但在將訊息發出至佇列之前,可能會故障。 這可能會導致可能的一致性問題,因為背景工作角色不會執行其邏輯的一部分。 交易式寄件匣模式技術可用來協助減輕此問題,但需要將傳出訊息的路由變更為透過個別佇列的第一個「回送」。 提供這項技術支援的其中一個連結庫是 NServiceBus 交易式會話

最佳作法

Azure App 服務 上的Web-Queue-Worker

本節描述使用 Azure App 服務 的建議 Web-Queue-Worker 架構。

Physical diagram of Web-Queue-Worker architecture style.

下載此架構的 Visio 檔案

工作流程

如需詳細資訊,請參閱 App Service Web 應用程式參考架構,以及如何使用 NServiceBus 和 Azure 服務匯流排 建置訊息驅動商務應用程式。

其他考量

  • 並非所有交易都必須通過佇列和背景工作角色至記憶體。 Web 前端可以直接執行簡單的讀取/寫入作業。 背景工作是針對需要大量資源的工作或長時間執行的工作流程所設計。 在某些情況下,您完全不需要背景工作角色。

  • 使用 App Service 的內建自動調整功能來相應放大 VM 實例數目。 如果應用程式的負載遵循可預測的模式,請使用以排程為基礎的自動調整。 如果負載無法預測,請使用以計量為基礎的自動調整規則。

  • 請考慮將 Web 應用程式和函式應用程式放入個別的 App Service 方案。 如此一來,就可以獨立調整它們。

  • 使用個別的 App Service 方案進行生產與測試。 否則,如果您使用相同的生產與測試計劃,這表示您的測試是在生產 VM 上執行。

  • 使用部署位置來管理部署。 這個方法可讓您將更新的版本部署到預備位置,然後交換至新版本。 如果更新發生問題,它也可讓您交換回舊版。