在《技術中台與業務中台都是啥玩意》一文中留下一個問題：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先滿足業務支持業務快速發展吧。數字化轉型，也並不是一次就吃個胖子，慢慢演進吧。最后，想着是快答，居然也洋洋灑灑寫了這么多，希望對你有所幫助吧！
畫外音：如果看到這里，你都不點個贊/在看，有點那啥了...
