微服務五種開源API網關實現組件對比

日期:

2019-04-25

瀏覽次數:

0

作者:佚名? ?來源:DockOne

微服務架構是當下比較流行的一種架構風格,它是一種以業務功能組織的服務集合,可以持續交付、快速部署、更好的可擴展性和容錯能力,而且還使組織更容易去嘗試新技術棧。微服務具有幾個關鍵特征:

  • 高度可維護和可測試性

  • 與其他服務松散耦合

  • 且可獨立部署

  • 能夠由一個小團隊開發

現在很多公司企業想將自己的單體應用架構遷移到微服務架構,在這個問題上,Martin Fowler提出了3個前提,而Phil Calcado對其進行了擴展如下:

  • 快速配置計算資源

  • 基本監控

  • 快速部署

  • 易于配置存儲

  • 易于訪問網關

  • 認證、授權

  • 標準化的 RPC

今天我們主要講講易于訪問的網關,也就是 API 網關。

為什么需要 API 網關

假設我們要使用微服務架構構建一個電商平臺,以下可能是一些潛在的服務:

  • 購物車服務

  • 訂單服務

  • 商品服務

  • 評論服務

  • 庫存服務

等等,客戶端應該怎么訪問這些服務呢?原來單體應用的情況我們都知道,都在一個服務器上部署,直接訪問IP+端口+服務前綴即可,現在微服務架構下,每個服務都可以獨立部署,并且是由不同的開發團隊開發的,難道我們要這樣訪問嗎?

微服務五種開源API網關實現組件對比

理論上每個服務都有端點可以訪問,但是客戶端就需要記錄所有服務的端點,發起5次請求,現在還是5個服務,如果之后擴展多了呢?對客戶端來說就是一個災難,隨之帶來的就是安全性問題、擴展性問題等,所以這種客戶端直接與每個服務交互是不可取的,通常,更好的方式是使用 API 網關。

API 網關是客戶端訪問服務的統一入口,API 網關封裝了后端服務,還提供了一些更高級的功能,例如:身份驗證、監控、負載均衡、緩存、多協議支持、限流、熔斷等等,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 路由和服務端的負載均衡器。

API 網關實現對比

微服務五種開源API網關實現組件對比




微服務五種開源API網關實現組件對比

微服務五種開源API網關實現組件對比


總結

由上述對比表格中可以看出:從開源社區活躍度來看,無疑是Kong和Traefik較好;從成熟度來看,較好的是Kong、Tyk、Traefik;從性能角度來看,Kong要比其他幾個領先一些;從架構優勢的擴展性來看,Kong、Tyk有豐富的插件,Ambassador也有插件但不多,而Zuul是完全需要自研,但Zuul由于與Spring Cloud深度集成,使用度也很高,近年來Istio服務網格的流行,Ambassador因為能夠和Istio無縫集成也是相當大的優勢。

具體使用選擇還是需要依據具體的業務場景,我們在參考鏈接中收集了一些性能對比,大家可以做下參考。

聲明:本網站發布的內容(圖片、視頻和文字)以原創、轉載和分享網絡內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服,電話:0755-22671324。


相關新聞

Web服務器、應用服務器、Web容器、反向代理服務器
作者:程序君來源:Web編程開發我們知道,不同膚色的人外貌差別很大,而雙胞胎的辨...
FTP服務器和Web服務器知多少
作者:yy來源:科技嘞服務器,也稱伺服器,是提供計算服務的設備。由于服務器需要響...