在《技術中臺與業務中臺都是啥玩意》一文中留下一個問題：BFF是啥？為啥在API閘道器和業務中臺之間加入了一層BFF？考慮到在實際工作中，我的大部分同事都問過這個問題，這裡我也總結一下進行答覆。

一、從一個MyShop開始說起

為了講清BFF是個啥，這裡引用我在波波老師的課程《Spring Boot與K8s雲原生應用開發》中學到的一個案例，來跟大家分享一下，並盡力說清楚BFF是啥，又是如何演化出來的。

假設我們在一個開發團隊中，開發了一個叫做MyShop的電商專案，它採用的是微服務的架構風格。它經歷過幾次架構調整，我們就跟著它的調整來看看BFF是怎麼演化出來的。

假設v1版本在七八年之前，MyShop已經採用了服務化的架構，它的客戶端也主要還是以傳統的Web應用為主。在當時，它的SOA架構已經算是跟上了潮流。

轉眼之間，來到了四五年前，MyShop升級為了v2版本，它的架構如下圖所示：

可以看到，這個時候已經進入了移動網際網路時代，MyShop為了緊跟時代，也推出了自己的無線應用App。為了能夠儘快上線，MyShop團隊的架構師設計了v2架構，它為App端新增了一個Nginx反向代理，可以使App入口直接訪問API微服務。

但是，這個急於求成的v2架構存在以下問題：

（1）App端和內部的API微服務存在一個強耦合的關係（包括介面耦合和域名耦合），任何一邊的變化都會對另外一邊造成一定影響。

（2）每個對外暴露的服務，都需要新的域名，而域名是需要買的，是需要承擔成本的。

（3）內部的API微服務一股腦地暴露在了公網上面，存在很大的安全風險。

（4）App客戶端需要開發大量的聚合裁剪的邏輯，客戶端很重且重複勞動。（所謂聚合裁剪，解釋一下，聚合就是一次需要從多個微服務獲取資料進行整合使用，而裁剪就是需要對微服務返回的資料進行過濾，可能只會用到其中一部分的欄位資料）

二、引入BFF的MyShop v2.5

由於v2版本存在的問題太多，於是架構團隊決定在Nginx和內部API微服務之間引入一層無線BFF（英文全稱：Backend For Frontend，指為前端應用開發的後端服務）來解決這個問題，也就有了下面的v2.5版本的架構。

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

由於v2.5版本解決了很多問題，因此成功上線，也為MyShop無線業務的發展做了很大的支援。

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

三、閘道器+BFF模式的MyShop v3

為了解決v2.5版本存在的問題，架構團隊經過進一步思考，一方面決定將單塊的無線BFF進行解耦拆分，針對不同的業務線引入獨立的微服務叢集。另一方面，決定在無線BFF和Nginx之間再引入一個新的角色：API閘道器，並將Cross-Cutting的職責轉移到API閘道器上。自此，v3架構出爐，如下圖所示：

v3架構下，BFF按照團隊或業務線的邊界進行劃分，每個業務線團隊可以並行各自開發和交付BFF。而閘道器則由單獨的中介軟體或框架團隊進行開發和維護，它專注於路由轉發和Cross-Cutting層面的功能建設，讓業務線團隊專注於業務邏輯的開發。我們.NET程式設計師所熟知的Ocelot閘道器專案（對，就是張隊參與貢獻的那個閘道器專案），就幫助我們實現了路由轉發和Cross-Cutting的功能，例如限流熔斷、集中鑑權（例如整合IdentityServer）、負載均衡、呼叫追蹤等。

四、乘風破浪的MyShop v4

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

在v4架構下，移除了原來偏運維層面的Nginx反向代理，轉而統一使用可變成型較強的閘道器作為客戶端應用入口，當然這裡引入了一些其他的LB服務做了閘道器層的負載均衡。這裡的閘道器也進行解耦拆分，針對不同的客戶端應用場景，分為了四個型別，如開放平臺閘道器、H5閘道器、無線閘道器和Web應用閘道器。而BFF層面，也根據業務線拆分為了無線BFF、H5 BFF及開放平臺BFF。整個架構層次清晰，職責分明，是一種靈活的、方便支援MyShop業務快速發展的架構。相信看到這裡，你大概應該明白了BFF是個啥，它在微服務架構中的位置和作用，以及它是如何演化出來的。

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

五、我司還處於v3階段

剛剛通過MyShop的案例架構演化，講解了BFF和閘道器是如何演化出來的。那麼，你可能會問，我司的架構處在哪個階段。這裡，回答一下，還在v3階段。

可以從這個技術體系圖中看到，作為應用服務層的API服務就是BFF，他們會從基礎業務服務如客戶服務、訂單服務、產品服務等微服務中獲取資料，進行一定的聚合和裁剪返回個某個具體業務線的前端應用，前端應用可能是SPA也可能是H5應用。BFF層的API服務，我們在實踐中大部分都使用了ASP.NET Core進行開發，同時也在嘗試使用Go進行開發，也讓前端有興趣的同事引入進來用Go進行BFF的開發。但是，在基礎服務層面即前面所說的業務中臺層，還是由後端同事使用ASP.NET Core開發，確保質量。API閘道器層面，我們使用的是Ocelot，集成了鑑權認證等工作，前端統一隻需要記住閘道器的域名即可，帶上合法的token訪問即可獲取資料返回。很多人說Ocelot效能低建議使用Kong，但是我司業務量小啊，所以目前沒啥問題，用得好好的。內部微服務之間的相互呼叫，我們目前也是走了API閘道器（區別於外部應用訪問的閘道器，這裡我稱之為內部閘道器），不過為了方便（其實是懶），我們對於內部信任的服務間呼叫，沒有走JWT認證，當然也可以選擇Client Credentials（客戶端憑證）模式。對於現階段的我們的架構來說，只能說是夠用，因為業務量真的不大，也沒必要為了上所謂的高效能高可用架構做過多的設計，對傳統家居裝飾行業的企業來說，IT先滿足業務支援業務快速發展吧。數字化轉型，也並不是一次就吃個胖子，慢慢演進吧。最後，想著是快答，居然也洋洋灑灑寫了這麼多，希望對你有所幫助吧！

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

作者：周旭龍

出處：https://edisonchou.cnblogs.com

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。