爲什麼需要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網關」，但是如果沒有特殊需求，還是不建議重複造輪子了，市面上有很多成熟的方案可以直接使用，下面簡單介紹一下 Zuul、Tyk、Kong三個比較熱門的開源組件。
Zuul
Zuul 是由 Netflix 所開源的組件，基於JAVA技術棧開發的。
Zuul網關的使用熱度非常高，並且也集成到了 Spring Cloud 全家桶中了，使用起來非常方便。
上圖可以看到Zuul的一個簡化結構，過濾器filter是整個Zuul的核心，分爲前置過濾器（pre filter）、路由過濾器（routing filter）、後置過濾器（post filter）以及 錯誤過濾器（error filter）。
一個請求過來，會先執行所有的 pre filter，然後再通過 routing filter 將請求轉發給後端服務，後端服務進行結果響應之後，再執行 post filter，最後再響應給客戶端。在不同的filter裏面可以執行不同的邏輯，比如安全檢查、日誌記錄等等。
Tyk
Tyk是一個基於GO編寫的，輕量級、快速可伸縮的開源的API網關。
可以通過下圖簡單瞭解一下Tyk的流程原理。
Kong
Kong是基於OpenResty技術棧的開源網關服務，因此其也是基於Nginx實現的。
Kong可以做到高性能、插件自定義、集羣以及易於使用的Restful API管理。
