BFF是近些年新衍生出來的一種開發(fā)模式，或者說是一種適配模式的系統(tǒng)，BFF全稱為Backend OF Front意為后端的前端，為了適配微服務(wù)模式下前端后端系統(tǒng)接口調(diào)用混亂而出現(xiàn)的。在如今微服務(wù)盛行的趨勢下，大型系統(tǒng)中劃分出了數(shù)十個(gè)服務(wù)模塊，例如商品，門店，運(yùn)費(fèi)，紅包，訂單，優(yōu)惠券，CMS，用戶，搜索，推薦，廣告等等系統(tǒng)，前端也有小程序，APP，網(wǎng)頁等端。由此產(chǎn)生了很多問題：

痛點(diǎn)

1. 前端問題：每次需求開發(fā)前端要對接多個(gè)系統(tǒng)來確認(rèn)接口信息，不同的數(shù)據(jù)要找不同的系統(tǒng)，各個(gè)接口散落一地，開發(fā)調(diào)試的效率極低。
2. 后端問題：后端同樣也需要各自包裝數(shù)據(jù)信息來提供前端處理，重心變成如何為前端提供數(shù)據(jù)，因?yàn)樾枰鶕?jù)不同的版本、客戶端、用戶、定位等特征來判別，很多時(shí)間浪費(fèi)在展示層，而不能專注于業(yè)務(wù)邏輯處理，每個(gè)后端系統(tǒng)各自為戰(zhàn)，都有自己的接口規(guī)則，各種歷史版本問題都不能完全統(tǒng)一，所有系統(tǒng)都嚴(yán)重耦合了版本問題。
3. 變更不靈活：當(dāng)產(chǎn)品想要更新需求時(shí)，更是牽一發(fā)而動(dòng)全身，某一塊的小改動(dòng)需要在各個(gè)系統(tǒng)之間找接口來回溝通，大部分系統(tǒng)都要重新上線一次。

如下面，前后端的溝通鏈路過多。

BFF網(wǎng)關(guān)定位

鑒于此痛點(diǎn)，需要一個(gè)中間層來適配前后端服務(wù)，BBF由此而生，它負(fù)責(zé)將所有下游后端接口進(jìn)行統(tǒng)一調(diào)用，下游接口只需要提供RPC接口供網(wǎng)關(guān)使用，BFF網(wǎng)關(guān)提供WEB接口來讓前端調(diào)用，最后將數(shù)據(jù)進(jìn)行組裝拼接，根據(jù)前端的需求來返回?cái)?shù)據(jù)。

所以BFF的核心定位就是：“統(tǒng)一下游接口，為前端提供服務(wù)”。

只有把握好服務(wù)這個(gè)概念，才能做好BFF網(wǎng)關(guān)系統(tǒng)，其他系統(tǒng)可以扯皮甩鍋，但BFF網(wǎng)關(guān)不可以，它與生俱來的使命就是把這兩邊拉扯起來，所有不合理不合適，繁瑣無用的邏輯都需要BFF網(wǎng)關(guān)去處理，后端只要做好業(yè)務(wù)邏輯，前端做好展示，其他的都可以交給BFF網(wǎng)關(guān)。

BFF網(wǎng)關(guān)特點(diǎn)

瑣碎

BFF網(wǎng)關(guān)主要為前端進(jìn)行服務(wù)，前端不關(guān)心版本、客戶端、定位、用戶身份等情況，只接收渲染數(shù)據(jù)即可，而這些邏輯都需要耦合到BFF網(wǎng)關(guān)中，以版本、客戶端、定位、用戶等特征作為緯度，其中版本最為最復(fù)雜的分支，可能貫徹整個(gè)系統(tǒng)生涯幾十個(gè)版本類型都需要做兼容，由此還需要兼顧不同客戶端的展示要求和用戶特征，所以BFF網(wǎng)關(guān)中必然需要做大量判斷分支，根據(jù)上百種情況組合判斷來生成-唯一版本-唯一端-唯一用戶的數(shù)據(jù)結(jié)構(gòu)。

數(shù)據(jù)瑣碎

