前世今生
在開始介紹網關之前，首先介紹兩個概念BFF（Backend For Frontend）和網關，這兩個概念及其容易混淆，所以首先借用Netflix和SoundCloud兩個公司的系統架構層次演化來說明一下。
Netflix微服務分層架構(2017以及以前)
Netflix 2017年
這個分層架構共分四個層次
- 用戶體驗層，據說Netflix要支持超過一千種的不同設備體驗，這個對Netflix技術團隊特別是前端團隊是一個巨大的挑戰。
- 網關路由層，Netflix使用Zuul網關作為服務路由層，同時兼具安全認證，監控，限流熔斷等跨橫切面功能。Zuul網關無狀態以集群方式部署，前面依賴AWS ELB做負載均衡。
- 邊界API層，Netflix的裁剪聚合和適配層，也就是BFF層，將後端微服務，適配到不同的前端體驗。在Netflix體系中，該層也稱Edge Service Layer。
- 微服務層，Netflix的核心領域服務，也稱中間層(Middle Tier)服務。
網關+邊界API層(BFF)+一些前端服務(如安全認證，Playback相關服務，DRM等)，統一由一個Netflix的前端團隊負責，該團隊也稱邊界工程(Edge Engineering)團隊。
- 因為Netflix要應對處理的設備類型巨多，所以它們在邊界層投入了大量工程技術資源，2017年前Netflix的邊界API層(BFF)具有下面架構特點：
- 整個邊界API層(BFF)住在一個PaaS平臺裡頭，稱為Edge PaaS。
- Edge PaaS本質上是一個動態腳本平臺(Dyanmic Scripting Platform)，支持使用Groovy等JVM腳本語言，方便前端團隊快速聚合裁剪後端微服務，並向前端設備暴露友好的API。之所以使用動態腳本語言Groovy，主要是考慮腳本語言對前端開發的友好性和生產率。
- Edge PaaS裡頭同時預置後端微服務的Java客戶端SDK，方便Groovy腳本調用後端服務，同時對客戶端進行Hystrix埋點，保障對後臺微服務調用的穩定性。
- 由於前端需求變更比較頻繁，所以Edge PaaS裡頭的腳本一般更新也比較頻繁，前端團隊可以按需每日更新，上傳動態腳本即可。
- 如果後端微服務有升級更新，一般需要升級Edge PaaS裡頭的客戶端SDK，但是這個不是頻繁操作，一般以固定週期（比如兩週一個full release）發生，但是集成迴歸測試成本還是比較高的。
Netflix微服務分層架構(2018)
上述的Edge PaaS其實是一個單塊架構，隨著Netflix的前端業務變得更加複雜，Edge PaaS也逐漸遭遇康威法則的約束，暴露出如下問題：
- Edge PaaS裡頭同時耦合了前端聚合裁剪適配和後端API/SDK邏輯，當後端API有升級，一般需要升級Edge PaaS裡頭的客戶端SDK，這種升級可能因不兼容和測試不充分，造成前端業務代碼出問題。總體上前後端團隊因升級、集成測試而造成的溝通協調成本非常大。
- 所有面向用戶體驗的腳本邏輯都住在一套Edge PaaS裡頭，缺乏隔離性，當某個團隊的腳本有bug，很容易負面影響到其它腳本。整個Edge PaaS也是一個大單點(Single Point of Failure)，嚴重腳本缺陷或者流量洪峰可致集群宕機。
- 前端腳本有上傳快和動態加載等優勢，但是本地調試不方便，很多依賴的環境(Edge PaaS + API/SDK)難以在本地開發環境複製，造成開發反饋效率低下，出現問題排障困難。
- 為解決上述問題，Netflix邊界工程團隊對Edge PaaS的架構進行了調整，從單塊一分為二，新的架構如下圖所示：
- image.png
主要變化是將邊界API層分成兩個子層次：
API聚合層，專注對後端微服務進行聚合，提供前端友好、抽象統一的API。API聚合層主要基於Java+後臺服務的客戶端SDK實現。API聚合層還按業務功能進行分集群部署(API Sharding)。
設備適配層BFF，專注對API聚合層的服務進行裁剪和適配，提供給不同的用戶體驗展示。
- 設備聚合層採用對前端開發友好的Node.js框架，各個團隊的服務可以獨立部署在容器環境(Netflix的容器雲Titus)中，使用容器機制進行隔離，避免相互干擾。Node.js+容器在Netflix稱為NodeQuark平臺。NodeQuark環境在開發人員本地可以搭建，方便開發本地調試。
- 經過拆分，當前Netflix演化出一個五層的微服務分層架構，前面三層(用戶體驗、網關路由和設備適配層)專注解決前端開發人員生產率的問題；後端兩層(API聚合層和微服務層)專注解決領域抽象和運維監控穩定性問題。整個體系架構層次職責分明，初步解決了之前單塊Edge PaaS的諸多問題，解放了生產率。
結論
- Netflix採用經典的微服務分層架構，前端體驗->網關路由->邊界API層(BFF)->後端微服務。這個分層架構可供一線企業實踐微服務參考。
- 近年，為了進一步提升前端研發效率，Netflix又將邊界API層(BFF)拆分成兩個子層次，設備適配層BFF和API聚合層。總體演化出一個五層的微服務分層架構。增加新的層次對於Netflix這種體量的公司來說，有其架構合理性，但一般企業沒必要細分5層，採用上述經典4層架構就OK了。BFF層也未必要採用腳本nodejs之類，java/.net等強類型語言開發也OK，畢竟一般企業沒有Netflix那麼多的用戶設備要處理。
- 從Netflix架構體系演變我們可以看出，為了提升研發效率，它的架構經過很多層細分，額外分層會帶來一定的性能損失。但是對於前沿大體量的互聯網公司，性能一般並不是其架構的首要考量，靈活性、可治理性和研發效率才是它們的首要考量。性能的損失一般可以通過雲計算+水平擴展+緩存等手段來彌補。
SoundCloud
下面繼續以SoundCloud公司為案例，通過一系列架構視圖，展示SoundCloud微服務架構的分層組織方式。如果你閱讀並理解了前面兩篇文章的內容，那麼就比較容易理解本文的內容，所有本文的分析會相對簡單一點。
注，SoundCloud是一家德國網站，提供音樂分享社區服務，成長很快，Alexa世界排名已進入200位以內。
- SouldCloud採用經典的三層微服務架構，用戶體驗層->邊界BFF層->後端微服務層
- SoundCloud的BFF主要分為四類：
- 面向主站的Api-V2 BFF
- 面向移動端的Api-mobile BFF
- 面向嵌入頁面場景的Api-embeded BFF
- 面向開放平臺場景的Public API BFF
- SoundCloud沒有像Netflix那樣的獨立的網關Gateway層，它的BFF層融合了網關功能+服務聚合裁剪和適配功能
- SoundCloud的微服務分層架構也是為了應對業務和技術挑戰，不斷演化出來的。關於其內部微服務的演進歷程，以及BFF在演進中扮演的角色。
image.png
總結
- Netflix的微服務架構有獨立的網關層，SoundCloud則沒有獨立網關層，它的網關和BFF層是融合在一起的。我認為這個和兩家公司的業務體量和團隊規模不同有關，Netflix業務體量更大也更復雜，需要獨立的網關層實現架構上的關注分離，保障研發交付效率。SoundCloud則業務體量和團隊規模相對小，暫時還沒有分解那麼細。將網關和BFF融合的做法，在國內很多公司也是這麼實踐的。
- SoundCloud對其微服務還進行了一層細分，包括基礎服務+增值服務，這個應該是架構師根據需要，額外定義的一種架構分層規範，有助於研發人員更清晰理解架構，並遵循架構規範開展研發。
- Netflix/SoundCloud等大公司的微服務分層架構僅供參考，各家做法有差異，但是背後原理相同。架構師要理解其背後的分佈式原理，然後靈活應用，不可拘泥照搬。
- SoundCloud還給出微服務架構的一種更抽象的描述，如下圖所示，微服務架構本質上可以理解成是一種分佈式的企業操作系統
- 內核是一個企業的業務領域基礎服務
- 第二層是BFF，將基礎服務聚合裁剪適配，暴露面向不同用戶體驗的API
- 第三層是面向不同用戶體驗(無線PC\開放平臺等)的客戶應用
- 最外層是使用這個企業操作系統的用戶
API網關概念介紹
API網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。
API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。
通常情況下， API 網關要做很多工作，它作為一個系統的後端總入口，承載著所有服務的組合路由轉換等工作，除此之外，我們一般也會把安全，限流，緩存，日誌，監控，重試，熔斷等放到 API 網關來做，那麼可以試想在高併發的情況下，這裡可能會出現一個性能瓶頸。
另外，如果沒有開源項目的支撐前提下，自己來做這樣一套東西，是非常大的一個工作量，而且還要做 API 網關本身的高可用等，如果一旦做不好，有可能最先掛掉的不是你的其他服務，而就是這個API網關。
鏈接：https://www.jianshu.com/p/a8b0ca4932e1
閱讀更多 思夢PHP 的文章
