微服務架構學習與思考(11)：開源 API 閘道器02-以 Java 為基礎的 API 閘道器詳細介紹

上一篇關於閘道器的文章：

微服務架構學習與思考(10)：微服務閘道器和開源 API 閘道器01-以 Nginx 為基礎的 API 閘道器詳細介紹，介紹了為什麼會有閘道器及以 Nginx 為基礎的閘道器。

一、閘道器 zuul

zuul 閘道器使用 java 語言開發，是 Netflix 公司出品的開源閘道器。它是 SpringCloud 的元件之一。zuul 有 2 個大的版本：

zuul1：zuul1 wiki
zuul2：zuul2 wiki

1.1 zuul1 架構

zuul1 是基於 Servlet 構建的，採用的是阻塞和多執行緒方式，它一個執行緒處理一次連線。I/O 操作是通過從執行緒池中選擇一個工作執行緒執行 I/O 來完成的，並且請求執行緒將阻塞，直到工作執行緒完成為止。工作執行緒在其工作完成時通知請求執行緒。如下圖：

(netflix blog: https://netflixtechblog.com/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c)

這種處理執行緒模型，當後端API延遲增加或錯誤導致重試，執行緒數也會隨之增加。這種情況發生時，就會給節點伺服器帶來麻煩，使伺服器負載激增，為了消除這種麻煩，構建了限流機制（比如hystrix）保持系統的穩定。

zuul1 中閘道器功能怎麼實現，在請求週期通過 Filter 實現，如下圖：

（from：https://github.com/Netflix/zuul/wiki/How-it-Works）

1.2 zuul2 架構

zuul2 對 zuul1 進行了重大的重構，採用非同步和事件驅動模式處理程式。請求和響應的生命週期通過事件和回撥機制來處理。沒有像 zuul1 那樣針對每個請求使用一個執行緒，不需要大量的執行緒成本，只需要一個檔案描述符和一個監聽器。而且像 zuul1 發生後端延遲和「重試風暴」，不是增加執行緒，zuul2 中是在佇列中增加事件，這個開銷比多個執行緒開銷小得多。

(netflix blog: https://netflixtechblog.com/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c)

關於高效能網路IO程式設計模型，可以看我之前的文章，點選這裡看文章

zuul2 閘道器中那麼多功能是怎麼實現的呢？是在請求週期（request cycle）中，通過 Filter 來處理實現。

（from：https://github.com/Netflix/zuul/wiki/How-It-Works-2.0）

Filter：

Filter 過濾器是 zuul2 業務邏輯處理的核心，它可以在請求-響應週期的不同部分執行。分為 3 個 Filter：

Inbound Filters：Inbound 過濾器，在請求到源之前執行，可用於身份驗證、路由和裝飾請求等處理操作

Endpoint Filters：Endpoint 過濾器，可用於返回靜態響應，否則內建的 ProxyEndpoint 過濾器會將請求路由到源。

Outbound Filters：Outbound 過濾器，請求處理之後執行，可用於度量、裝飾處理之後的請求或增加自定義 header。

更多 zuul2 Filter 用法請檢視 Filter wiki。

說明：在 zuul2 中編寫 Filter，使用的是 groovy 語言，它可以動態更新，不需要重啟伺服器。

1.3 zuul2 特性

Core Features
Push Messaging

二、SpringCloud Gateway

2.1 介紹

Spring Cloud Gateway3.1.x 旨在提供一種簡單而有效的方式路由到 API，併為它們它們提供橫切關注，比如：安全、監控和彈性。

它是構建在 Spring 生態之上，包括 Spring5、Spring2 和 Project Reactor(Spring WebFlux)。

Spring WebFlux 框架底層使用了 Reactor 模式高效能通訊框架 Netty。

官網：官網地址

github: github 地址

Spring Cloud Gateway 是用來替代 zuul 閘道器，因為 zuul2 開發進度落後。

2.2 Spring Cloud Gateway 特性

Features：

基於 Spring Framework 5、Project Reactor 和 Spring 2.0 構建
能夠在任何請求屬性上匹配路由
Predicates 和 Filters 作用於特定路由，易於編寫的 Predicates 和 Filters
整合了斷路器
整合了 Spring Cloud DiscoveryClient
很容易編寫 Predicates 和 Filters
具備閘道器一些高階功能：動態路由、限流、路由重寫

Spring Cloud Gateway 與 Eureka、Ribbon、Hystrix 等元件配合使用，實現路由轉發、負載均衡、鑑權、熔斷、路由重寫、紀錄檔監控等功能。

Spring Cloud Gateway 中的重要概念：

(1) Filter（過濾器）

可以使用它來攔截和修改請求，並且對它的上文的響應進行處理。

(2) Route（路由）

閘道器設定的基本組成模組。一個 Route 模組由一個 ID，一個目標 URI，一組斷言（Predicate）和一組過濾器（Filter）組成。如果斷言為真，則路由匹配，目標 URI 會被存取。

（3）Predicate（斷言）：

路由轉發的判斷條件，可以使用它來匹配來自 HTTP 請求的任何內容，例如修改請求方式、請求頭內容、請求路徑、請求引數等。如果匹配成功，則轉發到相應的服務裡。

Predicate 是路由的匹配條件，匹配之後，Filter 就對請求和響應進行精細化處理。有了這兩個工具，再加上目標 URI 可以實現一個具體的路由，就可以對具體的路由進行處理操作。

2.3 Gateway 處理流程

流程圖：

使用者端向 Spring Cloud Gateway 發出請求
Spring Cloud Gateway 通過 Gateway Handler Mapping 找到與請求相匹配的路由，將其傳送到 Gateway Web Handler。
Gateway Web Handler 通過指定的過濾器鏈（Filter Chain）來處理請求，然後傳送到實際的執行業務服務中，業務邏輯執行完後返回。
業務邏輯執行完成後，又經過了過濾器鏈（Filter Chain），這裡又可以對執行完後的業務邏輯進行加工處理。

說明：過濾器鏈中的虛線分開過過濾器，是表示過濾器會在業務邏輯處理之前進行 Filter 或處理完之後在進行 Filter。

在請求轉發到伺服器端前（Proied Service 前），可以進行 Filter 處理（上圖中虛線左邊部分），例如許可權檢查、引數效驗、流量監控、協定轉換等處理。

在伺服器端處理完業務邏輯後，也可以進行 Filter 處理（上圖中虛線右邊部分），例如修改響應頭、紀錄檔輸出、流量監控等處理。