微服務架構是當下比較流行的一種架構風格，它是一種以業務功能組織的服務集合，可以持續交付、快速部署、更好的可擴展性和容錯能力，而且還使組織更容易去嘗試新技術棧。微服務具有幾個關鍵特征：
現在很多公司企業想將自己的單體應用架構遷移到微服務架構，在這個問題上，Martin Fowler提出了3個前提，而Phil Calcado對其進行了擴展如下：
今天我們主要講講易于訪問的網關，也就是 API 網關。
假設我們要使用微服務架構構建一個電商平臺，以下可能是一些潛在的服務：
等等，客戶端應該怎么訪問這些服務呢？原來單體應用的情況我們都知道，都在一個服務器上部署，直接訪問IP+端口+服務前綴即可，現在微服務架構下，每個服務都可以獨立部署，并且是由不同的開發團隊開發的，難道我們要這樣訪問嗎？
理論上每個服務都有端點可以訪問，但是客戶端就需要記錄所有服務的端點，發起5次請求，現在還是5個服務，如果之后擴展多了呢？對客戶端來說就是一個災難，隨之帶來的就是安全性問題、擴展性問題等，所以這種客戶端直接與每個服務交互是不可取的，通常，更好的方式是使用 API 網關。
API 網關是客戶端訪問服務的統一入口，API 網關封裝了后端服務，還提供了一些更高級的功能，例如：身份驗證、監控、負載均衡、緩存、多協議支持、限流、熔斷等等，API 網關還可以針對不同的客戶端定制不同粒度的 API，上面例子中修改架構后如下：
API 網關的好處是顯而易見的，封裝了應用程序的內部結構，為不同客戶端提供不同粒度的 API，同時網關自身也提供了一些高級功能，也減少了客戶端與應用程序之間的往返次數，使客戶端代碼更優雅。
同時使用網關也存在一些缺點，增加了一個新的組件，增加了整個應用架構的復雜度，一個通俗的道理，你做的越多你犯錯的風險也越高，網關不可用很可能導致整個應用架構崩潰，當然現在有各種各樣的方案，能防止網關崩潰，它也可能存在瓶頸風險。
使用網關有利有弊，我個人而言，利肯定是大于弊的，我們盡可能的將弊端降到最低。
使用一個組件時，尤其是這種比較流行的架構，組件肯定存在開源的，我們不必自己去從零開始去實現一個網關，自己開發一個網關的工作量是相當可觀的，現在比較流行的開源 API 網關如下所示：
Kong
Kong是一個在 Nginx 中運行的Lua應用程序，并且可以通過lua-nginx模塊實現，Kong不是用這個模塊編譯Nginx，而是與 OpenResty 一起發布，OpenResty已經包含了 lua-nginx-module， OpenResty 不是 Nginx 的分支，而是一組擴展其功能的模塊。
它的核心是實現數據庫抽象，路由和插件管理，插件可以存在于單獨的代碼庫中，并且可以在幾行代碼中注入到請求生命周期的任何位置。
Traefik
Traefik 是一個現代 HTTP 反向代理和負載均衡器，可以輕松部署微服務，Traeffik 可以與您現有的組件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，并自動動態配置。
Ambassador
Ambassador 是一個開源的微服務 API 網關，建立在 Envoy 代理之上，為用戶的多個團隊快速發布，監控和更新提供支持，支持處理 Kubernetes ingress controller 和負載均衡等功能，可以與 Istio 無縫集成。
Tyk
Tyk是一個開源的、輕量級的、快速可伸縮的 API 網關，支持配額和速度限制，支持認證和數據分析，支持多用戶多組織，提供全 RESTful API?；?go 編寫。
Zuul
Zuul 是一種提供動態路由、監視、彈性、安全性等功能的邊緣服務。Zuul 是 Netflix 出品的一個基于 JVM 路由和服務端的負載均衡器。
由上述對比表格中可以看出：從開源社區活躍度來看，無疑是Kong和Traefik較好；從成熟度來看，較好的是Kong、Tyk、Traefik；從性能角度來看，Kong要比其他幾個領先一些；從架構優勢的擴展性來看，Kong、Tyk有豐富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于與Spring Cloud深度集成，使用度也很高，近年來Istio服務網格的流行，Ambassador因為能夠和Istio無縫集成也是相當大的優勢。
具體使用選擇還是需要依據具體的業務場景，我們在參考鏈接中收集了一些性能對比，大家可以做下參考。
參考鏈接
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
