微服務不能沒有網(wǎng)關，就如同 Java 程序員不能沒有IDEA、Eclipse。為什么呢?

之所以網(wǎng)關對微服務這么重要，主要有以下幾點原因：

1. 解決 API 放哪里的問題

要知道，采用微服務架構的系統(tǒng)本身是由很多的獨立服務單元組合起來的。而客戶端要調用系統(tǒng)，則必須通過系統(tǒng)提供的各種對外開放的 API 來實現(xiàn)。

問題來了，這些 API 要放在哪里呢?直接放在組成系統(tǒng)的服務單元上行不行?

比如，在一套電商系統(tǒng)上，關于訂單相關的 API ，放在組成訂單服務的服務單元上;風控服務的 API ，放在組成風控服務的服務單元上。

好，咱們假設有這么一個場景，有一位用戶想在這套電商系統(tǒng)上查看下商品詳情。那么，這個查看商品詳情的操作，就可能：

• 調用商品服務的 API 獲取商品描述
• 調用評價服務的 API 獲取相關評價
• 調用商家服務的 API 獲取商家信息
• 調用禮券服務的 API 獲取相關禮券
• ……

可以看到，就這么一個商品查看操作，就可能會調用許多服務的 API。

那這些 API 如果全部分散到各個服務單元上，供客戶端調用，像查看商品這么簡單的一次操作，客戶端就可能需要遠程訪問好幾次甚至十幾次服務器。

微服務自己又講究把 API 的粒度劃分的很細，也就是說，可能從商品服務上調用商品信息，不止是調用一次商品服務就夠了，很可能需要多次對商品服務的不同 API 進行調用，才能獲取到足夠的數(shù)據(jù)。

這樣一來，客戶端需要訪問服務器的次數(shù)就更多了，可能十幾次都不夠，得幾十次。

這種多次訪問服務器的行為，會極大延遲客戶端的界面響應時間，很不現(xiàn)實。

所以，把 API 放到各個業(yè)務相關的服務單元上，看上去問題很大。

那為什么引入網(wǎng)關就能解決這個問題呢?

因為引入網(wǎng)關，就相當于在客戶端和微服務之間加了一層隔離。通常，網(wǎng)關本身會和各個服務單元處于同一個機房，這樣，客戶端做業(yè)務操作的時候，只需要訪問一次網(wǎng)關。然后剩下的事情，再由網(wǎng)關分別訪問同在一個機房的不同的服務，再把拿到的數(shù)據(jù)統(tǒng)一在網(wǎng)關封裝好，返回給客戶端就好。

2. 解決邊緣功能集成的問題

在一套微服務組成的系統(tǒng)里，除了必須的業(yè)務功能以外，還有為了系統(tǒng)自身的健壯與安全，以及微服務本身的管理，而必須引入的一些非業(yè)務功能。對于這些非業(yè)務又很重要的功能，我們統(tǒng)稱為邊緣功能。

還是拿電商系統(tǒng)為例，我們來看一些重要的邊緣功能。

假設因為我們做了一次非常大的促銷活動，導致流量過大，系統(tǒng)承載不了了。此時，為了保證系統(tǒng)本身的穩(wěn)定，我們就需要把一些承載不了的流量給通過各種手段消化掉，一般的做法有三種：

• 限流：通過令牌桶等算法，把一些額外的流量擋在系統(tǒng)外面，不讓其訪問。
• 降級：由于系統(tǒng)可能已經(jīng)過載了，此時，我們就放棄處理一些服務和頁面的請求或者僅簡單處理，比如直接返回一個報錯。
• 熔斷：有些時候，系統(tǒng)過載過度或者上線出了 bug，降級都解決不了問題。比如，緩存失效了，導致大量請求頻繁訪問了數(shù)據(jù)庫，而這種頻繁訪問數(shù)據(jù)庫可能造成了大量的 IO 操作，結果又去影響了數(shù)據(jù)庫所在的操作系統(tǒng)，同時，這個操作系統(tǒng)上又有著別的重要服務，直接也被影響了。對于這種連鎖反應，我們稱之為雪崩。而為了防止雪崩，我們就會堅決把緩存失效導致數(shù)據(jù)庫被頻繁訪問的服務給停掉，這就是熔斷。

