一、為什么需要「 API網關 」？

為什么做微服務的需要「 API網關 」呢？「 API網關 」到底有些啥功能呢？我們以前項目結構比較簡單的時候有用到過「 API網關 」概念的模塊嗎？

其實在我們的項目曾經還是單體應用的時候，雖然沒有「 API網關 」的概念，但是一般在項目中都會用到filter/過濾器之類的東西，filter的作用就是把項目中的一些非業務邏輯的功能抽離出來獨立處理，避免與業務邏輯混在一起增加代碼復雜度。比如 鑒權認證功能、Session處理、安全檢查、日志處理等等。

現在我們采用微服務架構了，在一個項目中微服務節點很多，如果讓每一個節點都去處理上面這些 “鑒權認證功能、Session處理、安全檢查、日志處理等” 會多出很多冗余的代碼，也會給增加業務代碼的復雜度，因此我們就需要有一個「 API網關 」把這些公共的功能獨立出來成為一個服務來統一的處理這些事情。

我們看一下下面這個微服務架構示意圖：

「 API網關 」就像是微服務的大門守衛一樣，是連通外部客戶端與內部微服務之間的一個橋梁。

其主要功能有：

• 路由轉發

  之前說了「API網關」是內部微服務的對外唯一入口，所以外面全部的請求都會先發到這個「API網關」上，然后由「API網關」來根據不同的請求去路由到不同的微服務節點上。例如可以 根據路徑 來轉發、也可以 根據參數 來轉發。

  并且由于內部微服務實例也會隨著業務調整不停的變更，增加或者刪除節點，「API網關」可以與「服務注冊」模塊進行協同工作，保證將外部請求轉發到最合適的微服務實例上面去。

• 負載均衡

  既然「API網關」是內部微服務的單一入口，所以「API網關」在收到外部請求之后，還可以根據內部微服務每個實例的負荷情況進行動態的負載均衡調節。一旦內部的某個微服務實例負載很高，甚至是不能及時響應，則「API網關」就通過負載均衡策略減少或停止向這個實例轉發請求。當所有的內部微服務實例都處理不過來的時候，「API網關」還可以采用限流或熔斷的形式阻止外部請求，以保障整個系統的可用性。

• 安全認證

  「API網關」就像是微服務的大門守衛，每一個請求進來之后，都必須先在「API網關」上進行身份驗證，身份驗證通過后才轉發給后面的服務，轉發的時候一般也會帶上身份信息。

  同時「API網關」也需要對每一個請求進行安全性檢查，例如參數的安全性、傳輸的安全性等等。

• 日志記錄

  既然所有的請求都需要走「API網關」，那么我們就可以在「API網關」上統一集中的記錄下這些行為日志。這些日志既可以作為我們后續事件查詢使用，也可以作為系統的性能監控使用。

• 數據轉換

  因為「API網關」對外是面向多種不同的客戶端，不同的客戶端所傳輸的數據類型可能是不一樣的。因此「API網關」還需要具備數據轉換的功能，將不同客戶端傳輸進來的數據轉換成同一種類型再轉發給內部微服務上，這樣，兼容了這些請求的多樣性，保證了微服務的靈活性。

二、「 API網關 」原理與應用？

上面聊完了「為什么需要API網關」，我們再來看一下在實際項目中應該如何去應用。雖然我們可以自己去開發一套「API網關」，但是如果沒有特殊需求，還是不建議重復造輪子了，市面上有很多成熟的方案可以直接使用，下面簡單介紹一下 Zuul、Tyk、Kong三個比較熱門的開源組件。

• Zuul

  

  Zuul 是由 Netflix 所開源的組件，基于JAVA技術棧開發的。

  Zuul網關的使用熱度非常高，并且也集成到了 Spring Cloud 全家桶中了，使用起來非常方便。

  

  Tyk是一個基于GO編寫的，輕量級、快速可伸縮的開源的API網關。

  可以通過下圖簡單了解一下Tyk的流程原理。

  

• Kong是基于OpenResty技術棧的開源網關服務，因此其也是基于Nginx實現的。

  Kong可以做到高性能、插件自定義、集群以及易于使用的Restful API管理。