為什么我們的微服務(wù)中需要網(wǎng)關(guān)?
玩過微服務(wù)的小伙伴對 Spring Cloud 中的的 Spring Cloud Gateway 多多少少都有一些了解,松哥之前既寫過相關(guān)的文章,也錄過相關(guān)的視頻跟小伙伴們介紹 Spring Cloud Gateway,不過在之前的介紹中,我可能更加側(cè)重于跟小伙伴們介紹 Spring Cloud Gateway 的用法,對于我們在微服務(wù)中為什么要使用 Spring Cloud Gateway 可能沒有和大家仔細(xì)分析過,最近年前得空,我們來一起探討一下這個話題。
說起 Spring Cloud Gateway 的使用場景,我相信很多小伙伴都能夠脫口而出認(rèn)證二字,確實(shí),在網(wǎng)關(guān)中完成認(rèn)證操作,確實(shí)是 Gateway 的重要使用場景之一,然而并不是唯一的使用場景。在微服務(wù)中使用網(wǎng)關(guān)的好處可太多了,今天我們就來逐一分析一下。
1. 請求路由
首先,Gateway 的第一個重要特點(diǎn)就是對請求進(jìn)行路由,根據(jù)不同的請求頭、請求參數(shù)、請求路徑等,將請求路由到不同的服務(wù)上。
從這個角度來說,Spring Cloud Gateway 所扮演的角色與 Nginx 這一類的反向代理服務(wù)器類似,之前就有小伙伴問我,Spring Cloud Gateway 和 Nginx 有啥區(qū)別?能不能用 Nginx 代替 Spring Cloud Gateway?其實(shí),你要是單純的只看請求路由這一個功能,那么確實(shí)可以用 Nginx 代替 Spring Cloud Gateway,然而在實(shí)際開發(fā)中,我們 Spring Cloud Gateway 所承擔(dān)的責(zé)任可不僅僅是請求路由轉(zhuǎn)發(fā),還有其他方面的功能(后文有介紹),其他的功能用 Nginx 做起來就有一些吃力了。
如果用 Spring Cloud Gateway 做請求路由轉(zhuǎn)發(fā),我們可以畫一張簡單的架構(gòu)圖,如下:
2. API 組合
網(wǎng)關(guān)的另一個作用就是可以實(shí)現(xiàn) API 的組合。當(dāng)然這個一般來說需要一些代碼開發(fā),單純的配置一般來說是無法實(shí)現(xiàn)需求的。
先來說說沒有網(wǎng)關(guān)的時候我們可能會存在什么情況。
以松哥最近在錄的 TienChin 項目視頻為例,我有一個活動管理服務(wù),也就是健身房定期會做一些促銷活動,促銷活動往往又分為線上或者線下,線上線下又繼續(xù)細(xì)分為不同的渠道,如小紅書推廣、抖音推廣、公眾號推廣、線下地推等等,所以,假設(shè)我現(xiàn)在要做一個修改活動的功能,那么當(dāng)我選中一條記錄,點(diǎn)擊修改按鈕,此時,客戶端至少要發(fā)送兩條請求:
首先根據(jù)我選中的記錄的 ID,去服務(wù)端查詢這條記錄當(dāng)前的值。
去查詢活動渠道,因?yàn)榛顒佑涗浿斜4娴氖乔?ID,我們得去查詢所有的渠道信息,然后根據(jù)渠道信息才能顯示出來具體的渠道。
畫一張簡單的架構(gòu)圖,類似下面這樣:
如上圖所示,如果你是一個微服務(wù)項目,但是卻沒有網(wǎng)關(guān),那么前端用戶一個點(diǎn)擊事件你可能需要在后臺發(fā)出 N 多個操作。并且,這 N 多個操作還都屬于互聯(lián)網(wǎng)請求,小伙伴們知道,互聯(lián)網(wǎng)請求的一個特點(diǎn)就是低帶寬和高延遲,連著發(fā)送兩個甚至多個請求,用戶體驗(yàn)肯定不佳。
像這樣的場景,如果我們有網(wǎng)關(guān),就可以在網(wǎng)關(guān)中提供一個粗粒度的 API,這樣,前端只需要發(fā)送一個請求到網(wǎng)關(guān),然后又網(wǎng)關(guān)去發(fā)送多個請求,從不同的微服務(wù)上把數(shù)據(jù)拿回來再統(tǒng)一返回給前端。如下圖:
可能有小伙伴會說,你這個請求還是發(fā)送了兩次,不一定省時間。其實(shí)不然!網(wǎng)關(guān)往往和微服務(wù)處于同一個局域網(wǎng)之中,相比于互聯(lián)網(wǎng),局域網(wǎng)的通信延遲就要小很多了。
這是網(wǎng)關(guān)的第二個作用。
3. 協(xié)議切換
通過網(wǎng)關(guān)我們還能實(shí)現(xiàn)請求協(xié)議的切換。
一般來說我們暴露給外部的服務(wù)都是 RESTful API,但是,有時候考慮到服務(wù)內(nèi)部的執(zhí)行效率問題,我們可以在服務(wù)內(nèi)容實(shí)用其他更高效的協(xié)議,通過服務(wù)網(wǎng)關(guān)就可以實(shí)現(xiàn)這個切換。
當(dāng)然,這并不是必須的,只是說,當(dāng)我們在微服務(wù)中使用了網(wǎng)關(guān)之后,如果想做請求協(xié)議的切換,就會比較容易實(shí)現(xiàn)。
4. 限流
微服務(wù)中的限流操作,一個比較好的限流位置就是網(wǎng)關(guān)了,我們可以利用 Alibaba 的 Sentinel 結(jié)合 Spring Cloud Gateway 就可以非常方便的實(shí)現(xiàn)限流操作。
5. 請求分析
如果我們需要統(tǒng)計某一個請求的細(xì)節(jié),如執(zhí)行時間、參數(shù)等信息,那么這個操作也可以在網(wǎng)關(guān)上來做,在網(wǎng)關(guān)上對請求進(jìn)行詳細(xì)分析。
6. 緩存
對于一些不經(jīng)常變化的數(shù)據(jù),我們可以設(shè)置緩存時間,在網(wǎng)關(guān)上直接進(jìn)行檢查,如果緩存還沒失效,直接響應(yīng) 304,讓從客戶端讀取即可。
7. 認(rèn)證
這個是大家比較熟悉的了。
一般來說,我們可能會有單獨(dú)的認(rèn)證服務(wù),當(dāng)認(rèn)證請求到達(dá)網(wǎng)關(guān)之后,網(wǎng)關(guān)將之轉(zhuǎn)發(fā)到相應(yīng)的認(rèn)證服務(wù)上去完成認(rèn)證。對于非認(rèn)證請求,到達(dá)網(wǎng)關(guān)的時候需要校驗(yàn)這個請求是否有進(jìn)行認(rèn)證,這個校驗(yàn)就沒必要轉(zhuǎn)發(fā)了,可以直接在網(wǎng)關(guān)上進(jìn)行校驗(yàn)。
松哥舉個簡單的例子,也是我自己之前在項目中的一個實(shí)踐經(jīng)驗(yàn),就是用戶登錄請求到達(dá)網(wǎng)關(guān)之后,網(wǎng)關(guān)將之轉(zhuǎn)發(fā)到專門的認(rèn)證服務(wù)上去(由于認(rèn)證的過程往往需要操作用戶數(shù)據(jù)庫,所以不要在網(wǎng)關(guān)上做認(rèn)證,轉(zhuǎn)發(fā)到專門的認(rèn)證服務(wù)上去做認(rèn)證操作),認(rèn)證成功之后,返回 JWT 字符串給前端。下一次,請求帶著 JWT 字符串來到網(wǎng)關(guān),可以直接在網(wǎng)關(guān)上校驗(yàn) JWT 字符串,這個校驗(yàn)本身比較容易,又不需要連接數(shù)據(jù)庫,所以可以在網(wǎng)關(guān)上完成,校驗(yàn)成功之后,將校驗(yàn)得到的用戶信息放到請求頭中,然后再轉(zhuǎn)發(fā)請求到不同的微服務(wù)上,這樣在各個微服務(wù)上,就知道請求的用戶到底是誰了。
8. 記錄請求日志
如果需要記錄請求日志,網(wǎng)關(guān)也是一個好地方。
網(wǎng)關(guān)能干這么多事,so,想要用 Nginx 代替 Spring Cloud Gateway 顯然不太現(xiàn)實(shí)。