使用微服務網(wǎng)關作為微服務面向客戶端的單一入口，是目前普遍采用的微服務架構(gòu)模式。企業(yè)組織通過良好定義的 API 將內(nèi)部系統(tǒng)向內(nèi)部和外部用戶公開，通常都會采用 API （微服務）網(wǎng)關來處理橫向的關注點，包括訪問控制、速率限制、負載均衡等等，來實現(xiàn)安全可控的 API 開放。廣泛實踐的微服務架構(gòu)中，似乎有很多產(chǎn)品具有這些能力，那如何更好的根據(jù)我們的業(yè)務場景選擇最合適自己的“大門”呢？

性能選擇-Nginx

---

Nginx 應該是 Web 應用的標配組件，使用場景包括負載均衡、反向代理、代理緩存等。Nginx 的內(nèi)核的設計非常微小和簡潔，實現(xiàn)的功能也相對簡單，僅僅通過查找配置文件與請求進行 URL 匹配，用于啟動不同的模塊去完成相應的工作。
Nginx 在啟動后，會有一個 Master 進程和多個 Worker 進程，Master 進程和 Worker 進程之間是通過進程間通信進行交互的。Worker 工作進程的阻塞點是在像 select()、epoll_wait() 等這樣的 I/O 多路復用函數(shù)調(diào)用處，以等待發(fā)生數(shù)據(jù)可讀 / 寫事件。Nginx 采用了異步非阻塞的方式來處理請求，是可以同時處理成千上萬個請求的。

服務親和-Zuul & Sping Cloud Gateway

---

Zuul 是 Netflix 開源的微服務網(wǎng)關組件，其可以配合 Eureka、Nacos 等開源產(chǎn)品實現(xiàn)不錯的服務發(fā)現(xiàn)能力，同時集成Ribbon、Hystrix 或 Sentinel 等組件實現(xiàn)對整個鏈路的流控。
Zuul 的核心是一系列的過濾器，這些過濾器許多功能，例如：
? 鑒權與訪問控制： 識別每次請求的合法性，并拒絕那些沒有在授權列表中的來源請求。
? 審計與監(jiān)控：記錄每次請求/響應的內(nèi)容，以及 RT/錯誤率等，從而分析出 API 的動態(tài)質(zhì)量、安全情況。
? 動態(tài)路由負載：動態(tài)地將請求路由分流到不同的服務、應用或者集群。
? 統(tǒng)一上下文：在請求轉(zhuǎn)發(fā)前根據(jù)業(yè)務需求設置公共的上下文信息向后傳遞。
? Mock 響應：針對簡單請求可以組合配置中心，直接在網(wǎng)關層直接響應，從而避免其轉(zhuǎn)發(fā)到內(nèi)部。
上面提及的這些特性是 Nginx 所沒有的，Netflix 公司研發(fā) Zuul 是為了解決微服務場景的諸多問題，而不僅僅是做一個類似于 nginx 的反向代理。
Spring Cloud Gateway 是 Spring Cloud 的一個全新項目，該項目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發(fā)的網(wǎng)關，它旨在為微服務架構(gòu)提供一種簡單有效的統(tǒng)一的 API 路由管理方式。
Spring Cloud Gateway 作為 Spring Cloud 生態(tài)系統(tǒng)中的網(wǎng)關，目標是替代 Zuul，在Spring Cloud 2.0 以上版本中，沒有對新版本的 Zuul 2.0 以上最新高性能版本進行集成，仍然還是使用的 Zuul 2.0 之前的非 Reactor 模式的老版本。而為了提升網(wǎng)關的性能，SpringCloud Gateway 是基于 WebFlux 框架實現(xiàn)的，而 WebFlux 框架底層則使用了高性能的 Reactor 模式通信框架 Netty。
Spring Cloud Gateway 的目標，不僅提供統(tǒng)一的路由方式，并且基于 Filter 鏈的方式提供了網(wǎng)關基本的功能，例如：安全，監(jiān)控/指標，和限流。

兩者兼得-Kong

---

