一、什么是BFF

最開始，我們還是先明確下BFF是什么吧，由于前文已經做過介紹了，這里就簡單的提一下。

BFF：Backends For Frontends（服務于前端的后端）。

BFF是一種Web架構，微服務設計系列叢書的作者 Sam Newman曾在他的博客中寫了一篇相關文章《Pattern: Backends For Frontends》。

BFF 的概念最初就是來源于此。

圖片

服務端設計API時會考慮到不同設備的需求，即為不同設備提供不同API接口，雖然它們可能實現相同功能，但因不同設備的特殊性，它們對服務端的API訪問也各有其特點，需區(qū)別處理。在計算機科學中，所有問題都可以通過加一層來解決，于是 BFF 架構設計應運而生。

2. BFF的胖瘦之爭

在現代軟件開發(fā)中，服務化可能是解決大型復雜應用的必然之路，BFF 架構已成為構建高效、靈活前端應用的重要手段之一。

在服務化的系統中規(guī)劃階段，有一些必然會被討論的話題：

要不要 BFF 層? 要不要編排層？

要不要網關？什么是網關？

應用網關和網關的區(qū)別是什么？

后端（領域服務）服務之間要不要互相調用？

要不要使用 BFF 來編排后端服務？

BFF 是不是編排層？

BFF 能不能宏觀上對應 DDD 的應用層？

......

在上面這些問題中，最讓人關心的問題倒不是響應用戶請求流量的服務叫是 ServiceA 還是 ServiceB，而是它應該直接轉發(fā)數據還是需要為每個 API 重新編寫一次實現，并調用后端 API。

然而，對于 BFF 架構的設計，存在著 “胖” 與 “瘦” 的不同考量，這會決定我們在 BFF 中是否需要編寫大量代碼，所以我把它們的區(qū)別稱之為"胖瘦 BFF"。

概括而言：不同 BFF 的考量會決定微服務架構的兩種形態(tài)。

3. 胖 BFF

在有一些架構形態(tài)中，BFF 會有以下職責：

• 鑒權
• 限流、熔斷、服務降級、灰度路由等
• 接入多種協議和設備，比如 MQTT 服務、WebSocket 等
• 編排領域服務，盡量避免后端服務之間互相依賴，統一由 BFF 處理
• 不同類型的客戶端一套 BFF
• 非常接近 DDD 四層架構中的應用層，處理面向場景的業(yè)務

因為它的職責比較多，我們暫且稱其為：胖 BFF。

胖 BFF 的特點是：

• 強大的業(yè)務邏輯處理能力：胖 BFF 架構不僅可以進行數據轉換，還可以承擔更多的業(yè)務邏輯處理。它可以整合多個后端服務的數據，進行復雜的計算和業(yè)務規(guī)則校驗。
• 高度定制化：能夠根據不同的前端需求進行深度定制，為不同的用戶界面提供個性化的數據和服務。
• 更好的性能優(yōu)化：可以對數據進行緩存、預取等優(yōu)化操作，提高前端應用的性能。

胖 BFF 的好處是：

• 可以對不同類型的客戶端定制一套 API，且各自之間不受干擾
• 領域服務可以設計得比較原子化，比較少的侵入特定場景信息到領域服務中
• 容易適配更多類型的客戶端
• 比較容易實現個性化的鑒權、特定用戶群的交互邏輯
• 方便實現準確、統一的 API 文檔

但是這類架構也有非常多的弊端，導致很多架構師非常抗拒：

• 破壞了端到端交付能力，如果按照上下文劃分微服務，剛好這些微服務和前端業(yè)務和需求對應，那么跨功能團隊的交付效率會更高
• 重復勞動，一些接口的模型不僅在領域服務實現一次，還需要在 BFF 做一次
• 難以分工，維護后端服務的人員都會和這個服務集成

在海外的一些文章和書籍中，他們也會有類似的困惑。很多架構師把這種結構叫做編排（Orchestration）。

圖片

4. 瘦 BFF

相對而言，瘦 BFF 架構，其職責可能更少：

• 鑒權
• 透明轉發(fā)流量到后端服務
• 和胖 BFF 類似，也有限流、熔斷、服務降級、灰度路由等職責

瘦 BFF 的特點：

• 簡潔高效：瘦 BFF 架構專注于將后端服務的數據進行輕量級的轉換和適配，以滿足前端的需求。它通常只進行必要的數據篩選、格式轉換和簡單的業(yè)務邏輯處理。
• 快速響應：由于功能相對簡單，瘦 BFF 可以快速響應前端的請求，減少延遲，提高用戶體驗。
• 易于維護：代碼量較少，結構清晰，使得維護成本相對較低。開發(fā)人員可以更容易地理解和修改代碼，快速定位和解決問題。

瘦 BFF 的好處是：

• 端到端交付，前端開發(fā)人員直接使用后端領域服務的 API 文檔
• 開發(fā)效率高，避免多編寫一層 BFF
• 減少一次集成

對應的，瘦 BFF 的弊端可想而知：

• 沒有編排層，服務之間相互依賴
• 編排行為落入前端或者領域服務，拓展性差
• 領域服務之間調用關系復雜
• 領域服務職責過多，侵入業(yè)務場景，難以被復用

這樣的話，BFF 僅僅扮演轉發(fā)的作用，也就成了我們口中的網關。

圖片

5. 兩種形態(tài)的權衡

那么在什么場景下，更合理的選擇這兩種結構之一呢？

• 1. 業(yè)務需求

如果業(yè)務邏輯簡單，數據交互相對較少，瘦 BFF 可能就足夠滿足需求。但如果業(yè)務復雜，需要進行大量的業(yè)務邏輯處理和數據整合，胖 BFF 則更為合適。

• 2. 開發(fā)團隊規(guī)模和技能

瘦 BFF 相對容易開發(fā)和維護，適合小型開發(fā)團隊或技術能力有限的團隊。而胖 BFF 需要更高的技術水平和更多的開發(fā)資源，適合有經驗的大型開發(fā)團隊。

• 3. 項目周期和迭代速度

對于短期項目或需要快速迭代的項目，瘦 BFF 可以更快地實現并投入使用。而胖 BFF 的開發(fā)周期可能較長，但在長期運行中可以提供更好的性能和可維護性。

• 4. 可擴展性

考慮未來業(yè)務的發(fā)展和擴展需求。如果預計業(yè)務會不斷增長，功能會逐漸復雜，選擇胖 BFF 可以為未來的擴展提供更好的基礎。

圖片

6. 總結

總之，BFF 架構的胖瘦之分并沒有絕對的標準，需要根據具體的項目需求、業(yè)務特點和開發(fā)團隊情況進行綜合考慮。

無論是胖瘦 BFF，其實都是基于場景對單體系統拆分的結果，非常依賴于所屬場景。

在實際應用中，可以根據不同的階段和需求，靈活地調整 BFF 的設計，以實現最佳的用戶體驗和系統性能，這也解釋了關于 BFF 為什么目前還沒有形成統一的技術方案和觀念。