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

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

什么是 BFF

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

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

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

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

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

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

使用 BFF 的正確姿勢(shì)

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

實(shí)戰(zhàn)中的玩法

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