Kong 是一款基于 Nginx_Lua 模塊寫的高可用服務網(wǎng)關，由于 Kong 是基于 Nginx 的，所以可以水平擴展多個 Kong 服務器。通過前置的負載均衡配置把請求均勻地分發(fā)到各個 Server，來應對大批量的網(wǎng)絡請求。
Kong 主要有三個組件：
? Kong Server：基于 nginx 的服務器，用來接收 API 請求。
? Apache Cassandra/PostgreSQL：用來存儲操作數(shù)據(jù)。
? Kong dashboard：官方推薦 UI 管理工具，當然，也可以使用 restfull 方式管理 admin api。
Kong 采用插件機制進行功能定制，插件集（可以是 0 或 N 個）在 API 請求響應循環(huán)的生命周期中被執(zhí)行。插件使用 Lua 編寫，基礎功能包括：HTTP 基本認證、密鑰認證、CORS（Cross-Origin Resource Sharing，跨域資源共享）、TCP、UDP、文件日志、API 請求限流、請求轉(zhuǎn)發(fā)以及 Nginx 監(jiān)控等。
Kong 網(wǎng)關具有以下的特性：
? 可擴展性：通過簡單地添加更多的服務器，可以輕松地進行橫向擴展，這相較于 nginx 能讓你省心不少，但可能相對于 Zuul 稍稍弱些；
? 模塊化：可以通過添加新的插件進行擴展，這些插件可以通過 RESTful Admin API 輕松配置；
? 在任何基礎架構(gòu)上運行：Kong 網(wǎng)關可以在任何地方都能運行，可以在云或內(nèi)部網(wǎng)絡環(huán)境中部署 Kong。

自建 OR 云產(chǎn)品

---

但是！有過使用經(jīng)驗的同學應該會發(fā)現(xiàn)，真正用起來我們還需要更多的服務發(fā)現(xiàn)能力、更全面的監(jiān)控可觀測能力、更高的穩(wěn)定性保障，那么到底是自己手工打造還是購買成本更合適呢？我們先來看下自建和云產(chǎn)品的比較：

自建 VS 托管云產(chǎn)品

能力	自建	托管
彈性擴縮容	需要自建維護K8s	產(chǎn)品控制臺直接操作
多種開發(fā)語言	Kong 使用 Lua 來擴展（可能還需要掌握 nginx ），Zuul 用 Java 實現(xiàn)	全都要，不用關注
服務發(fā)現(xiàn)	Kong 不支持，Zuul 支持部分需要開發(fā)	支持 Eureka、Nacos 等
監(jiān)控大盤	需要一個團隊支持，且要二次開發(fā)	控制臺一鍵創(chuàng)建
協(xié)議轉(zhuǎn)換	需要服務框架團隊開發(fā)	支持 Http、Dubbo 等
微服務治理	需要中間件團隊支持	集成 MSE 支持無損上下線、金絲雀發(fā)布、標簽路由、離群實例摘除等

對比可以看到，這些能力使用托管的 MSE 微服務網(wǎng)關就相當于省去了一個運維團隊、一個中間件團隊、一個多語言開發(fā)能力的研發(fā)團隊?，F(xiàn)在，您只要結(jié)合自己的業(yè)務場景選擇合適的引擎即可：

• 接入層場景選擇 Kong，性能高 SSL 安全能力匹配；

• 業(yè)務分支選擇 Zuul，自定義擴展方便還有很強的服務發(fā)現(xiàn)能力；

• 或者如果你是 Spring Cloud 技術體系，那么趕緊把 Spring Cloud Gateway 加入你的全家桶吧。
  

云產(chǎn)品的各引擎對比

更多內(nèi)容了解： https://www.aliyun.com/product/aliware/mse

總結(jié)

---

微服務網(wǎng)關作為微服務流量的“大門”，它的穩(wěn)定性、安全性、功能完備性上的要求是要遠遠高于我們業(yè)務自身的，我們往往需要投入非常大的人力和時間在他的運維和開發(fā)上，并還未必能保證有非常好的效果；BaaS 化的服務型（全托管）云產(chǎn)品，幫助我們的用戶堅持開源技術棧這一大方向不變的基礎上，更穩(wěn)定、更便捷、更專注的為我們業(yè)務保駕護航。