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