本文用假想的公司案例+圖示的方式，解釋BFF和閘道器是什麼，它們是怎麼演化出來的。希望對架構師設計和落地微服務架構有所啟發。

服務化架構V1

我們先把時間推回到大致2011年左右。假設有一家有一定業務體量的電商公司CoolShop，在這個時間點它已經完成單塊應用的解構拆分，內部SOA服務化已經初步完成。這個時候它的無線應用還沒有起步，前端使用者體驗層主要是傳統的服務端Web應用，總體服務化架構V1如下圖所示。

服務化架構V2

時間轉眼來到2012年初，國內的無線應用開始起風，CoolShop公司也緊跟市場趨勢，研發自己的無線原生App。為了能儘快上線，公司的架構師提出如下V2架構，讓App直接呼叫內部的服務：

這個架構有如下問題：

無線App和內部微服務強耦合，任何一邊的變化都可能對另外一邊造成影響。無線App需要知道內部服務的地址等細節。無線App端需要開發大量的聚合裁剪和適配邏輯：聚合：某一個功能需要同時呼叫幾個後端API進行組合，比如首頁需要顯示分類和產品細節，就要同時呼叫分類API和產品API，不能一次呼叫完成。裁剪：後端服務返回的Payload一般比較通用，App需要根據裝置型別進行裁剪，比如手機螢幕小，需要多裁掉一些不必要的內容，Pad的螢幕比較大，可以少裁掉一些內容。適配：一種常見的適配場景是格式轉換，比如有些後臺服務比較老，只支援老的SOAP/XML格式，不支援新的JSON格式，則無線App需要適配處理不同資料格式。隨著裝置型別的增多(iPhone/Android/iPad/WindowsPhone)，聚合裁剪和適配邏輯的開發會造成裝置端的大量重複勞動。服務化架構V2.1

V2架構問題太多，沒有開發實施。為解決上述問題，架構師經過思考決定在外部裝置和內部微服務之間引入一個新的角色~Mobile BFF。

所謂BFF其實是Backend for Frontend的簡稱，中文翻譯是為前端而開發的後端，它主要由前端團隊開發（後端微服務一般由後端團隊開發）。BFF可以認為是一種適配服務，將後端的微服務進行適配（主要包括聚合裁剪和格式適配等邏輯），向無線端裝置暴露友好和統一的API，方便無線裝置接入訪問後端服務。

新的V2.1架構如下圖所以：

這個架構的優勢是：

無線App和內部微服務不耦合，通過引入BFF這層間接，使得兩邊可以獨立變化：後端如果發生變化，通過BFF遮蔽，前端裝置可以做到不受影響。前端如果發生變化，通過BFF遮蔽，後端微服務可以暫不變化。當無線App有新的需求時，通過BFF的遮蔽，可以減少前後端團隊的溝通協調開銷，很多需求由前端團隊在BFF上就可以自己搞定。無線App只需要知道Mobile BFF的地址，並且服務介面是統一的，不需要知道內部複雜微服務的地址和細節。聚合裁剪和適配邏輯在Mobile BFF上實現，無線App端可以大大簡化瘦身。服務化架構V3

V2.1架構比較成功，實施落地以後支援了CoolShop公司早期無線業務的成長。隨著業務量進一步增長，投入無線研發的團隊也不斷增加，V2.1架構也逐漸暴露出如下問題：

剛開始只有一個Mobile BFF，是個單塊，但是無線研發團隊在不斷增加，分別對應多條業務線。根據康威法則，單塊的無線BFF和多團隊之間就出現不匹配問題，團隊之間溝通協調成本高，交付效率低下。Mobile BFF裡頭不僅有各個業務線的聚合/裁剪/適配和業務邏輯，還引入了很多跨橫切面邏輯，比如安全認證，日誌監控，限流熔斷等。隨著時間的推移，程式碼變得越來越複雜，技術債越堆越多，開發效率不斷下降，缺陷數量不斷增加。Mobile BFF叢集是個失敗單點(Single Point of Failure)，嚴重程式碼缺陷或者流量洪峰可能引發叢集宕機，所有無線應用都不可用。

