現在在新的公司基礎服務組（中臺）待了快一年了，主要折騰公司的網關平臺生態，我們公司網關平臺是基於SpringCloud Gateway爲基礎構建的，屬於從零到一構建整個網關平臺的生態，目前核心服務基本完成，後期新的需求，POC和MVP都在路上，同時也覺的有必要看一看業界開源網關產品(排除幾大共有云廠商的網關服務)，這也是寫這篇博客的出發點。
主要分析對比下：Nginx，Zuul2，Spring Cloud Gateway, Kong, APISIX
1. Nginx
Nginx由內核和模塊組成，內核的設計非常微小和簡潔，完成的工作也非常簡單，僅僅通過查找配置文件與客戶端請求進行 URL 匹配，用於啓動不同的模塊去完成相應的工作。 Nginx架構大概如下圖
Nginx 的模塊直接被編譯進 Nginx，因此屬於靜態編譯方式。啓動 Nginx 後，Nginx 的模塊被自動加載，不像 Apache，首先將模塊編譯爲一個 so 文件，然後在配置文件中指定是否進行加載。在解析配置文件時，Nginx 的每個模塊都有可能去處理某個請求，但是同一個處理請求只能由一個模塊來完成。
Nginx 在啓動後，會有一個 Master 進程和多個 Worker 進程，Master 進程和 Worker 進程之間是通過進程間通信進行交互的，如圖所示。Worker 工作進程的阻塞點是在像 select()、epoll_wait() 等這樣的 I/O 多路複用函數調用處，以等待發生數據可讀 / 寫事件。Nginx 採用了異步非阻塞的方式來處理請求，也就是說，Nginx 是可以同時處理成千上萬個請求的。一個 Worker 進程可以同時處理的請求數只受限於內存大小，而且在架構設計上，不同的 Worker 進程之間處理併發請求時幾乎沒有同步鎖的限制，Worker 進程通常不會進入睡眠狀態，因此，當 Nginx 上的進程數與 CPU 核心數相等時（最好每一個 Worker 進程都綁定特定的 CPU 核心），進程間切換的代價是最小的。
nginx優缺點
Nginx優點： 1、工作在網絡7層之上，可針對http應用做一些分流的策略，如針對域名、目錄結構，它的正規規則比HAProxy更爲強大和靈活，所以，目前爲止廣泛流行。 2、Nginx對網絡穩定性的依賴非常小，理論上能ping通就能進行負載功能。 3、Nginx安裝與配置比較簡單，測試也比較方便，基本能把錯誤日誌打印出來。 4、可以承擔高負載壓力且穩定，硬件不差的情況下一般能支撐幾萬次的併發量，負載度比LVS小。 5、Nginx可以通過端口檢測到服務器內部的故障，如根據服務器處理網頁返回的狀態碼、超時等，並會把返回錯誤的請求重新提交到另一個節點。 6、不僅僅是優秀的負載均衡器/反向代理軟件，同時也是強大的Web應用服務器。LNMP也是近些年非常流行的Web架構，在高流量環境中穩定性也很好。 7、可作爲中層反向代理使用。 8、可作爲靜態網頁和圖片服務器。 9、Nginx社區活躍，第三方模塊非常多，相關的資料在網上比比皆是。 Nginx缺點： 1、適應範圍較小，僅能支持http、https、Email協議。 2、對後端服務器的健康檢查，只支持通過端口檢測，不支持url來檢測。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，
Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而不滿。
Nginx應用場景: HTTP服務器, 靜態服務器,反向代理, 負載均衡, 動靜分離
2. Zuul2
網址:https://github.com/Netflix/zuul
Zuul是Netflix開源的微服務網關組件，它可以和Eureka、Ribbon、Hystrix等組件配合使用。Zuul的核心是一系列的過濾器，這些過濾器可以完成以下功能：
身份認證與安全：識別每個資源的驗證要求，並拒絕那些與要求不符的請求。
審查與監控：與邊緣位置追蹤有意義的數據和統計結果，從而帶來精確的生產視圖。
動態路由：動態地將請求路由到不同的後端集羣。
壓力測試：逐漸增加指向集羣的流量，以瞭解性能。
負載分配：爲每一種負載類型分配對應容量，並棄用超出限定值的請求。
靜態響應處理：在邊緣位置直接建立部分響應，從而避免其轉發到內部集羣。
多區域彈性：跨越 AWS Region 進行請求路由，旨在實現 ELB（Elastic Load Balancing，彈性負載均衡）使用的多樣化，以及讓系統的邊緣更貼近系統的使用者。
Zuul1是基於Servlet 框架構建，採用的是阻塞和多線程方式，即一個線程處理一次連接請求，這種方式在內部延遲嚴重、設備故障較多情況下會引起存活的連接增多和線程增加的情況發生。
正式基於此，Netflix公司積極推出了2.0版本。Zuul2.x 最大的改進就是基於Netty Server 實現了異步IO來接入請求，同時基於Netty Client 實現了到後端業務服務API的請求。這樣就可以實現更高的性能、更低的延遲。此外也調整了filter類型，將原來的三個核心filter 顯式命名爲：Inbound Filter、Endpoint Filter 和 Outbound Filter。
Zuul2的核心功能：Service Discovery，Load Balancing，Connection Pooling。Status Categories，Retries，Request Passport，Request Attempts，Origin Concurrency Protection，HTTP/2，Mutual TLS，Proxy Protocol，GZip，WebSockets
Zuul2的應用場景：io密集的任務，大請求或者大文件，隊列的流式數據，超大量的連接
3. Spring Cloud Gateway
網址：https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/
Spring Cloud Gateway 基於 Java 8、Spring 5.0、Spring Boot 2.0、Project Reactor，發展的比 Zuul 2 要早，目前也是 Spring Cloud 全家桶的一部分。SpringCloud Gateway 作爲 Spring Cloud 生態系統中的網關，目標是替代 Zuul，在Spring Cloud 2.0以上版本中，沒有對新版本的Zuul 2.0以上最新高性能版本進行集成。而爲了提升網關的性能，SpringCloud Gateway是基於WebFlux框架實現的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。Spring Cloud Gateway 的目標，不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/指標，和限流。
SpringCloud官方，對SpringCloud Gateway 特徵介紹如下：
（1）基於 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
（2）集成 Hystrix 斷路器
（3）集成 Spring Cloud DiscoveryClient
（4）Predicates 和 Filters 作用於特定路由，易於編寫的 Predicates 和 Filters
（5）具備一些網關的高級功能：動態路由、限流、路徑重寫
Spring Cloud Gateway應用場景：反向代理, 鑑權，流量控制，熔斷, 日誌監控, 編輯請求頭和請求體, 編輯響應體的參數, 黑白名單, 路徑重寫
接下來要介紹的兩個網關平臺是近幾年比較火的網關平臺
4. Kong
Kong 的基本架構
Kong基於Nginx來實現Api Gateway基本的負載均衡、反向代理等功能。由C語言編寫的Nginx有着超高的性能和低內存開銷
OpenResty是一個基於Nginx的庫，它將Nginx進行封裝，並提供了整個生命週期的Hook（ 鉤子 ），使得開發者可以通過Lua腳本對Nginx進行插件化管理
Kong使用PostgreSQL或Cassandra來對其配置文件進行持久化存儲，使得可以進行集羣管理
Kong提供了插件模型，使用Lua腳本來對Nginx整個生命週期進行擴展。實現了一些常用插件（ 限流、熔斷、驗權等 ）
Kong的特點
Cloud-Native：與平臺無關，Kong可以在任何平臺上運行-從裸機到容器-並且可以在本機上的每個雲上運行。 Kubernetes-Native：使用官方的Ingress Controller通過本地Kubernetes CRD聲明性地配置Kong，以路由和連接所有L4 + L7通信。 動態負載平衡：跨多個上游服務對流量進行負載平衡。 基於哈希的負載平衡：具有一致的哈希/粘性會話的負載平衡。 熔斷器：智能跟蹤不健康的上游服務。 運行狀況檢查：主動和被動監視您的上游服務。 服務發現：在第三方DNS解析器（例如Consul）中解析SRV記錄。 無服務器：直接從Kong調用和保護AWS Lambda或OpenWhisk功能。 WebSockets：通過WebSockets與您的上游服務進行通信。 gRPC：與gRPC服務進行通信，並通過日誌記錄和可觀察性插件觀察流量 OAuth2.0：輕鬆將OAuth2.0身份驗證添加到您的API。 日誌記錄：通過HTTP，TCP，UDP或磁盤記錄對系統的請求和響應。 安全性：ACL，殭屍程序檢測，允許/拒絕IP等… Syslog：登錄到系統日誌。 SSL：爲基礎服務或API設置特定的SSL證書。 監視：實時監視提供關鍵的負載和性能服務器指標。 轉發代理：使Kong連接到中間透明HTTP代理。 認證：HMAC，JWT，基本等。 速率限制：基於許多變量來阻止和限制請求。 轉換：添加，刪除或處理HTTP請求和響應。 緩存：在代理層緩存並提供響應。 CLI：從命令行控制Kong羣集。 REST API：Kong可以使用其RESTful API進行操作，以實現最大的靈活性。 地理複製：跨不同區域的配置始終是最新的。 故障檢測和恢復：如果您的Cassandra節點之一發生故障，則Kong不會受到影響。 集羣：所有Kong節點自動加入集羣，並在各個節點之間更新其配置。 可擴展性：Kon本質上是分佈式的，只需添加節點即可水平擴展。 性能：Kong通過擴展和使用NGINX作爲核心輕鬆處理負載。 插件：可擴展的體系結構，用於向Kong和API添加功能。
5. APISIX
APISIX 是一個雲原生、高性能、可擴展的微服務 API 開源網關，基於OpenResty(Nginx+Lua)和etcd來實現，對比傳統的API網關，具有動態路由和熱插件加載的特點。系統本身自帶前端，可以手動配置路由、負載均衡、限速限流、熔斷、金絲雀發佈、身份驗證、可監控等插件，操作方便。可以使用Apache APISIX來處理傳統的南北流量，以及服務之間的東西流量。它也可以用作k8s入口控制器。
您可以將Apache APISIX用作處理所有業務數據的流量入口，包括動態路由，動態上游，動態證書，A / B測試，金絲雀發佈，藍綠色部署，限制速率，防禦惡意攻擊，指標，監視警報，服務可觀察性，服務治理等。
支持所有平臺
原生雲：與平臺無關，無供應商鎖定，APISIX可以從裸機運行到Kubernetes。
運行環境：同時支持OpenResty和Tengine。
支持ARM64：不用擔心基礎技術的鎖定。
多協議
TCP / UDP代理：動態TCP / UDP代理。 動態MQTT代理：支持按client_id負載均衡，同時支持MQTT 3.1.*，5.0。 gRPC代理：代理gRPC通信。 gRPC轉碼：支持協議轉碼，以便客戶端可以使用HTTP / JSON訪問您的gRPC API。 代理Websocket代理協議代理Dubbo：基於Tengine的Dubbo代理。 HTTP(S)轉發代理。 SSL：動態加載SSL證書。
全動態
熱更新和熱插件：不斷更新其配置和插件，而無需重新啓動
代理重寫：在發送到上游之前，支持重寫主機，uri，架構，enable_websocket，請求標頭。
響應重寫：爲客戶端設置自定義的響應狀態代碼，正文和標頭。
無服務：在APISIX的每個階段調用功能。
動態負載均衡：循環負載均衡。
基於哈希的負載均衡：具有一致的哈希會話的負載均衡。
健康檢查：在上游節點上啓用健康檢查，並在負載均衡期間自動過濾不正常的節點，以確保系統穩定性。
熔斷器：智能跟蹤不健康的上游服務。
代理鏡像：提供鏡像客戶端請求的功能。
細粒度路由
支持全路徑匹配和前綴匹配。 支持所有Nginx內置變量作爲路由條件，因此您可以使用cookie，args等作爲路由條件來實現金絲雀發佈，A / B測試等。 支持各種運算符作爲判斷條件用於路由，例如{“ arg_age”，“>”，24} 支持自定義路由匹配功能 IPv6：使用IPv6來匹配路由。 支持TTL 支持優先級 支持批量Http請求
安全認證
身份驗證：密鑰身份驗證，JWT，基本身份驗證，wolf-rbac IP白名單/黑名單 引用白名單/黑名單 IdP：支持外部身份驗證服務，例如Auth0，okta等，用戶可以使用它來連接到OAuth 2.0和其他身份驗證方式。 Limit-req ： 請求限流（基於漏桶算法） Limit-count ： 連接數限流 Limit-conn : 併發限流 Anti-ReDoS（正則表達式拒絕服務）：Anti ReDoS的內置策略，無需配置。 CORS爲您的API啓用CORS（跨域資源共享）。 URI阻斷：按URI阻止客戶端請求。 請求驗證
友好便捷運維
OpenTracing：支持Apache Skywalking和Zipkin 結合第三方服務發現的組件一起使用：除了內置的etcd外，它還支持Consul和Nacos DNS發現模式，以及Eureka 監控和統計：Prometheus 集羣：APISIX節點是無狀態的，創建了配置中心，請參閱etcd集羣指南。 高可用：支持在同一集羣中配置多個etcd地址。 控制檯：內置控制檯可在控制檯上操作APISIX。 版本控制：支持操作回滾。 CLI：通過命令行啓動\停止\重新加載APISIX。 獨立模式：支持從本地yaml文件加載路由規則。在kubernetes（k8s）下，更加友好。 全局規則：允許針對所有請求運行任何插件，例如：限流插件，IP黑白名單等。 高性能：單核QPS達到18k，平均延遲小於0.2毫秒。 故障注入 REST Admin API：使用REST Admin API控制Apache APISIX（默認情況下僅允許127.0.0.1訪問），您可以修改conf / config.yaml中的allow_admin字段以指定允許調用IP的IP列表。
管理員API。另請注意，Admin API使用密鑰身份驗證來驗證調用方的身份。部署前需要修改conf / config.yaml中的admin_key字段，以確保安全。 支持日誌導出：將訪問日誌導出到外部日誌管理工具。 （HTTP記錄器，TCP記錄器，Kafka記錄器，UDP記錄器）
高度可擴展
自定義插件：允許hook在公共階段，例如rewrite, access, header filer, body filter and log階段等，還允許hooK在balancer階段。
自定義負載均衡算法：可以在balancer階段使用自定義負載均衡算法。
自定義路由：支持用戶自己實現路由算法。