客戶端需要多次提出要求，要求不同域名對應的服務，增加了通信成本和維護客戶端代碼的復雜性。

每一項服務都會單獨進行服務驗證，如果每一項服務驗證的邏輯不同，就會導致客戶端反復驗證。

此外，如果每個服務都采用不同的協議，那么對客戶來說就是災難性的。

基于以上，我們需要一個中間層，讓客戶端要求中間層。至于需要請求的服務，我們需要請求中間部分，最后把結果總結回客戶端。這個中間層是網關。

為何使用網關？

使用網關有幾個功能：

統一鑒權

一般來說，我們在網關上評估權利有兩種:1。它是對客戶端身份的認證。2.訪問權限控制是在確認用戶身份后，判斷是否有訪問某一資源的權限。曾經我們在單個應用中，客戶端要求驗證身份和對資源權限的約束相對簡單，相應的用戶和權限信息可以通過要求的session獲得。但是在微服務架構下，所有的服務都被拆分成單個微服務，集群部署會變得復雜，因為如果我們仍然使用session，我們將在每個分布式平臺上尋求相同的效果。

日志記錄

當客戶端要求進入時，我們需要記錄當前要求的時間依賴于來源、地址、ip等信息，這樣我們就可以在網關層面統一攔截獲取，然后通過ELK組件輸出到日志文件中，記錄內容可以在不分別記錄的情況下，在多維度、多信息統一記錄。網關模塊方案

要求分發和過濾

對于網關來說，匹配和分發這個請求是最重要的功能。事實上，我們常見的nginx有一個請求轉發和過濾的功能。對于網關來說，請求可以前后過濾。

請求分發:接受客戶端的請求，將請求與后面的微服務相對應，并請求微服務。因為微服務的粒度比較細，這個網關可以整合各種微服務的功能，最后還給客戶端。

過濾器：網關將攔截所有請求，相當于spring中AOP的一個橫截面，在此截面上進行鑒權、限流、認證等操作。

灰度發布

一般來說，公司的互聯網產品迭代非常快，基本上是小步快跑。基本上每周發布一次版本迭代。在這種情況下，會出現兼容性、功能完整性、bug最終發生事故等風險。一般來說，當我們發布它時，我們會將新功能發布到指定的機器上，并劃分過去的一小部分流量來觀察具體情況。因此，這個功能可以通過網關作為請求的入口來完成。