bff(backend for frontend)和閘道器gateway是微服務架構中的兩個重要概念，這兩個概念相對比較新，有些開發人員甚至是架構師都不甚理解。
本文用假想的公司案例+圖示的方式，解釋bff和閘道器是什麼，它們是怎麼演化出來的。希望對架構師設計和落地微服務架構有所啟發。
我們先把時間推回到大致2023年左右。假設有一家有一定業務體量的電商公司a，在這個時間點它已經完成單塊應用的解構拆分，內部soa服務化已經初步完成。這個時候它的無線應用還沒有起步，前端使用者體驗層主要是傳統的服務端web應用，總體服務化架構v1如下圖所示。
這個架構有如下問題：
隨著裝置型別的增多(iphone/android/ipad/windowsphone)，聚合裁剪和適配邏輯的開發會造成裝置端的大量重複勞動。
v2架構問題太多，沒有開發實施。為解決上述問題，架構師經過思考決定在外部裝置和內部微服務之間引入乙個新的角色~mobile bff。
所謂bff其實是backend for frontend的簡稱，中文翻譯是為前端而開發的後端，它主要由前端團隊開發（後端微服務一般由後端團隊開發）。bff可以認為是一種適配服務，將後端的微服務進行適配（主要包括聚合裁剪和格式適配等邏輯），向無線端裝置暴露友好和統一的api，方便無線裝置接入訪問後端服務。
新的v2.1架構如下圖所以：
這個架構的優勢是：
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之間又引入了一層間接，讓兩邊可以獨立變化，特別是當後台bff在公升級或遷移時，可以做到使用者端應用不受影響。
在新的v3架構中，閘道器承擔了重要的角色，它是解耦拆分和後續公升級遷移的利器。在閘道器的配合下，單塊bff實現了解耦拆分，各業務線團隊可以獨立開發和交付各自的微服務，研發效率大大提公升。另外，把跨橫切面邏輯從bff剝離到閘道器上去以後，bff的開發人員可以更加專注業務邏輯交付，實現了架構上的關注分離(separation of concerns)。
業務在不斷發展，技術架構也需要不斷的調整來應對需求的變化。近年，a公司技術團隊又迎來了新的業務和技術需求，主要是：
開放內部的業務能力，建設a open api平台。借助第 三方社群開發者的力量，在a平台上進行創新，進一步拓寬a的應用和業務形態。
廢棄傳統的服務端web應用模式，引入前後分離架構，前端採用h5單頁等技術給使用者提供更好的體驗。
為滿足業務需求，架構師對服務化架構又進行了拓展公升級，新的v4新架構如下圖所示：
v4整體思路和v3類似，只是拓展了新的接入渠道:
引入面向第三方開放api的bff層和配套的閘道器，支援第三方開發者在coolshop open api平台上開發應用。
引入面向h5應用的bff層和配套的閘道器，支援前後分離和h5單頁應用模式。
v4是乙個比較完整的現代微服務架構，從外到內依次分為：端使用者體驗層->閘道器層->bff層->微服務層。整個架構層次清晰，職責分明，是一種靈活的能夠支援業務不斷創新的演化式架構。
微服務架構之 API閘道器
在微服務架構的系列文章中，前面已經通過文章 架構設計之 服務註冊 介紹過了服務註冊的原理和應用，今天這篇文章我們來聊一聊 api閘道器 api閘道器 是任何微服務架構的重要組成部分。有了它我們可以在乙個獨立的模組上方便的處理一些非業務邏輯，可以讓微服務本身專注在自身特定的功能上，使得每個微服務的開發...
微服務架構中整合閘道器 許可權服務
前言 之前的文章有講過微服務的許可權系列和閘道器實現，都是孤立存在，本文將整合後端服務與閘道器 許可權系統。安全許可權部分的實現還講解了基於前置驗證的方式實現，但是由於與業務聯絡比較緊密，沒有具體的示例。業務許可權與業務聯絡非常密切，本次的整合專案將會把這部分的操作許可權校驗實現基於具體的業務服務。...
微服務架構 去中心化的微服務閘道器
這篇文章主要還是想談如果僅僅是內部多個微服務模組間的介面服務整合，是否能夠實現一種去中心化的微服務閘道器，或者也可以理解為實現一種去中心化的輕量服務匯流排能力。要知道，在微服務模組間的介面服務呼叫中，涉及到安全，日誌，路由，監控，限流等能力，我們還是希望有乙個統一的微服務閘道器來處理。在前面的文章裡...