為了解決上述問題，架構師經過思考決定在外部裝置和內部BFF之間再引入一個新的角色~API Gateway，新的架構V3如下圖所示：

新的架構V3有如下調整：

BFF按團隊或業務線進行解耦拆分，拆分成若干個BFF微服務，每個業務線可以並行開發和交付各自負責的BFF微服務。閘道器（一般由獨立框架團隊負責運維）專注跨橫切面(Cross-Cutting Concerns)的功能，包括：路由，將來自無線裝置的請求路由到後端的某個微服務BFF叢集。認證，對涉及敏感資料的API訪問進行集中認證鑑權。監控，對API呼叫進行效能監控。限流熔斷，當出現流量洪峰，或者後端BFF/微服務出現延遲或故障，閘道器能夠主動進行限流熔斷，保護後端服務，並保持前端使用者體驗可以接受。安全防爬，收集訪問日誌，通過後臺分析出惡意行為，並阻斷惡意請求。閘道器在無線裝置和BFF之間又引入了一層間接，讓兩邊可以獨立變化，特別是當後臺BFF在升級或遷移時，可以做到使用者端應用不受影響。

在新的V3架構中，閘道器承擔了重要的角色，它是解耦拆分和後續升級遷移的利器。在閘道器的配合下，單塊BFF實現了解耦拆分，各業務線團隊可以獨立開發和交付各自的微服務，研發效率大大提升。另外，把跨橫切面邏輯從BFF剝離到閘道器上去以後，BFF的開發人員可以更加專注業務邏輯交付，實現了架構上的關注分離(Separation of Concerns)。

服務化架構V4

業務在不斷髮展，技術架構也需要不斷的調整來應對需求的變化。近年，CoolShop公司技術團隊又迎來了新的業務和技術需求，主要是：

開放內部的業務能力，建設CoolShop Open API平臺。藉助第三方社群開發者的力量，在CoolShop平臺上進行創新，進一步拓寬CoolShop的應用和業務形態。廢棄傳統的服務端Web應用模式，引入前後分離架構，前端採用H5單頁等技術給使用者提供更好的體驗。

為滿足業務需求，架構師對服務化架構又進行了拓展升級，新的V4新架構如下圖所示：

V4整體思路和V3類似，只是拓展了新的接入渠道:

引入面向第三方開放API的BFF層和配套的閘道器，支援第三方開發者在CoolShop Open API平臺上開發應用。引入面向H5應用的BFF層和配套的閘道器，支援前後分離和H5單頁應用模式。

V4是一個比較完整的現代微服務架構，從外到內依次分為：端使用者體驗層->閘道器層->BFF層->微服務層。整個架構層次清晰，職責分明，是一種靈活的能夠支援業務不斷創新的演化式架構。

結論在微服務架構中，BFF(Backend for Frontend)也稱聚合層或者適配層，它主要承接一個適配角色：將內部複雜的微服務，適配成對各種不同使用者體驗（無線/Web/H5/第三方等）友好和統一的API。聚合裁剪適配是BFF的主要職責。在微服務架構中，閘道器專注解決跨橫切面邏輯，包括路由、安全、監控和限流熔斷等。閘道器一方面是拆分解耦的利器，同時讓開發人員可以專注業務邏輯的實現，達成架構上的關注分離。端使用者體驗層->閘道器層->BFF層->微服務層，是現代微服務架構的典型分層方式，這個架構能夠靈活應對業務需求的變化，是一種支援創新的演化式架構。技術和業務都在不斷變化，架構師要不斷調整架構應對這些的變化，BFF和閘道器都是架構演化的產物。

原文：《微服務架構~BFF和閘道器是如何演化出來的》