微服務閘道器被作為微服務面向客戶端的單一入口，用來處理橫向的關注點，包括訪問控制、速率限制、負載均衡等等。真正用起來時，我們還需要關注更多的縱向因素，例如服務發現能力、更全面的監控可觀測能力、更高的穩定性保障等。

近日，阿里雲微服務引擎MSE重磅釋出閘道器功能，將在閘道器的穩定性、安全性、功能完備性上提供更多增值價值，開啟微服務“大門”的雲化時代。

一、微服務“大門”有哪些選擇？

1、效能選擇-Nginx

Nginx 應該是 Web 應用的標配元件，使用場景包括負載均衡、反向代理、代理快取等。Nginx 的核心的設計非常微小和簡潔，實現的功能也相對簡單，僅僅透過查詢配置檔案與請求進行 URL 匹配，用於啟動不同的模組去完成相應的工作。

Nginx 在啟動後，會有一個 Master 程式和多個 Worker 程式，Master 程式和 Worker 程式之間是透過程式間通訊進行互動的。Worker 工作程式的阻塞點是在像 select()、epoll_wait() 等這樣的 I/O 多路複用函式呼叫處，以等待發生資料可讀 / 寫事件。Nginx 採用了非同步非阻塞的方式來處理請求，是可以同時處理成千上萬個請求的。

2、服務親和-Zuul & Sping Cloud Gateway

Zuul 是 Netflix 開源的微服務閘道器元件，其可以配合 Eureka、Nacos 等開源產品實現不錯的服務發現能力，同時整合Ribbon、Hystrix 或 Sentinel 等元件實現對整個鏈路的流控。

Zuul 的核心是一系列的過濾器，這些過濾器許多功能，例如：

鑑權與訪問控制：識別每次請求的合法性，並拒絕那些沒有在授權列表中的來源請求。

審計與監控：記錄每次請求/響應的內容，以及 RT/錯誤率等，從而分析出 API 的動態質量、安全情況。

動態路由負載：動態地將請求路由分流到不同的服務、應用或者叢集。

統一上下文：在請求轉發前根據業務需求設定公共的上下文資訊向後傳遞。

Mock 響應：針對簡單請求可以組合配置中心，直接在閘道器層直接響應，從而避免其轉發到內部。

上面提及的這些特性是 Nginx 所沒有的，Netflix 公司研發 Zuul 是為了解決微服務場景的諸多問題，而不僅僅是做一個類似於 nginx 的反向代理。

Spring Cloud Gateway 是 Spring Cloud 的一個全新專案，該專案是基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的閘道器，它旨在為微服務架構提供一種簡單有效的統一的 API 路由管理方式。

Spring Cloud Gateway 作為 Spring Cloud 生態系統中的閘道器，目標是替代 Zuul，在Spring Cloud 2.0 以上版本中，沒有對新版本的 Zuul 2.0 以上最新高效能版本進行整合，仍然還是使用的 Zuul 2.0 之前的非 Reactor 模式的老版本。而為了提升閘道器的效能，SpringCloud Gateway 是基於 WebFlux 框架實現的，而 WebFlux 框架底層則使用了高效能的 Reactor 模式通訊框架 Netty。

Spring Cloud Gateway 的目標，不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了閘道器基本的功能，例如：安全，監控/指標，和限流。

3、兩者兼得-Kong

Kong 是一款基於 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 閘道器具有以下的特性：

可擴充套件性：透過簡單地新增更多的伺服器，可以輕鬆地進行橫向擴充套件，這相較於 nginx 能讓你省心不少，但可能相對於 Zuul 稍稍弱些；

模組化：可以透過新增新的外掛進行擴充套件，這些外掛可以透過 RESTful Admin API 輕鬆配置；

在任何基礎架構上執行：Kong 閘道器可以在任何地方都能執行，可以在雲或內部網路環境中部署 Kong。

二、自建 OR 雲產品

但是！有過使用經驗的同學應該會發現，真正用起來我們還需要更多的服務發現能力、更全面的監控可觀測能力、更高的穩定性保障，那麼到底是自己手工打造還是購買成本更合適呢？我們先來看下自建和雲產品的比較：

1、自建 VS 託管雲產品

對比可以看到，這些能力使用託管的 MSE 微服務閘道器就相當於省去了一個運維團隊、一箇中介軟體團隊、一個多語言開發能力的研發團隊。現在，您只要結合自己的業務場景選擇合適的引擎即可：

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

業務分支選擇 Zuul，自定義擴充套件方便還有很強的服務發現能力；

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

2、雲產品的各引擎對比

三、總結

微服務閘道器作為微服務流量的“大門”，它的穩定性、安全性、功能完備性上的要求是要遠遠高於我們業務自身的，我們往往需要投入非常大的人力和時間在他的運維和開發上，並還未必能保證有非常好的效果；BaaS 化的服務型（全託管）雲產品，幫助我們的使用者堅持開源技術棧這一大方向不變的基礎上，更穩定、更便捷、更專注的為我們業務保駕護航。