org.springframework.cloud.gateway?是 Spring Cloud 生態系統中的一個新一代的、功能強大的 API 網關。
1. 什么是 API 網關 (API Gateway)?
在講解 Spring Cloud Gateway 之前,我們先要理解它扮演的角色——API 網關。
在一個微服務架構中,系統被拆分成多個獨立的服務(如用戶服務、商品服務、訂單服務等)。客戶端(如網頁、手機 App)如果直接和這些服務通信,會面臨很多問題:
-
地址管理復雜:客戶端需要知道所有服務的網絡地址。
-
認證授權繁瑣:每個服務都需要獨立做用戶認證。
-
跨域問題:瀏覽器訪問不同域的服務會產生跨域問題。
-
協議轉換困難:如果有的服務用 HTTP,有的用 WebSocket,客戶端處理起來很麻煩。
API 網關就是為了解決這些問題而誕生的。它像一個“大門”或“前臺接待”,統一接收所有外部請求,然后根據一定的規則,將請求轉發到內部對應的微服務上。
網關的核心職責包括:
-
路由 (Routing):將請求轉發到正確的微服務。
-
認證與安全 (Authentication & Security):統一處理身份驗證、權限控制。
-
負載均衡 (Load Balancing):將請求分發到服務的多個實例上。
-
限流熔斷 (Rate Limiting & Circuit Breaking):防止流量過大沖垮后端服務。
-
日志監控 (Logging & Monitoring):記錄請求日志,監控系統健康狀況。
-
協議轉換:如 HTTP 到 gRPC 的轉換。
2. Spring Cloud Gateway 詳解
org.springframework.cloud.gateway?就是 Spring 官方推出的用于構建 API 網關的框架。它是對之前 Netflix Zuul 1.x 的替代和升級。
核心特性
-
基于響應式編程模型:它構建于 Spring Framework 5, Project Reactor 和 Spring Boot 2之上,底層網絡通信使用的是?Netty。這使得它是一個完全異步、非阻塞的網關。相比于 Zuul 1.x 的阻塞式 I/O 模型,Gateway 在高并發場景下性能更好,資源消耗更低。
-
動態路由:可以與服務發現組件(如 Eureka, Consul, Nacos)無縫集成,動態地從注冊中心獲取服務地址并創建路由,無需重啟網關。
-
強大的斷言(Predicate)和過濾器(Filter):這是 Gateway 的核心。你可以通過非常靈活的方式來定義路由規則和請求處理邏輯。
-
易于配置:支持通過配置文件(如?application.yml)或 Java Bean 的方式進行配置。
-
高集成度:與 Spring Cloud 生態的其他組件(如 Spring Security, Resilience4j)可以很好地集成,輕松實現安全、熔斷等功能。
-
支持 Websockets。
3. 三大核心概念
Spring Cloud Gateway 的工作原理基于三個核心概念:路由 (Route)、斷言 (Predicate)?和?過濾器 (Filter)。
a. 路由 (Route)
路由是網關最基本的組成單元。它由以下幾個部分構成:
-
ID: 路由的唯一標識。
-
目標 URI: 請求最終被轉發到的目標地址。
-
一組斷言 (Predicates): 決定一個請求是否匹配該路由的條件。
-
一組過濾器 (Filters): 在請求被轉發前后對其進行修改或處理。
b. 斷言 (Predicate)
斷言就是一個布爾值判斷,輸入是?ServerWebExchange(包含了 HTTP 請求的所有信息),輸出是?true?或?false。如果一個請求滿足了某個路由的所有斷言條件,那么這個請求就會被該路由處理。
Spring Cloud Gateway 內置了多種斷言工廠,可以讓你根據請求的各種屬性來匹配路由:
-
Path: 根據請求的 URL 路徑進行匹配。例如?Path=/users/**。
-
Method: 根據請求的方法進行匹配。例如?Method=GET。
-
Header: 根據請求頭進行匹配。例如?Header=X-Request-Id, \d+。
-
Query: 根據請求參數進行匹配。例如?Query=name, john。
-
Host: 根據主機名進行匹配。例如?Host=**.somehost.org。
-
Cookie: 根據 Cookie 進行匹配。
-
After/Before/Between: 根據時間進行匹配。
多個斷言可以組合使用,它們之間是“與”(AND)的關系。
c. 過濾器 (Filter)
過濾器用于在請求被路由之前或之后,對請求和響應進行修改。過濾器分為兩種類型:
-
GatewayFilter: 作用于單個路由。
-
GlobalFilter: 全局過濾器,作用于所有路由。
過濾器的生命周期分為 "pre" 和 "post" 兩個階段:
-
Pre-filtering: 在請求被轉發到下游服務之前執行。可以用來添加請求頭、記錄日志、進行權限驗證等。
-
Post-filtering: 在下游服務返回響應之后執行。可以用來修改響應體、添加響應頭等。
常見的內置過濾器有:
-
AddRequestHeader,?AddResponseHeader: 添加請求/響應頭。
-
RewritePath: 重寫請求路徑。
-
Retry: 失敗重試。
-
RateLimiter: 請求限流。
-
CircuitBreaker: 熔斷器。
4. 工作流程
一個請求進入 Spring Cloud Gateway 的完整流程如下:
-
客戶端向 Gateway 發送請求。
-
Gateway 的?Handler Mapping?模塊接收請求,并根據一系列的斷言 (Predicates)?來尋找匹配的路由 (Route)。
-
一旦找到匹配的路由,請求就會被發送給 Gateway 的?Web Handler。
-
Web Handler 會將請求通過一個過濾器鏈 (Filter Chain)。
-
在 "pre" 階段,請求會依次經過所有全局過濾器 (GlobalFilters)?和該路由配置的網關過濾器 (GatewayFilters)。
-
過濾器鏈執行完畢后,Gateway 發出代理請求,通過負載均衡(如?lb://?協議)將請求轉發到真正的后端微服務。
-
微服務處理請求并返回響應。
-
響應會再次經過過濾器鏈的 "post" 階段,倒序執行所有過濾器。
-
最終,Gateway 將處理后的響應返回給客戶端。
5. 配置示例
下面是一個典型的?application.yml?配置,它展示了如何定義路由:
spring:cloud:gateway:# 開啟與服務發現組件的集成discovery:locator:enabled: truelower-case-service-id: true # 將服務名轉為小寫# 定義路由規則routes:# 路由1:訪問 /user/** 的請求會被轉發到 user-service- id: user_service_route # 路由的唯一IDuri: lb://user-service # 目標URI,lb:// 表示從服務發現中獲取地址predicates: # 斷言條件- Path=/user/**filters: # 過濾器# 重寫路徑,例如 /user/1 -> /1- RewritePath=/user/(?<segment>.*), /$\{segment} # 路由2:訪問 /product/** 的請求會被轉發到 product-service- id: product_service_routeuri: lb://product-servicepredicates:- Path=/product/**
content_copydownload
Use code?with caution.Yaml
解釋:
-
id: 路由的唯一標識,方便管理。
-
uri: lb://user-service:?lb?是?load-balancer?的縮寫,表示 Gateway 會從服務注冊中心(如 Nacos、Eureka)查找名為?user-service?的服務,并對其進行負載均衡。
-
predicates: - Path=/user/**: 當請求的路徑匹配?/user/?開頭的模式時,該路由生效。
-
filters: - RewritePath...: 這是一個過濾器,它會重寫請求路徑。例如,當客戶端請求?http://gateway-host/user/profile/1?時,Gateway 會將請求路徑修改為?/profile/1,然后再轉發給?user-service。
6. 總結:為什么要用 Spring Cloud Gateway?
-
性能優越:基于非阻塞模型,適合處理高并發 I/O 密集型任務。
-
功能強大:提供了豐富的路由、斷言和過濾器,能滿足絕大多數網關場景的需求。
-
與 Spring Cloud 生態無縫集成:是目前構建 Spring Cloud 微服務架構的首選網關。
-
易于開發和擴展:可以輕松編寫自定義的過濾器和斷言,實現復雜的業務邏輯。
總而言之,org.springframework.cloud.gateway?是一個現代、高效、功能完備的 API 網關解決方案,是 Spring Cloud 微服務技術棧中不可或缺的一環。