雲原生架構下的 API 網關實踐： Kong （一）

API 網關選型

業界有不少流行的 API 網關，開源的有 Nginx、Netflix Zuul、Kong 等。固然 Kong 還有商業版，相似的商業版網關還有 GoKu API Gateway 和 Tyk 等。

GoKu API Gateway 是由國內公司 eolinker 使用 Go 語言研發，擁有社區版和商業版，包含 API Gateway 和 Dashboard 兩部分。其中社區版本包含大量基礎功能，能夠知足中型企業和產品的使用；企業版本包含更多擴展；比較適合大型軟件和大型組織使用。

Tyk 由國外的 TykTechnologies 公司研發，也是基於 Go 語言。Tyk 一切均導向收費版本，免費版本第一次申請有一年的使用受權。

下面將會介紹經常使用的 API 網關組件 Nginx、Zuul 和 Kong 的相關特性。

Nginx

Nginx 能夠說是互聯網應用的標配組件，主要的使用場景包括負載均衡、反向代理、代理緩存、限流等。

Nginx 由內核和模塊組成，內核的設計很是微小和簡潔，完成的工做也很是簡單，僅僅經過查找配置文件與客戶端請求進行 URL 匹配，用於啓動不一樣的模塊去完成相應的工做。

Nginx 在啓動後，會有一個 Master 進程和多個 Worker 進程，Master 進程和 Worker 進程之間是經過進程間通訊進行交互的，如圖所示。Worker 工做進程的阻塞點是在像 select()、epoll_wait() 等這樣的 I/O 多路複用函數調用處，以等待發生數據可讀 / 寫事件。Nginx 採用了異步非阻塞的方式來處理請求，也就是說，Nginx 是能夠同時處理成千上萬個請求的。

還能夠將 Lua 嵌入到 Nginx 中，從而可使用 Lua 來編寫腳本，這樣就可使用 Lua 編寫應用腳本，部署到 Nginx 中運行，即 Nginx 變成了一個 Web 容器；這樣開發人員就可使用 Lua 語言開發高性能Web應用了。在開發的時候使用 OpenResty 來搭建開發環境，OpenResty 將 Nginx 核心、LuaJIT、許多有用的 Lua 庫和 Nginx 第三方模塊打包在一塊兒；這樣只須要安裝 OpenResty，不須要了解 Nginx 核心和寫複雜的 C/C++ 模塊就能夠，只須要使用 Lua 語言進行 Web 應用開發了。

使用 Nginx 的反向代理和負載均衡可實現負載均衡及高可用，除此以外還須要咱們解決自注冊和網關自己的擴展性。

Netflix Zuul

Zuul 是 Netflix 開源的微服務網關組件，它能夠和 Eureka、Ribbon、Hystrix 等組件配合使用。社區活躍，融合於 SpringCloud 完整生態，是構建微服務體系前置網關服務的最佳選型。Zuul 的核心是一系列的過濾器，這些過濾器能夠完成如下功能：

• 身份認證與安全：識別每一個資源的驗證要求，並拒絕那些與要求不符的請求。
• 審查與監控：與邊緣位置追蹤有意義的數據和統計結果，從而帶來精確的生產視圖。
• 動態路由：動態地將請求路由到不一樣的後端集羣。
• 壓力測試：逐漸增長指向集羣的流量，以瞭解性能。
• 負載分配：爲每一種負載類型分配對應容量，並棄用超出限定值的請求。
• 靜態響應處理：在邊緣位置直接創建部分響應，從而避免其轉發到內部集羣。
• 多區域彈性：跨越 AWS Region 進行請求路由，旨在實現 ELB（Elastic Load Balancing，彈性負載均衡）使用的多樣化，以及讓系統的邊緣更貼近系統的使用者。

上面說起的這些特性是 Nigix 所沒有的，Netflix 公司研發 Zuul 是爲了解決雲端的諸多問題（特別是幫助 AWS 解決跨 Region 狀況下的這些特性實現），而不只僅是作一個相似於 Nigix 的反向代理，固然，咱們能夠僅使用反向代理功能，這裏很少作描述。

