API網(wǎng)關(guān)你不知道的那些事情
gzh：堆棧future
干貨：
網(wǎng)關(guān)模式是BFF模式嗎
Facade模式與網(wǎng)關(guān)模式又有什么區(qū)別
API網(wǎng)關(guān)不只是代理或者路由
1. 客戶端到微服務(wù)通信架構(gòu)
在這種模式中分尸，客戶端應(yīng)用程序可以直接向某些微服務(wù)發(fā)出請(qǐng)求⊥帕蓿客戶端通過微服務(wù)提供的一個(gè)公開的endpoint來訪問，可以是域名也可以是IP+Port囊嘉。這種方式比較簡(jiǎn)單粗暴，前期產(chǎn)品的迭代和開發(fā)效率高革为，也不用維護(hù)其他中間件組件(gateway,nacos等)扭粱；但是缺點(diǎn)也很明顯，比如我們看以下問題：
-
客戶端應(yīng)用程序如何最大限度地減少對(duì)后端的請(qǐng)求數(shù)量并減少與多個(gè)微服務(wù)的繁瑣通信震檩？
與多個(gè)微服務(wù)交互以構(gòu)建單個(gè)UI頁面會(huì)增加網(wǎng)絡(luò)上的往返次數(shù)琢蛤，也就是說這種模式會(huì)增加UI端的延遲和復(fù)雜性。理想情況下抛虏，聚合數(shù)據(jù)的響應(yīng)應(yīng)該在服務(wù)器端有效地聚合然后提供一個(gè)接口統(tǒng)一返回就行了虐块，這樣的方式就會(huì)減少響應(yīng)延遲，UI在獲取到數(shù)據(jù)之后會(huì)立刻渲染展示嘉蕾。
-
如何處理橫切關(guān)注點(diǎn)贺奠，如授權(quán)、數(shù)據(jù)轉(zhuǎn)換和動(dòng)態(tài)請(qǐng)求分派?
我們從上圖可以看出错忱，我們每個(gè)微服務(wù)其實(shí)都對(duì)各個(gè)端提供了例如認(rèn)證儡率，授權(quán)，限流等之類的操作以清，對(duì)于服務(wù)端來說就是復(fù)制黏貼儿普，但是對(duì)于客戶端來說簡(jiǎn)直就是災(zāi)難，他們每對(duì)接一個(gè)微服務(wù)就得寫一套處理服務(wù)端的認(rèn)證鑒權(quán)邏輯掷倔，還得維護(hù)很多secret key眉孩。其實(shí)后端也挺痛苦的，他也得拷貝之前項(xiàng)目的認(rèn)證授權(quán)模式在新項(xiàng)目中使用勒葱，完完全全在做無用功浪汪。再比如分布式鏈路追蹤，trace_id的生成凛虽，每個(gè)后端服務(wù)都得搞一套死遭，這不是XG嗎，我們是人不是機(jī)器凯旋。還有就是我們?cè)谧龌叶劝l(fā)布的時(shí)候呀潭，你總不能在端上搞吧，你總共有1000w用戶至非，你想用100w人做灰度驗(yàn)證钠署，你讓客戶端去做，那客戶端同學(xué)絕筆回敬你一個(gè)白眼荒椭。既然你不想得罪他們你就在服務(wù)端去做谐鼎，可是服務(wù)端有好幾個(gè)微服務(wù)，你該如何去做灰度呢戳杀？
-
如果服務(wù)端不是http/https等友好協(xié)議该面，是二進(jìn)制協(xié)議咋辦
客戶端應(yīng)用程序不支持服務(wù)器端使用的協(xié)議（如 AMQP 或二進(jìn)制協(xié)議）夭苗。因此，請(qǐng)求必須通過 HTTP/HTTPS 等協(xié)議轉(zhuǎn)換為其他協(xié)議隔缀。在這種情況下又該如何去做题造？
-
如何打造一個(gè)專門為移動(dòng)應(yīng)用提供的服務(wù)呢？
多個(gè)微服務(wù)的API可能無法很好地滿足不同客戶端應(yīng)用程序的需求猾瘸。例如界赔，移動(dòng)應(yīng)用程序的需求可能與PC應(yīng)用程序的需求不同。對(duì)于移動(dòng)應(yīng)用程序來說牵触，可能需要進(jìn)一步優(yōu)化以提高數(shù)據(jù)響應(yīng)效率淮悼。我們可以通過聚合來自多個(gè)微服務(wù)的數(shù)據(jù)并返回一組數(shù)據(jù)來實(shí)現(xiàn)此功能，有時(shí)還可以在響應(yīng)中過濾移動(dòng)應(yīng)用程序不需要的任何數(shù)據(jù)揽思。當(dāng)然袜腥，我們也可以壓縮響應(yīng)數(shù)據(jù)。像這樣的聚合或者壓縮數(shù)據(jù)等行為到底有誰來做是最合適的呢钉汗？
2. 引入API Gateway網(wǎng)關(guān)
上面的所有問題都靠API Gateway搞定羹令，而且還有很多問題我們雖然沒有提到，但是Gateway統(tǒng)統(tǒng)都可以幫你搞定损痰。
2.1 什么是API網(wǎng)關(guān)模式
當(dāng)你為多端應(yīng)用程序提供服務(wù)而準(zhǔn)備設(shè)計(jì)和構(gòu)建龐大且復(fù)雜的基于微服務(wù)的后臺(tái)應(yīng)用程序的時(shí)候福侈，可以考慮使用API Gateway。此模式是為特定微服務(wù)組提供單一入口點(diǎn)的服務(wù)卢未。它類似于面向?qū)ο笤O(shè)計(jì)中的Facade模式肪凛，但在本例中，它是分布式系統(tǒng)的一部分辽社。API網(wǎng)關(guān)模式有時(shí)也被稱為BFF模式伟墙，因?yàn)槲覀冊(cè)跇?gòu)建它時(shí)考慮了客戶端應(yīng)用程序的需求。
2.2 那什么是Facade模式爹袁？
Facade模式是面向?qū)ο缶幊讨谐Ｓ玫能浖O(shè)計(jì)模式远荠。一個(gè)facade對(duì)象它作為一個(gè)前置接口矮固，掩蓋了更復(fù)雜的底層代碼或結(jié)構(gòu)代碼失息。就比如linux操作系統(tǒng)的文件讀寫操作，林納斯·托瓦茲不可能給你復(fù)雜的讀寫文件邏輯档址，他就給你提供四五個(gè)簡(jiǎn)單的api盹兢，比如read,write,open and create等，人家沒必要再給你解釋inode是啥守伸，段又是啥绎秒，文件句柄又是啥，這要解釋下來沒完沒了尼摹，估計(jì)linux也不會(huì)發(fā)展到現(xiàn)在见芹，作者有意屏蔽底層實(shí)現(xiàn)細(xì)節(jié)剂娄，提供高度抽象的api就是讓你愛上linux，而不是唾棄這樣偉大的產(chǎn)品玄呛。
所以這樣看來Facade模式和網(wǎng)關(guān)模式?jīng)]啥區(qū)別阅懦，都是提供單一入口點(diǎn)的服務(wù)，但是因?yàn)锳pi Gateway誕生于微服務(wù)架構(gòu)體系中徘铝，所以它屬于分布式系統(tǒng)架構(gòu)中的一部分耳胎，進(jìn)而在各大公司中發(fā)展壯大起來。
2.3 什么又是BFF模式惕它？
BFF模式我前面講過了 怕午，大家回頭可以看下。我這里也再說一遍：就是當(dāng)你的app想要獲取多個(gè)微服務(wù)去渲染一個(gè)頁面的時(shí)候淹魄，這個(gè)過程會(huì)經(jīng)過多次的網(wǎng)絡(luò)請(qǐng)求郁惜，勢(shì)必會(huì)增加延遲和復(fù)雜性，為了避免這一類問題的發(fā)生或者說減少這類問題的影響甲锡，我們?cè)诩軜?gòu)模式中抽離出來一種模式叫做BFF模式扳炬，它專門用來做一件事情：就是根據(jù)app的請(qǐng)求模式，它先把所有要請(qǐng)求多個(gè)微服務(wù)的數(shù)據(jù)聚合任務(wù)在它這里做了搔体，它本身也是一個(gè)微服務(wù)恨樟，所以可以對(duì)外提供一個(gè)接口就行了，這樣app就不用請(qǐng)求多次了疚俱。就這么簡(jiǎn)單劝术。
我們已經(jīng)知道了什么是網(wǎng)關(guān)模式，那么很明顯網(wǎng)關(guān)模式是屬于BFF中的一種呆奕，而BFF會(huì)有很多種實(shí)現(xiàn)方式养晋，這也就回答了前面第一個(gè)問題。
應(yīng)用程序連接到單個(gè)服務(wù)梁钾，即API網(wǎng)關(guān)绳泉，該服務(wù)配置了路由轉(zhuǎn)發(fā)規(guī)則，將請(qǐng)求轉(zhuǎn)發(fā)到各個(gè)微服務(wù)姆泻。
這樣我們就可以把鑒權(quán)零酪，安全，限流拇勃，轉(zhuǎn)換等與業(yè)務(wù)無關(guān)的邏輯在這個(gè)里面就做了四苇，然后流量透?jìng)鞯胶蠖宋⒎?wù)處理就行了，后端再也不用做跟業(yè)務(wù)無關(guān)的需求了方咆。
但是上述方式有瓶頸月腋，所有服務(wù)都經(jīng)由一個(gè)API Gateway， 隨著接入的業(yè)務(wù)越來越多，它不斷的增長(zhǎng)和演變榆骚，最終片拍，它會(huì)因?yàn)檫@些不同的需求而變得臃腫，實(shí)際上它可能類似于單體應(yīng)用程序或單體服務(wù)了妓肢，那這個(gè)時(shí)候就要小心了穆碎，它可能違反了微服務(wù)自治。
我們目前的做法就是把一個(gè)大的API Gateway根據(jù)業(yè)務(wù)邊界和客戶端應(yīng)用程序進(jìn)行隔離职恳，拆分成一個(gè)個(gè)小的Gateway所禀，這樣我們就可以針對(duì)每個(gè)客戶端應(yīng)用程序的需求使用不同的Gateway。如下圖放钦，多個(gè)API Gateway：
基本上現(xiàn)有大公司的微服務(wù)架構(gòu)都是這套模式色徘，有的可能在API Gateway和微服務(wù)之間再加一個(gè)BFF，專門解決數(shù)據(jù)聚合的問題操禀，但這都是基于這套基本的架構(gòu)模式褂策，因此掌握了這套架構(gòu)，你就不是小白了颓屑。
3. API Gateway模式的主要特性
3.1 反向代理或路由
API網(wǎng)關(guān)提供了一個(gè)反向代理來將請(qǐng)求（第7層路由斤寂，通常是HTTP請(qǐng)求）重定向或路由到內(nèi)部微服務(wù)。
3.2 請(qǐng)求聚合
作為網(wǎng)關(guān)模式的一部分揪惦，我們可以將針對(duì)多個(gè)客戶端請(qǐng)求多個(gè)內(nèi)部微服務(wù)的請(qǐng)求（通常是 HTTP 請(qǐng)求）聚合到一個(gè)Gateway中遍搞，當(dāng)客戶端頁面需要來自多個(gè)微服務(wù)的信息時(shí)，這種模式特別方便器腋。
3.3 插件管理
根據(jù)每個(gè)API Gateway產(chǎn)品提供的功能溪猿，我們可以將某些插件從網(wǎng)關(guān)中卸載或者設(shè)置上，例如如下功能：
- 認(rèn)證和授權(quán)
- 服務(wù)發(fā)現(xiàn)
- 響應(yīng)緩存
- 重試策略纫塌、降級(jí)
- 限流
- 負(fù)載均衡
- 鏈路追蹤
- 協(xié)議轉(zhuǎn)換
- 黑白名單
- 灰度發(fā)布
上面我們有說灰度發(fā)布诊县，其實(shí)就是在API Gateway中做的，實(shí)現(xiàn)方式多樣化措左，因?yàn)槟愣寄玫搅髁苛艘廊朐谶@個(gè)上面灰度，你可以在header頭中加一個(gè)標(biāo)識(shí)怎披，然后在Gateway中配置下灰度轉(zhuǎn)發(fā)路由胸嘁，這樣你就將灰度流量轉(zhuǎn)發(fā)到灰度環(huán)境了，而你的灰度環(huán)境也不要硬編碼來判斷那些人需要灰度以及header中是否有灰度標(biāo)識(shí)钳枕。
我們這里的灰度標(biāo)識(shí)就是落日志用的缴渊，為了統(tǒng)計(jì)灰度環(huán)境的穩(wěn)定性和功能性的，有了這個(gè)標(biāo)識(shí)就可以在日志中有了區(qū)分鱼炒。
4. API Gateway缺點(diǎn)
- 單點(diǎn)故障
- 額外的網(wǎng)絡(luò)調(diào)用，API網(wǎng)關(guān)可能會(huì)增加響應(yīng)時(shí)間
- API網(wǎng)關(guān)設(shè)計(jì)不合理蝌借，擴(kuò)展就很麻煩
- 如果API Gateway是由單個(gè)團(tuán)隊(duì)開發(fā)昔瞧，可能會(huì)出現(xiàn)開發(fā)瓶頸
缺點(diǎn)都是隨著業(yè)務(wù)的不斷增長(zhǎng)而不斷變化的指蚁，擁抱變化才是好心態(tài)。
5. 小結(jié)
首先介紹了客戶端直連微服務(wù)模式自晰，其次介紹了API網(wǎng)關(guān)模式凝化，其實(shí)不管是那種模式都是軟件架構(gòu)的正常迭代過程，可能下一代就會(huì)發(fā)生天翻覆地的變化酬荞，所以懷抱一顆真誠學(xué)習(xí)的心就是了搓劫，成長(zhǎng)永不落后，怕的就是不敢于突破現(xiàn)在的自己混巧，加油枪向。
