初識BFF架構設計

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便可，基礎服務內提供的服務接口咱們徹底能夠複用，由於基礎服務提供的接口都是沒有業務針對性的！！！

總結

在微服務架構設計中，BFF起到了一個業務聚合的關鍵做用，能夠 經過openfeign、restTemplate調用基礎服務來獲取數據，將獲取到的數據進行組裝返回結果對象，BFF解決了業務場景問題，也一樣帶來了一些問題，以下所示：

• 響應時間延遲（服務若是是內網之間訪問，延遲時間較低）
• 編寫起來較爲浪費時間（由於在基礎服務上添加的一層轉發，因此會多寫一部分代碼）
• 業務異常處理（統一格式化業務異常的返回內容）
• 分佈式事務（微服務的通病）