Zuul 目前有兩個大的版本：Zuul1 和 Zuul2。

• Zuul1 是基於 Servlet 框架構建，如圖所示，採用的是阻塞和多線程方式，即一個線程處理一次鏈接請求，這種方式在內部延遲嚴重、設備故障較多狀況下會引發存活的鏈接增多和線程增長的狀況發生。
• Netflix 發佈的 Zuul2 有重大的更新，它運行在異步和無阻塞框架上，每一個 CPU 核一個線程，處理全部的請求和響應，請求和響應的生命週期是經過事件和回調來處理的，這種方式減小了線程數量，所以開銷較小。

Kong

Kong 是 Mashape 開源的高性能高可用 API 網關和 API 服務管理層，一款基於 Nginx_Lua 模塊寫的高可用服務網關，因爲 Kong 是基於 Nginx 的，因此能夠水平擴展多個 Kong 服務器。經過前置的負載均衡配置把請求均勻地分發到各個 Server，來應對大批量的網絡請求。

Kong 主要有三個組件：

• Kong Server ：基於nginx的服務器，用來接收 API 請求。
• Apache Cassandra/PostgreSQL：用來存儲操做數據。
• Kong dashboard：官方推薦 UI 管理工具，固然，也可使用 restfull 方式管理 admin api。

Kong 採用插件機制進行功能定製，插件集（能夠是 0 或 N 個）在 API 請求響應循環的生命週期中被執行。插件使用 Lua 編寫，基礎功能包括：HTTP 基本認證、密鑰認證、CORS（Cross-Origin Resource Sharing，跨域資源共享）、TCP、UDP、文件日誌、API 請求限流、請求轉發以及 Nginx 監控等。

Kong 網關具備如下的特性：

• 可擴展性: 經過簡單地添加更多的服務器，能夠輕鬆地進行橫向擴展，這意味着您的平臺能夠在一個較低負載的狀況下處理任何請求；
• 模塊化: 能夠經過添加新的插件進行擴展，這些插件能夠經過RESTful Admin API輕鬆配置；
• 在任何基礎架構上運行: Kong 網關能夠在任何地方都能運行。能夠在雲或內部網絡環境中部署 Kong，包括單個或多個數據中心設置，以及 public，private 或 invite-only APIs。

動態負載均衡、基於散列的負載均衡、斷路器、健康檢查、Websockets、OAuth2.0、日誌記錄、安全性、Syslog、監控、轉發代理、認證、速率限制、故障檢測和恢復

小結

筆者在上面小節簡要介紹了 Nginx、Zuul 和 Kong 這三種 API 網關組件的功能和特性，並製做了以下的對比表格：

組件/指標	Nginx	Zuul（1.x）	Kong 社區版
API 註冊/動態路由	在Nginx中配置	動態路由	經過 Admin API 管理
支持協議	RESTful API	RESTful API	RESTful API
插件機制	Lua 插件機制	能夠基於源碼定製開發，基於 Servlet/Filter	Lua 插件機制
安全認證 & 鑑權	插件支持	支持 OAuth、JWT 等	支持OAuth2.0、黑白名單、ACL、JWT、SSL 等
限流	插件	插件	支持Rate Limiting
高可用集羣	配合硬件負載均衡	能夠經過部署多個 Zuul 作負載均衡	支持集羣
可管理性	無	沒有 GUI 管理臺	提供 Rest API 交互
性能	高	通常	高
日誌記錄	Nginx 可靈活記日誌	可自行配置	日誌能夠記錄到磁盤，或者HTTP、TCP、UDP發出去

總得來講，Zuul 複雜度較低，上手簡單，能夠自定義開發，可是高併發場景下的性能相對較差；Nginx 性能經受得住考驗，配合 Lua 能夠引入各類插件，可是功能性相對較弱，須要開發者自身去完善不少功能；Kong 基於 Nginx、OpenResty 和 Lua，對性能要求高，須要對外開放，建議考慮使用 Kong。下面咱們將重點介紹。

更多內容，歡迎訂閱。