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

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

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

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

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

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

應用場景

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

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

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

架構優(yōu)勢

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

有哪些挑戰(zhàn)

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

最佳實踐

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