可以看到，像限流、降級、熔斷這些系統(tǒng)保障策略，最合適的地方應該是有一個集中的請求入口點，就像古時候，老百姓進城需要過城門那樣。

當系統(tǒng)出現(xiàn)問題的時候，直接就在這個入口點做相應的操作即可。

• 限流，就直接在這個入口點限制后續(xù)請求。
• 降級，就直接在這個入口點判斷請求想要訪問的服務或者頁面，直接報錯返回。
• 熔斷，就直接在這個入口點，斷開所有訪問特定服務的請求連接，然后再把后繼對特定服務的訪問，也統(tǒng)統(tǒng)攔在門外。

在電商系統(tǒng)里，有很多特殊場景的接口，需要受到嚴格的限制。

比如，支付接口，訪問它就需要認證和權限控制。又比如，對于系統(tǒng)的訪問，有時候不能讓國外的去訪問國內的網(wǎng)站，這就需要限制客戶端的訪問 IP，所以系統(tǒng)還需要認證和授權功能。

那這種認證和授權也最合適放在請求的一個集中入口點，統(tǒng)一實現(xiàn)。

還記得上面咱們說過的網(wǎng)關的 API 統(tǒng)一存放嗎?我們只需要對這些 API 做對應的權限設置，當請求訪問特殊場景接口的時候，必定會通過 API 訪問。所以，限制接口的訪問，本質上就是對特定 API 的限制，那么，放在網(wǎng)關再合適不過了。

現(xiàn)實里，我們有時候需要把線上的流量鏡像出來，轉發(fā)到灰度環(huán)境，利用這些鏡像出來的流量既可以用于小范圍測試，又可以更好的評估系統(tǒng)所能承載的最大吞吐量，也因此，系統(tǒng)需要有一個統(tǒng)一入口做分流。

可以看到，無論是系統(tǒng)需要的保障策略，認證授權，還是流量分流等功能，都應該放到一個統(tǒng)一的請求入口處才能得到最好的實現(xiàn)。網(wǎng)關恰好就承擔了這么個統(tǒng)一請求入口的角色。

所以，對于微服務中，林林總總的邊緣功能，往往會通過插件的形式，集成在 API 網(wǎng)關中。

3. 解耦了客戶端和后端微服務

一套項目，在使用微服務模式的初期，往往后端變化是十分頻繁的。

頻繁變化的原因有很多，像業(yè)務領域劃分不合適啊，像某個業(yè)務模塊急速膨脹啊，都可能導致后端微服務的劇烈變化。

在這種情況下，如果沒有網(wǎng)關，很可能就會出現(xiàn)客戶端需要被迫隨著后端的變化而變化的情況。

比如，在電商系統(tǒng)里，初期我們很可能會把風控服務做的非常小。隨著業(yè)務的發(fā)展，風控服務越來越龐大，此時，風控服務就可能被分解為決策引擎和分析中心等更多更細的服務。

在電商里，風控往往是下單、支付等操作的必要前置操作。如果沒有網(wǎng)關去分隔開客戶端和微服務，客戶端直接和風控服務打交道，那么風控服務拆分，API 必然不會穩(wěn)定，API 的變化，自然會引發(fā)調用 API 客戶端代碼的變化。

有了網(wǎng)關之后，情況就好了很多了。當風控服務本身頻繁變化的時候，我們只需要改動網(wǎng)關的代碼就好。而服務器代碼的升級可是遠遠要比客戶端代碼的升級容易太多了。

本文轉載自微信公眾號「四猿外」，可以通過以下二維碼關注。轉載本文請聯(lián)系四猿外公眾號。