1. 這種架構的核心組件包含：
2. 一個Web前端，用戶可以通過這里發送請求
3. 一個worker服務，它可以執行資源密集型任務、耗時的工作流或批處理作業。

Web前端和worker服務通過一個消息隊列進行通信。

這個架構中還包含其它一些組件：

• 一個/多個數據庫
• KV Cache，用來降低數據庫的負載
• CDN系統，提供靜態資源的訪問加速
• 遠程服務，比如email或消息發送服務，通常是第三方的服務
• 身份認證服務，比如Google Oauth登錄服務

Web前端和worker服務都是無狀態的。作業的會話狀態通常存儲在分布式存儲里（比如Redis集群）。worker通過異步的方式處理耗時的作業，我們通常使用消息隊列來觸發作業的創建和執行，或者通過一個定時任務調度批處理任務。worker并不是必須的，如果沒有耗時的操作，就不需要它。

前端除了頁面的部分，也可以提供web API（BFF層）。在client端，我們可以通過一個單頁應用觸發ajax請求，或者使用原生的APP去觸發。

應用場景

Web-Queue-worker架構在云服務中很常見，比如函數計算服務（FAAS）。這類服務通常會提供 HTTP API 或 RPC API，同時支持消費Kafka來的流式消息。目前流行的低代碼也是由此衍生出來的。

該架構適用于以下的場景：

• 應用的業務領域/場景比較簡單
• 應用包含了一些耗時的工作流或批處理任務；
• 想要低成本地接入現有的服務，而不是從Infra開始搭建

架構優勢

• 架構簡單易懂；
• 部署和管理很簡單；
• 服務職能邊界清晰；
• 前端和worker是解耦的，消息隊列使用現成的技術即可；
• 前端和worker可以獨立進行擴容；

有哪些挑戰

• 如果設計不合理，前端和worker都可能融入太多的邏輯，變得越來越重。后期演變成單體架構后，很難維護和升級；
• 如果前端和worker共享了一些數據結構或代碼，可能會有隱藏的依賴；

最佳實踐

• 暴露給client的API必須清晰明了，經過良好的設計；對于HTTP請求，可以遵循REST協議；
• 對于工作負載的變化，啟動自動擴縮容；云平臺和K8s都提供了監控實例CPU/內存自動擴縮容的能力；
• 對于半靜態的數據，使用緩存進行加速訪問；比如memcached/memory cache等；
• 使用CDN對靜態資源進行緩存加速；
• 根據需求使用混合持久化方案。比如關系數據庫和非關系型數據庫混合使用，比如KV存儲、文檔數據庫、搜索數據庫、時序數據庫、列式存儲數據庫、圖數據庫等。數據庫之間，可以采用最終一致性方案進行數據同步；
• 對數據進行分區，分區可以更好地支持擴容，減少競爭讀寫問題，提升訪問性能。