本文主要內(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è)新名詞萝挤，但它的理念由來已久御毅。
BFF 解決了什么問題
如下圖，在我們的前端頁面時(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 層儒洛，這樣可以只暴露必要信息給第三方精耐，從而便于控制第三方的訪問。
