點選“博雲技術社群”，擷取最新技術分享
微服務架構是當下比較流行的一種架構風格，它是一種以業務功能組織的服務集合，可以持續傳遞、快速部署、更好的可擴充性和容錯能力，而且還使組織更容易去嘗試新技術棧。微服務具有幾個關鍵特征：
- 高度可維護和可測試性
- 與其他服務松散耦合
- 且可獨立部署
- 能夠由一個小團隊開發
現在很多公司企業想将自己的單體應用架構遷移到微服務架構，在這個問題上，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
相關推薦
- Istio 1.1安裝部署實踐
- 全方位解讀 | Istio v1.1正式釋出
- 深度解析Istio系列之安全子產品篇
- 深度解析Istio系列之流量控制篇
- 深度解析Istio系列之政策與遙測篇
- 深度解析Istio系列之Istio-proxy初始化
加入技術交流群
添加管理者微信ID : ruffylining
備注姓名-公司-職位，即可入群
歡迎留言交流~