微服務架構~BFF和網關是如何演化出來的

 

 

介紹

BFF(Backend for Frontend)和網關Gateway是微服務架構中的兩個重要概念，這兩個概念相對比較新，有些開發人員甚至是架構師都不甚理解。

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

服務化架構V1

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

 

服務化架構V2

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

 

 

這個架構有以下問題：

1. 無線App和內部微服務強耦合，任何一邊的變化均可能對另一邊形成影響。

2. 無線App須要知道內部服務的地址等細節。

3. 無線App端須要開發大量的聚合裁剪和適配邏輯：

• 聚合：某一個功能須要同時調用幾個後端API進行組合，好比首頁須要顯示分類和產品細節，就要同時調用分類API和產品API，不能一次調用完成。

• 裁剪：後端服務返回的Payload通常比較通用，App須要根據設備類型進行裁剪，好比手機屏幕小，須要多裁掉一些沒必要要的內容，Pad的屏幕比較大，能夠少裁掉一些內容。

• 適配：一種常見的適配場景是格式轉換，好比有些後臺服務比較老，只支持老的SOAP/XML格式，不支持新的JSON格式，則無線App須要適配處理不一樣數據格式。

4. 隨着設備類型的增多(iPhone/Android/iPad/WindowsPhone)，聚合裁剪和適配邏輯的開發會形成設備端的大量重複勞動。

服務化架構V2.1

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

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

新的V2.1架構以下圖因此：

 

 

 

這個架構的優點是：

1. 無線App和內部微服務不耦合，經過引入BFF這層間接，使得兩邊能夠獨立變化：

• 後端若是發生變化，經過BFF屏蔽，前端設備能夠作到不受影響。

• 前端若是發生變化，經過BFF屏蔽，後端微服務能夠暫不變化。

• 當無線App有新的需求時，經過BFF的屏蔽，能夠減小先後端團隊的溝通協調開銷，不少需求由前端團隊在BFF上就能夠本身搞定。

2. 無線App只須要知道Mobile BFF的地址，而且服務接口是統一的，不須要知道內部複雜微服務的地址和細節。

3. 聚合裁剪和適配邏輯在Mobile BFF上實現，無線App端能夠大大簡化瘦身。

服務化架構V3

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

1. 剛開始只有一個Mobile BFF，是個單塊，可是無線研發團隊在不斷增長，分別對應多條業務線。根據康威法則，單塊的無線BFF和多團隊之間就出現不匹配問題，團隊之間溝通協調成本高，交付效率低下。

2. Mobile BFF裏頭不只有各個業務線的聚合/裁剪/適配和業務邏輯，還引入了不少跨橫切面邏輯，好比安全認證，日誌監控，限流熔斷等。隨着時間的推移，代碼變得愈來愈複雜，技術債越堆越多，開發效率不斷降低，缺陷數量不斷增長。

3. Mobile BFF集羣是個失敗單點(Single Point of Failure)，嚴重代碼缺陷或者流量洪峯可能引起集羣宕機，全部無線應用都不可用。

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

 

 

新的架構V3有以下調整：

1. BFF按團隊或業務線進行解耦拆分，拆分紅若干個BFF微服務，每一個業務線能夠並行開發和交付各自負責的BFF微服務。

2. 網關（通常由獨立框架團隊負責運維）專一跨橫切面(Cross-Cutting Concerns)的功能，包括：

• 路由，未來自無線設備的請求路由到後端的某個微服務BFF集羣。

• 認證，對涉及敏感數據的API訪問進行集中認證鑑權。

• 監控，對API調用進行性能監控。

• 限流熔斷，當出現流量洪峯，或者後端BFF/微服務出現延遲或故障，網關可以主動進行限流熔斷，保護後端服務，並保持前端用戶體驗能夠接受。

• 安全防爬，收集訪問日誌，經過後臺分析出惡意行爲，並阻斷惡意請求。

3. 網關在無線設備和BFF之間又引入了一層間接，讓兩邊能夠獨立變化，特別是當後臺BFF在升級或遷移時，能夠作到用戶端應用不受影響。

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

服務化架構V4

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

1. 開放內部的業務能力，建設CoolShop Open API平臺。藉助第三方社區開發者的力量，在CoolShop平臺上進行創新，進一步拓寬CoolShop的應用和業務形態。

2. 廢棄傳統的服務端Web應用模式，引入先後分離架構，前端採用H5單頁等技術給用戶提供更好的體驗。

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

 

 

 

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

1. 引入面向第三方開放API的BFF層和配套的網關，支持第三方開發者在CoolShop Open API平臺上開發應用。

2. 引入面向H5應用的BFF層和配套的網關，支持先後分離和H5單頁應用模式。

V4是一個比較完整的現代微服務架構，從外到內依次分爲：端用戶體驗層->網關層->BFF層->微服務層。整個架構層次清晰，職責分明，是一種靈活的可以支持業務不斷創新的演化式架構。