BFF是（Backends For Frontends）單詞的縮寫，主要是用於服務前端的後臺應用程式，來解決多訪問終端業務耦合問題。

最近在公司的微服務架構中遇到了一些多終端訪問介面的問題，不同的終端擁有不同的介面服務，有不同的操作資料的能力，針對這種業務場景做出了調研，我們是否可以在不同的訪問層進行業務邏輯處理，獲取不同的資料內容呢？

早在微服務出現的初期就已經存在類似的業務需求出現，而且衍生出了一套成熟的解決方案，那就是BFF，可以針對不用業務場景來提供對應的服務介面，每一種業務場景之間完全獨立。

演進過程

在傳統的應用程式中，我們一般只將介面提供給一種型別的終端使用。

單端呼叫基礎服務

傳統的應用程式內提供的介面是有業務針對性的，這種型別的介面如果獨立出來再提供給別的系統再次使用是一件比較麻煩的事情，設計初期的高耦合就決定了這一點。

多端直接呼叫基礎服務

如果我們的介面同時提供給web、移動端使用，移動端僅用來採集資料以及資料的展示，而web端大多數場景是用來管理資料，因為不同端點的業務有所不同每一個端的介面複用度不會太高。

多端共用一個BFF

針對多端共用服務介面的場景，我們將基礎的資料服務與BFF進行了分離，資料服務僅提供資料的增刪改查，並不過多涉及業務的判斷處理，所有業務判斷處理都交給BFF來把控，遇到的一些業務邏輯異常也同樣由BFF格式化處理後展示給訪問端點。

這種設計方式同樣存在一定的問題，雖然基礎服務與BFF進行了分離，我們只需要在BFF層面進行業務判斷處理，但是多個端共用一個BFF，也會導致程式碼編寫複雜度增高、程式碼可閱讀性降低、多端業務耦合。

每個端提供一個BFF

如果我們為每一個端點都提供一個BFF，每個端點的BFF處理自身的業務邏輯，需要資料時從基礎服務內獲取，然後在介面返回之前進行組裝資料用於例項化返回物件。

這樣基礎服務如果有新功能新增，BFF幾乎不會受到影響，而我們如果後期把App端點進行拆分成Android、IOS時我們只需要將app-bff進行拆分為android-bff、ios-bff，基礎服務同樣也不會受到影響

這樣每當新增一個訪問端點時，我們需要修改的地方也只有閘道器的轉發

總結

在微服務架構設計中，BFF起到了一個業務聚合的關鍵作用，可以 通過openfeign、restTemplate呼叫基礎服務來獲取資料，將獲取到的資料進行組裝返回結果物件，BFF解決了業務場景問題，也同樣帶來了一些問題，如下所示：

• 響應時間延遲（服務如果是內網之間訪問，延遲時間較低）
• 編寫起來較為浪費時間（因為在基礎服務上新增的一層轉發，所以會多寫一部分程式碼）
• 業務異常處理（統一格式化業務異常的返回內容）
• 分散式事務（微服務的通病）