微服務五種開源API網關實作元件對比

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

• 高度可維護和可測試性
• 與其他服務松散耦合
• 且可獨立部署
• 能夠由一個小團隊開發

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

• 快速配置計算資源
• 基本監控
• 快速部署
• 易于配置存儲
• 易于通路網關
• 認證、授權
• 标準化的 RPC

今天我們主要講講易于通路的網關，也就是 API 網關。

為什麼需要 API 網關

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

• 購物車服務
• 訂單服務
• 商品服務
• 評論服務
• 庫存服務

等等，用戶端應該怎麼通路這些服務呢？原來單體應用的情況我們都知道，都在一個伺服器上部署，直接通路IP+端口+服務字首即可，現在微服務架構下，每個服務都可以獨立部署，并且是由不同的開發團隊開發的，難道我們要這樣通路嗎？

理論上每個服務都有端點可以通路，但是用戶端就需要記錄所有服務的端點，發起5次請求，現在還是5個服務，如果之後擴充多了呢？對用戶端來說就是一個災難，随之帶來的就是安全性問題、擴充性問題等，是以這種用戶端直接與每個服務互動是不可取的，通常，更好的方式是使用 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 網關實作對比

Kong	Traefik	Ambassador	Tyk	Zuul
基本
主要用途	企業級API管理	微服務網關	微服務網關	微服務網關	微服務網關
學習曲線	适中	simple	simple	适中	simple
成本	開源/企業版	開源	開源/pro	開源/企業版	開源
社群star	20742	21194	1719	4299	7186
配置
配置語言	Admin Rest api, Text file(nginx.conf 等)	TOML	YAML(kubernetes annotation)	Tyk REST API	REST API，YAML靜态配置
配置端點類型	指令式	聲明式	聲明式	指令式	指令式
拖拽配置	yes	no	no	no	no
管理模式	configurable	decentralised, self-service	decentralised, self-service	decentralised, self-service	decentralised, self-service
部署
kubernetes	适中(k8s yaml,helm chart)	easy	easy	适中(k8s yaml,helm chart)	适中(k8s yaml,helm chart)
Cloud IAAS	high	easy	N/A	easy	easy
Private Data Center	high	easy	N/A	easy	easy
部署模式	金絲雀(企業版)	金絲雀	金絲雀，shadow	金絲雀	金絲雀
state	postgres,cassandra	kubernetes	kubernetes	redis	記憶體檔案
可擴充性
擴充功能	插件	自己實作	插件	插件	自己實作
擴充方法	水準	水準	水準	水準	水準
功能
服務發現	動态	動态	動态	動态	動态
協定	http,https,websocket	http,https,grpc,websocket	http,https,grpc,websocket	http,https,grpc,websocket	http,https
基于	kong+nginx	traefik	envoy	tyk	zuul
ssl 終止	yes	yes	yes	yes	no
websocket	yes	yes	yes	yes	no
routing	host,path,method	host,path	host,path,header	host,path
限流	yes	no	yes	yes	需要開發
熔斷	yes	yes	no	yes	需要其他元件
重試	yes	yes	no	yes	yes
健康檢查	yes	no	no	yes	yes
負載均衡算法	輪詢，哈希	輪詢，權重輪詢	權重輪詢	輪詢	輪詢，随機，權重輪詢，自定義
權限	Basic Auth, HMAC, JWT, Key, LDAP, OAuth 2.0, PASETO, plus paid Kong Enterprise options like OpenID Connect	basic	yes	HMAC，JWT，Mutual TLS，OpenID Connect，基本身份驗證，LDAP，社交OAuth（例如GPlus，Twitter，Github）和傳統基本身份驗證提供程式	開發實作
tracing	yes	yes	yes	yes	需要其他元件
istio內建	no	no	yes	no	no
dashboard	yes	yes	grafana,Prometheus	yes	no

總結

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

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

參考連結

• https://www.bbva.com/en/api-gateways-kong-vs-tyk/ kong vs tyk
• https://stackshare.io/stackups/kong-vs-traefik kong vs traefik
• https://blog.getambassador.io/envoy-vs-nginx-vs-haproxy-why-the-open-source-ambassador-api-gateway-chose-envoy-23826aed79ef envoy vs nginx
• https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369 nginx vs zuul