【答疑解惑】|?作者?/ Edison Zhou

這是恰童鞋騷年的第263篇原創(chuàng)內(nèi)容

---

昨天的騷年快答《技術(shù)中臺與業(yè)務(wù)中臺都是啥玩意》一文中留下一個問題：BFF是啥？為啥在API網(wǎng)關(guān)和業(yè)務(wù)中臺之間加入了一層BFF？考慮到在實際工作中，我的大部分同事都問過這個問題，這里我也總結(jié)一下進行答復(fù)。

1從一個MyShop開始說起

為了講清BFF是個啥，這里引用我在波波老師的課程《Spring Boot與K8s云原生應(yīng)用開發(fā)》中學(xué)到的一個案例，來跟大家分享一下，并盡力說清楚BFF是啥，又是如何演化出來的。

假設(shè)我們在一個開發(fā)團隊中，開發(fā)了一個叫做MyShop的電商項目，它采用的是微服務(wù)的架構(gòu)風(fēng)格。它經(jīng)歷過幾次架構(gòu)調(diào)整，我們就跟著它的調(diào)整來看看BFF是怎么演化出來的。

假設(shè)v1版本在七八年之前，MyShop已經(jīng)采用了服務(wù)化的架構(gòu)，它的客戶端也主要還是以傳統(tǒng)的Web應(yīng)用為主。在當時，它的SOA架構(gòu)已經(jīng)算是跟上了潮流。

轉(zhuǎn)眼之間，來到了四五年前，MyShop升級為了v2版本，它的架構(gòu)如下圖所示：

可以看到，這個時候已經(jīng)進入了移動互聯(lián)網(wǎng)時代，MyShop為了緊跟時代，也推出了自己的無線應(yīng)用App。為了能夠盡快上線，MyShop團隊的架構(gòu)師設(shè)計了v2架構(gòu)，它為App端新增了一個Nginx反向代理，可以使App入口直接訪問API微服務(wù)。

但是，這個急于求成的v2架構(gòu)存在以下問題：

（1）App端和內(nèi)部的API微服務(wù)存在一個強耦合的關(guān)系（包括接口耦合和域名耦合），任何一邊的變化都會對另外一邊造成一定影響。

（2）每個對外暴露的服務(wù)，都需要新的域名，而域名是需要買的，是需要承擔(dān)成本的。

（3）內(nèi)部的API微服務(wù)一股腦地暴露在了公網(wǎng)上面，存在很大的安全風(fēng)險。

（4）App客戶端需要開發(fā)大量的聚合裁剪的邏輯，客戶端很重且重復(fù)勞動。（所謂聚合裁剪，解釋一下，聚合就是一次需要從多個微服務(wù)獲取數(shù)據(jù)進行整合使用，而裁剪就是需要對微服務(wù)返回的數(shù)據(jù)進行過濾，可能只會用到其中一部分的字段數(shù)據(jù)）

2引入BFF的MyShop?v2.5

由于v2版本存在的問題太多，于是架構(gòu)團隊決定在Nginx和內(nèi)部API微服務(wù)之間引入一層無線BFF（英文全稱：Backend For Frontend，指為前端應(yīng)用開發(fā)的后端服務(wù)）來解決這個問題，也就有了下面的v2.5版本的架構(gòu)。

我們可以將BFF看做是一個后端微服務(wù)的代理服務(wù)，它主要做聚合和裁剪的邏輯，方便客戶端接入和訪問。可以看到，引入了BFF之后，降低了App端與后端微服務(wù)之間的耦合，從而避免了v2版本提到的強耦合問題。此外，App端只需要知道BFF的域名即可，內(nèi)部微服務(wù)也躲在BFF之后不需要暴露在公網(wǎng)之上。

由于v2.5版本解決了很多問題，因此成功上線，也為MyShop無線業(yè)務(wù)的發(fā)展做了很大的支持。

但是，隨著業(yè)務(wù)的不斷快速發(fā)展，單塊的無線BFF堆積了大量的不同業(yè)務(wù)線的邏輯變得越來越臃腫，升級維護也變得越來越困難。此外，根據(jù)康威法則，單塊的無線BFF和多團隊也出現(xiàn)了不匹配的問題，即團隊之間溝通成本變低，交付成本也就會變高。最后，無線BFF里面除了多業(yè)務(wù)線的聚合裁剪邏輯，還引入了Cross-Cutting（跨橫切面）的邏輯，比如安全認證、日志監(jiān)控、限流熔斷等等。隨著時間的推移，代碼變得越來越復(fù)雜，技術(shù)棧越堆越多，開發(fā)效率也不斷下降。（當然，還有單點問題等等，這里就不多贅述了）

3網(wǎng)關(guān)+BFF模式的MyShop v3

為了解決v2.5版本存在的問題，架構(gòu)團隊經(jīng)過進一步思考，一方面決定將單塊的無線BFF進行解耦拆分，針對不同的業(yè)務(wù)線引入獨立的微服務(wù)集群。另一方面，決定在無線BFF和Nginx之間再引入一個新的角色：API網(wǎng)關(guān)，并將Cross-Cutting的職責(zé)轉(zhuǎn)移到API網(wǎng)關(guān)上。自此，v3架構(gòu)出爐，如下圖所示：

v3架構(gòu)下，BFF按照團隊或業(yè)務(wù)線的邊界進行劃分，每個業(yè)務(wù)線團隊可以并行各自開發(fā)和交付BFF。而網(wǎng)關(guān)則由單獨的中間件或框架團隊進行開發(fā)和維護，它專注于路由轉(zhuǎn)發(fā)和Cross-Cutting層面的功能建設(shè)，讓業(yè)務(wù)線團隊專注于業(yè)務(wù)邏輯的開發(fā)。

