本文主要內(nèi)容：
- 什么是 BFF
- BFF 解決了什么問(wèn)題
- 使用 BFF 的正確姿勢(shì)
- 實(shí)戰(zhàn)中的玩法
什么是 BFF
BFF，即 Backend For Frontend（服務(wù)于前端的后端），也就是服務(wù)器設(shè)計(jì) API 時(shí)會(huì)考慮前端的使用，并在服務(wù)端直接進(jìn)行業(yè)務(wù)邏輯的處理，又稱(chēng)為用戶(hù)體驗(yàn)適配器。BFF 只是一種邏輯分層，而非一種技術(shù)，雖然 BFF 是一個(gè)新名詞，但它的理念由來(lái)已久。
BFF 解決了什么問(wèn)題
如下圖，在我們的前端頁(yè)面時(shí)常存在，某個(gè)頁(yè)面需要向 backend A、backend B 以及 backend C...... 發(fā)送請(qǐng)求，不同服務(wù)的返回值用于渲染頁(yè)面中不同的 component，即一個(gè)頁(yè)面存在很多請(qǐng)求的場(chǎng)景。
此時(shí)，每次訪(fǎng)問(wèn)該頁(yè)面都需要發(fā)送 3 個(gè)請(qǐng)求。同時(shí)為了保障 Android，iOS，以及 Web 端的不同需求，需要為不同的平臺(tái)寫(xiě)不同的 API 接口，而每當(dāng)值發(fā)生一些變化時(shí)，需要 Android，iOS，Web 做出修改。與此同時(shí)，當(dāng)我們需要對(duì)一個(gè)字符串進(jìn)行處理，如限定 140 個(gè)字符的時(shí)候，我們需要在每一個(gè)客戶(hù)端（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ǎng)問(wèn)發(fā)送 3 請(qǐng)求頁(yè)面，變成一個(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 訪(fǎng)問(wèn)也各有其特點(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 帶來(lái)的各種好處的同時(shí)，也要注意到它所帶來(lái)的代碼重復(fù)和工作量增加方面的問(wèn)題。如果與已有 BFF 功能類(lèi)似，且展現(xiàn)數(shù)據(jù)的要求也相近的話(huà)，一定要謹(jǐn)慎對(duì)待新增 BFF 的行為。因此，建議非必要，莫新增。
實(shí)戰(zhàn)中的玩法
訪(fǎng)問(wèn)控制
例如，服務(wù)中的權(quán)限控制，將所有服務(wù)中的權(quán)限控制集中在 BFF 層，使下層服務(wù)更加純粹和獨(dú)立。應(yīng)用緩存
項(xiàng)目中時(shí)常存在一些需要緩存的臨時(shí)數(shù)據(jù)，此時(shí) BFF 作為業(yè)務(wù)的匯聚點(diǎn)，距離用戶(hù)請(qǐng)求最近，遂將該緩存操作放在 BFF 層。第三方入口
在業(yè)務(wù)中需要與第三交互時(shí)，將該交互放在 BFF 層，這樣可以只暴露必要信息給第三方，從而便于控制第三方的訪(fǎng)問(wèn)。
