本文主要內(nèi)容：

• 什么是 BFF
• BFF 解決了什么問題
• 使用 BFF 的正確姿勢
• 實戰(zhàn)中的玩法

什么是 BFF

BFF，即 Backend For Frontend（服務(wù)于前端的后端），也就是服務(wù)器設(shè)計 API 時會考慮前端的使用，并在服務(wù)端直接進行業(yè)務(wù)邏輯的處理，又稱為用戶體驗適配器。BFF 只是一種邏輯分層，而非一種技術(shù)，雖然 BFF 是一個新名詞，但它的理念由來已久。

如下圖，在我們的前端頁面時常存在，某個頁面需要向 backend A、backend B 以及 backend C...... 發(fā)送請求，不同服務(wù)的返回值用于渲染頁面中不同的 component，即一個頁面存在很多請求的場景。

此時，每次訪問該頁面都需要發(fā)送 3 個請求。同時為了保障 Android，iOS，以及 Web 端的不同需求，需要為不同的平臺寫不同的 API 接口，而每當值發(fā)生一些變化時，需要 Android，iOS，Web 做出修改。與此同時，當我們需要對一個字符串進行處理，如限定 140 個字符的時候，我們需要在每一個客戶端（Android，iOS，Web）分別實現(xiàn)一遍，這樣的代價顯然相當大。

于是，我們就需要 BFF 作為中間件。在這個中間件上我們將做一些業(yè)務(wù)邏輯處理：

而當我們有了 BFF 這一層時，我們就不需要考慮系統(tǒng)后端的遷移。后端發(fā)生的變化都可以在 BFF 層做一些響應(yīng)的修改。

例如，我們加入 BFF 層，原本每次訪問發(fā)送 3 請求頁面，變成一個請求。

使用 BFF 的正確姿勢

• 多端應(yīng)用
• 我們在設(shè)計 API 時會考慮到不同設(shè)備的需求，也就是為不同的設(shè)備提供不同的 API，雖然它們可能是實現(xiàn)相同的功能，但因為不同設(shè)備的特殊性，它們對服務(wù)端的 API 訪問也各有其特點，需要區(qū)別處理。
• 服務(wù)聚合
• 隨著微服務(wù)的興起，原本在同一個進程內(nèi)運行的業(yè)務(wù)流程被拆分到了不同的服務(wù)中。這在增加業(yè)務(wù)靈活性的同時，也讓前端的調(diào)用變得更復(fù)雜。BFF 的出現(xiàn)為前端應(yīng)用提供了一個對業(yè)務(wù)服務(wù)調(diào)用的聚合點，它屏蔽了復(fù)雜的服務(wù)調(diào)用鏈，讓前端可以聚焦在所需要的數(shù)據(jù)上，而不用關(guān)注底層提供這些數(shù)據(jù)的服務(wù)。
• 非必要，莫新增
• 我們在看到 BFF 帶來的各種好處的同時，也要注意到它所帶來的代碼重復(fù)和工作量增加方面的問題。如果與已有 BFF 功能類似，且展現(xiàn)數(shù)據(jù)的要求也相近的話，一定要謹慎對待新增 BFF 的行為。因此，建議非必要，莫新增。

實戰(zhàn)中的玩法

• 訪問控制
• 例如，服務(wù)中的權(quán)限控制，將所有服務(wù)中的權(quán)限控制集中在 BFF 層，使下層服務(wù)更加純粹和獨立。
• 應(yīng)用緩存
• 項目中時常存在一些需要緩存的臨時數(shù)據(jù)，此時 BFF 作為業(yè)務(wù)的匯聚點，距離用戶請求最近，遂將該緩存操作放在 BFF 層。
• 第三方入口
• 在業(yè)務(wù)中需要與第三交互時，將該交互放在 BFF 層，這樣可以只暴露必要信息給第三方，從而便于控制第三方的訪問。