我們.NET程序員所熟知的Ocelot網(wǎng)關(guān)項目（對，就是張隊參與貢獻的那個網(wǎng)關(guān)項目），就幫助我們實現(xiàn)了路由轉(zhuǎn)發(fā)和Cross-Cutting的功能，例如限流熔斷、集中鑒權(quán)（例如集成IdentityServer）、負載均衡、調(diào)用追蹤等。

4乘風(fēng)破浪的MyShop v4

最近一兩年呢，MyShop團隊迎來了新的業(yè)務(wù)和技術(shù)的發(fā)展需求，要開放內(nèi)部的企業(yè)級能力建設(shè)OpenAPI開放平臺，還想要借助第三方的力量在MyShop平臺上進行創(chuàng)新打造生態(tài)從而豐富MyShop的應(yīng)用形態(tài)。此外，SPA單頁應(yīng)用、H5前后端分離應(yīng)用等多類型的應(yīng)用客戶端也需要接入。架構(gòu)團隊設(shè)計了一個如下圖所示的v4架構(gòu)，從而滿足快速發(fā)展的已有和未來可能的需求：

在v4架構(gòu)下，移除了原來偏運維層面的Nginx反向代理，轉(zhuǎn)而統(tǒng)一使用可編程性較強的API網(wǎng)關(guān)作為客戶端應(yīng)用入口。這里的網(wǎng)關(guān)也進行解耦拆分，針對不同的客戶端應(yīng)用場景，分為了四個類型，如開放平臺網(wǎng)關(guān)、H5網(wǎng)關(guān)、無線網(wǎng)關(guān)和Web應(yīng)用網(wǎng)關(guān)。而BFF層面，也根據(jù)業(yè)務(wù)線拆分為了無線BFF、H5 BFF及開放平臺BFF。整個架構(gòu)層次清晰，職責(zé)分明，是一種靈活的、方便支持MyShop業(yè)務(wù)快速發(fā)展的架構(gòu)。

相信看到這里，你大概應(yīng)該明白了BFF是個啥，它在微服務(wù)架構(gòu)中的位置和作用，以及它是如何演化出來的。

畫外音：如果還沒明白，那就再看一遍！

5我司還處于v3架構(gòu)階段

剛剛通過MyShop的案例架構(gòu)演化，講解了BFF和網(wǎng)關(guān)是如何演化出來的。那么，你可能會問，我司的架構(gòu)處在哪個階段。這里，回答一下，還在v3階段。

可以從這個技術(shù)體系圖中看到，作為應(yīng)用服務(wù)層的API服務(wù)就是BFF，他們會從基礎(chǔ)業(yè)務(wù)服務(wù)如客戶服務(wù)、訂單服務(wù)、產(chǎn)品服務(wù)等微服務(wù)中獲取數(shù)據(jù)，進行一定的聚合和裁剪返回個某個具體業(yè)務(wù)線的前端應(yīng)用，前端應(yīng)用可能是SPA也可能是H5應(yīng)用。BFF層的API服務(wù)，我們在實踐中大部分都使用了ASP.NET Core進行開發(fā)，同時也在嘗試使用Go進行開發(fā)，也讓前端有興趣的同事引入進來用Go進行BFF的開發(fā)。但是，在基礎(chǔ)服務(wù)層面即前面所說的業(yè)務(wù)中臺層，還是由后端同事使用ASP.NET Core開發(fā)，確保質(zhì)量。

API網(wǎng)關(guān)層面，我們使用的是Ocelot，集成了鑒權(quán)認證等工作，前端統(tǒng)一只需要記住網(wǎng)關(guān)的域名即可，帶上合法的token訪問即可獲取數(shù)據(jù)返回。很多人說Ocelot性能低建議使用Kong，但是我司業(yè)務(wù)量小啊，所以目前沒啥問題，用得好好的。內(nèi)部微服務(wù)之間的相互調(diào)用，我們目前也是走了API網(wǎng)關(guān)（區(qū)別于外部應(yīng)用訪問的網(wǎng)關(guān)，這里我稱之為內(nèi)部網(wǎng)關(guān)），不過為了方便（其實是懶），我們對于內(nèi)部信任的服務(wù)間調(diào)用，沒有走JWT認證，當然也可以選擇Client Credentials（客戶端憑證）模式。

對于現(xiàn)階段的我們的架構(gòu)來說，只能說是夠用，因為業(yè)務(wù)量真的不大，也沒必要為了上所謂的高性能高可用架構(gòu)做過多的設(shè)計，對傳統(tǒng)家居裝飾行業(yè)的企業(yè)來說，IT先滿足業(yè)務(wù)支持業(yè)務(wù)快速發(fā)展吧。傳統(tǒng)行業(yè)的企業(yè)數(shù)字化轉(zhuǎn)型，也并不是一次就吃個胖子，慢慢演進吧。

最后，想著是快答，居然也洋洋灑灑寫了這么多，希望對你有所幫助吧！

畫外音：如果看到這里，你都不點個贊/在看，有點那啥了...

往期精彩快答

技術(shù)中臺與業(yè)務(wù)中臺到底是啥？

點個“在看” 就是對我最大的支持

總結(jié)

以上是生活随笔為你收集整理的骚年快答 | 微服务架构中的BFF到底是啥？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。