微服務架構設計-Backend For Frontend Pattern(BFF)

前言

介紹 BFF 之前我們先講一下 Client 與 Microservices 直接溝通，我們知道微服務有很多的不同的服務，它們的端點也四散在各處，那當今天網頁或是 App 要存取，就要對各自的端點做請求，看似簡單暴力但也衍伸了許多問題，因此現代很少會使用這種溝通方式

Direct Client-To-Microservices 問題

Client 與服務高耦合
Client 與服務高網路依賴 - 可能造成延遲
服務全都暴露給 Client 的安全性問題
所有接觸 Client 的服務都要做相同的事情，比如驗證

API Gateway Pattern

由於 Direct Client-To-Microservices 出現了太多問題，後來多數人都使用 API Gateway Pattern 只有單一端口對 Client 開放，有以下特色

反向代理
可做 Redirect 將 Client 與 Microservices 解耦
請求聚合，減少網路溝通成本
通用邏輯都集中在 Gateway 處理

API Gateway Pattern 問題

儘管 API Gateway Pattern 看似解決了 Direct Client-To-Microservices 很多問題，但還是有很多隱患

產生單點故障問題 - 單一節點故障造成整個系統癱瘓
Client 與 Services 多一層 Gateway 可能造成網路延遲
架構變複雜
需要由專門的團隊來開發與維護 Gateway

Backend-For-Frontend Pattern

BFF Pattern 就是來解決 API Gateway Pattern 所帶來的問題的
當 Client 的種類越來越多(手機、網頁、桌面應用程式)，他們都需要單一的端點可能產生一些問題，原因在於每個 Client 所需的格式可能不同(如 App 需要輕量便捷的設計因此資料結構相較於桌面應用程式簡略)，當然遇到這種問題我們可以對 API Gateway 進行額外處理，但是這樣讓架構變得更複雜也不容易擴展，當有新的 Client 種類就要重新添加

因此後來出現了 BFF Pattern 主要的理念是根據 UX 使用者體驗做 API 切分，也就是說對於不同裝置設置不同的 Proxy Server

Backend-For-Frontend Pattern 優點

更容易根據 Client 進行調整 API
每個 Proxy 更容易針對 Client 進行發展，容易維護與擴展

理想狀況是每個 Client Dev Team 負責自已的 BFF Proxy，更能對於 Client 進行反應與改變，Backend Team 就只需要針對系統業務進行開發即可

參考資料

前端開發者該負責寫 API Endpoints 嗎？The Backend For Frontend Pattern (BFF) In Microservices World

System-Architecture