BFF不需要數(shù)據(jù)庫，這點(diǎn)會(huì)在下面說明，所以有很多數(shù)據(jù)需要以靜態(tài)變量的形式存放在代碼里，或者是使用配置中心來動(dòng)態(tài)配置，例如圖片地址、各種色值、模塊固定文字、處理標(biāo)識(shí)等，這些瑣碎的數(shù)據(jù)都會(huì)存放在BFF網(wǎng)關(guān)中進(jìn)行維護(hù)，如果放在前端，修改時(shí)必須要進(jìn)行發(fā)版，時(shí)間周期太長，而存放在后端的話，又會(huì)打散數(shù)據(jù)，不能從一個(gè)地方作為主要數(shù)據(jù)窗口進(jìn)行管理。

邏輯瑣碎

衍生第一點(diǎn)說到的，BFF網(wǎng)關(guān)作為下游接口的聚合，每次流程需要調(diào)用數(shù)十個(gè)后端接口，再根據(jù)版本、端、用戶進(jìn)行邏輯處理，歷史邏輯與新需求雜糅在一起，實(shí)現(xiàn)新功能的同時(shí)要不斷兼顧歷史邏輯，只能是加入大量的分支判斷，最后變成了if大爆炸，或者使用策略模式進(jìn)行優(yōu)化，但無論如何怎么包裝都無法掩蓋瑣碎的邏輯。

性能

BFF網(wǎng)關(guān)的耗時(shí)主要有兩部分

1. 內(nèi)部處理耗時(shí)
2. 下游RPC接口耗時(shí)

BFF作為最直接和前端交互的接口，BFF的耗時(shí)將直接影響用戶瀏覽體驗(yàn)，所以BFF性能一定要最優(yōu)，不斷壓縮耗時(shí)來提高接口響應(yīng)性能，內(nèi)部邏輯優(yōu)化時(shí)，首先觀察下游接口耗時(shí)情況，各個(gè)模塊之間難免重復(fù)調(diào)用接口，可以使用編排框架將下游接口調(diào)用進(jìn)行優(yōu)化。然后使用線程池進(jìn)行并發(fā)處理，能夠并發(fā)處理的一定要并發(fā)執(zhí)行，這樣可以極大降低下游接口耗時(shí)，提供接口處理能力。

緩存

切勿在BFF網(wǎng)關(guān)中使用緩存

此處指的緩存主要是Redis等中間件緩存，BFF網(wǎng)關(guān)主要數(shù)據(jù)來源都是通過調(diào)用下游接口獲取，這里是最耗時(shí)的，如果想要減少下游接口耗時(shí)，應(yīng)該使用并發(fā)或者編排能力，而不可以通過緩存下游接口數(shù)據(jù)來實(shí)現(xiàn)。

1. 成本問題：下游接口數(shù)據(jù)會(huì)根據(jù)傳入的定位、用戶等信息查詢，當(dāng)系統(tǒng)用戶量大、覆蓋城市多時(shí)，需要緩存的數(shù)據(jù)量將劇增，而數(shù)據(jù)緩存后再次訪問概率很低，造成嚴(yán)重的緩存空間浪費(fèi)。
2. 一致性問題：BFF網(wǎng)關(guān)的引入主要是為了統(tǒng)一后端接口，性能是網(wǎng)關(guān)的一大指標(biāo)，但不能為了性能將所有下游接口數(shù)據(jù)進(jìn)行緩存，從而犧牲數(shù)據(jù)一致性，后續(xù)展示時(shí)一旦出現(xiàn)問題，將增加排查難度。

降級

任何時(shí)候都不要將錯(cuò)誤直接返回給用戶，不論是下游的錯(cuò)誤還是系統(tǒng)內(nèi)部的錯(cuò)誤，這一點(diǎn)完全可以交給BFF網(wǎng)關(guān)來做，這里降級可以分為兩類型處理。

