玩過微服務(wù)的小伙伴對 Spring Cloud 中的的 Spring Cloud Gateway 多多少少都有一些了解，松哥之前既寫過相關(guān)的文章，也錄過相關(guān)的視頻跟小伙伴們介紹 Spring Cloud Gateway，不過在之前的介紹中，我可能更加側(cè)重于跟小伙伴們介紹 Spring Cloud Gateway 的用法，對于我們在微服務(wù)中為什么要使用 Spring Cloud Gateway 可能沒有和大家仔細分析過，最近年前得空，我們來一起探討一下這個話題。

說起 Spring Cloud Gateway 的使用場景，我相信很多小伙伴都能夠脫口而出認證二字，確實，在網(wǎng)關(guān)中完成認證操作，確實是 Gateway 的重要使用場景之一，然而并不是唯一的使用場景。在微服務(wù)中使用網(wǎng)關(guān)的好處可太多了，今天我們就來逐一分析一下。

1. 請求路由

首先，Gateway 的第一個重要特點就是對請求進行路由，根據(jù)不同的請求頭、請求參數(shù)、請求路徑等，將請求路由到不同的服務(wù)上。

從這個角度來說，Spring Cloud Gateway 所扮演的角色與 Nginx 這一類的反向代理服務(wù)器類似，之前就有小伙伴問我，Spring Cloud Gateway 和 Nginx 有啥區(qū)別？能不能用 Nginx 代替 Spring Cloud Gateway？其實，你要是單純的只看請求路由這一個功能，那么確實可以用 Nginx 代替 Spring Cloud Gateway，然而在實際開發(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)的另一個作用就是可以實現(xiàn) API 的組合。當(dāng)然這個一般來說需要一些代碼開發(fā)，單純的配置一般來說是無法實現(xiàn)需求的。

先來說說沒有網(wǎng)關(guān)的時候我們可能會存在什么情況。

以松哥最近在錄的 TienChin 項目視頻為例，我有一個活動管理服務(wù)，也就是健身房定期會做一些促銷活動，促銷活動往往又分為線上或者線下，線上線下又繼續(xù)細分為不同的渠道，如小紅書推廣、抖音推廣、公眾號推廣、線下地推等等，所以，假設(shè)我現(xiàn)在要做一個修改活動的功能，那么當(dāng)我選中一條記錄，點擊修改按鈕，此時，客戶端至少要發(fā)送兩條請求：

1. 首先根據(jù)我選中的記錄的 ID，去服務(wù)端查詢這條記錄當(dāng)前的值。
2. 去查詢活動渠道，因為活動記錄中保存的是渠道 ID，我們得去查詢所有的渠道信息，然后根據(jù)渠道信息才能顯示出來具體的渠道。

畫一張簡單的架構(gòu)圖，類似下面這樣：

如上圖所示，如果你是一個微服務(wù)項目，但是卻沒有網(wǎng)關(guān)，那么前端用戶一個點擊事件你可能需要在后臺發(fā)出 N 多個操作。并且，這 N 多個操作還都屬于互聯(lián)網(wǎng)請求，小伙伴們知道，互聯(lián)網(wǎng)請求的一個特點就是低帶寬和高延遲，連著發(fā)送兩個甚至多個請求，用戶體驗肯定不佳。

像這樣的場景，如果我們有網(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ā)送了兩次，不一定省時間。其實不然！網(wǎng)關(guān)往往和微服務(wù)處于同一個局域網(wǎng)之中，相比于互聯(lián)網(wǎng)，局域網(wǎng)的通信延遲就要小很多了。

這是網(wǎng)關(guān)的第二個作用。

3. 協(xié)議切換

通過網(wǎng)關(guān)我們還能實現(xiàn)請求協(xié)議的切換。

一般來說我們暴露給外部的服務(wù)都是 RESTful API，但是，有時候考慮到服務(wù)內(nèi)部的執(zhí)行效率問題，我們可以在服務(wù)內(nèi)容實用其他更高效的協(xié)議，通過服務(wù)網(wǎng)關(guān)就可以實現(xiàn)這個切換。

當(dāng)然，這并不是必須的，只是說，當(dāng)我們在微服務(wù)中使用了網(wǎng)關(guān)之后，如果想做請求協(xié)議的切換，就會比較容易實現(xiàn)。

4. 限流

微服務(wù)中的限流操作，一個比較好的限流位置就是網(wǎng)關(guān)了，我們可以利用 Alibaba 的 Sentinel 結(jié)合 Spring Cloud Gateway 就可以非常方便的實現(xiàn)限流操作。

5. 請求分析

如果我們需要統(tǒng)計某一個請求的細節(jié)，如執(zhí)行時間、參數(shù)等信息，那么這個操作也可以在網(wǎng)關(guān)上來做，在網(wǎng)關(guān)上對請求進行詳細分析。

6. 緩存

對于一些不經(jīng)常變化的數(shù)據(jù)，我們可以設(shè)置緩存時間，在網(wǎng)關(guān)上直接進行檢查，如果緩存還沒失效，直接響應(yīng) 304，讓從客戶端讀取即可。

7. 認證

這個是大家比較熟悉的了。

一般來說，我們可能會有單獨的認證服務(wù)，當(dāng)認證請求到達網(wǎng)關(guān)之后，網(wǎng)關(guān)將之轉(zhuǎn)發(fā)到相應(yīng)的認證服務(wù)上去完成認證。對于非認證請求，到達網(wǎng)關(guān)的時候需要校驗這個請求是否有進行認證，這個校驗就沒必要轉(zhuǎn)發(fā)了，可以直接在網(wǎng)關(guān)上進行校驗。

松哥舉個簡單的例子，也是我自己之前在項目中的一個實踐經(jīng)驗，就是用戶登錄請求到達網(wǎng)關(guān)之后，網(wǎng)關(guān)將之轉(zhuǎn)發(fā)到專門的認證服務(wù)上去（由于認證的過程往往需要操作用戶數(shù)據(jù)庫，所以不要在網(wǎng)關(guān)上做認證，轉(zhuǎn)發(fā)到專門的認證服務(wù)上去做認證操作），認證成功之后，返回 JWT 字符串給前端。下一次，請求帶著 JWT 字符串來到網(wǎng)關(guān)，可以直接在網(wǎng)關(guān)上校驗 JWT 字符串，這個校驗本身比較容易，又不需要連接數(shù)據(jù)庫，所以可以在網(wǎng)關(guān)上完成，校驗成功之后，將校驗得到的用戶信息放到請求頭中，然后再轉(zhuǎn)發(fā)請求到不同的微服務(wù)上，這樣在各個微服務(wù)上，就知道請求的用戶到底是誰了。

8. 記錄請求日志

如果需要記錄請求日志，網(wǎng)關(guān)也是一個好地方。

網(wǎng)關(guān)能干這么多事，so，想要用 Nginx 代替 Spring Cloud Gateway 顯然不太現(xiàn)實。