1. 下游接口降級：當(dāng)下游接口出現(xiàn)超時(shí)或數(shù)據(jù)異常時(shí)，一定要做好降級措施，例如增加接口超時(shí)時(shí)間判斷，及時(shí)中斷調(diào)用，不要因?yàn)槟硞€(gè)下游接口而影響整體性能，當(dāng)下游接口報(bào)錯(cuò)時(shí)，也要做好異常捕獲，整體頁面可以直接丟棄這部分?jǐn)?shù)據(jù)不做展示，而不能完全不展示。
2. 異常整體降級：在BFF網(wǎng)關(guān)內(nèi)部處理邏輯中難免會(huì)有錯(cuò)誤發(fā)生，或者下游核心的定位、商品等接口異常，這里就需要做整體降級，例如模擬一個(gè)友情提示頁面等，提示用戶稍等重新刷新，或者在未開通城市里可以引導(dǎo)用戶切換地址，整體頁面的降級盡量交給BFF網(wǎng)關(guān)來做，而不要分散到不同的前端來做。

BFF網(wǎng)關(guān)劃分

接口粒度

如上圖，BFF網(wǎng)關(guān)的下游接口較多，如何聚合下游接口進(jìn)行劃分是一個(gè)需要考慮的問題，這里提供的建議是按照頁面來劃分，例如在首頁可以提供首頁接口返回整體展示效果，購物車頁面提供購物車接口，以頁面為單位劃分可以方便前后端的統(tǒng)一處理，當(dāng)然如果頁面內(nèi)容太多時(shí)，BFF網(wǎng)關(guān)接口可能耗時(shí)較多，可以同頁面拆分開來，讓前端并行加載接口，這樣既能降低整體頁面加載時(shí)間，也能讓BFF網(wǎng)關(guān)減少下游接口調(diào)用。

數(shù)據(jù)安全

BFF網(wǎng)關(guān)雖然也叫網(wǎng)關(guān)，但數(shù)據(jù)安全方面例如安全攻防等主要還是外層去做，BFF只負(fù)責(zé)數(shù)據(jù)的調(diào)用組裝，不要再賦予其他太多功能，但BFF網(wǎng)關(guān)一定要有限流邏輯，可以采用Sentinel等框架實(shí)現(xiàn)，防止某個(gè)前端異常進(jìn)行大量請求，打垮BFF網(wǎng)關(guān)導(dǎo)致所有前端異常。

上線注意

BFF網(wǎng)關(guān)較為單薄，沒有依賴的數(shù)據(jù)庫等大型中間件，可能只是用到比較輕量的配置中心和消息隊(duì)列，所以上線時(shí)初始化參數(shù)較少，但因?yàn)锽FF網(wǎng)關(guān)需要做版本、定位、客戶端等特征的數(shù)據(jù)處理，所以一定要做好灰度上線，防止新功能影響到歷史版本、不同定位下的用戶瀏覽。

優(yōu)勢總結(jié)

BFF網(wǎng)關(guān)的引入：文章來源地址http://www.zghlxwxcb.cn/news/detail-543028.html

1. 降低后端開發(fā)聯(lián)調(diào)成本：直接提供RPC接口將基礎(chǔ)數(shù)據(jù)返回即可
2. 降低前端開發(fā)聯(lián)調(diào)成本：直接對接一兩個(gè)接口就可以拿到全部數(shù)據(jù)，并且可以將很多前端寫死的邏輯交給BFF網(wǎng)關(guān)做下發(fā)，提高前端展示的靈活性。
3. 方便需求迭代升級：當(dāng)大量前端邏輯移植到BFF網(wǎng)關(guān)，很多需求的上線不再依賴前后端發(fā)版，直接讓BFF快速上線更新即可。
4. 提高用戶體驗(yàn)：BFF網(wǎng)關(guān)可以較低成本的做異常降級處理，為前后端包裝錯(cuò)誤提示，統(tǒng)一異常捕獲類型。
5. 提高系統(tǒng)性能：雖然引入BFF網(wǎng)關(guān)相當(dāng)于多加了一層，但BFF網(wǎng)關(guān)可以通過并發(fā)調(diào)用下游接口，或者線程池的形式提高接口處理性能，而不需要像之前前端去逐個(gè)調(diào)用接口，規(guī)范了整體接口調(diào)用執(zhí)行邏輯。

到了這里，關(guān)于BFF網(wǎng)關(guān)模式開發(fā)指南的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！