Spring Cloud Gateway奪命連環十問？

來源：碼猿技術專欄時間：2023-03-08 08:49:22

這篇文章介紹下微服務中的一個重要角色：網關，對于網關如何選擇，由于阿里系暫時未出網關，當然是選擇了Spring cloud Gateway，畢竟是親兒子。

已經閱讀過該篇文章的朋友可以直接跳過

文章目錄如下：

(資料圖片僅供參考)

為什么需要網關？

傳統的單體架構中只有一個服務開放給客戶端調用，但是微服務架構中是將一個系統拆分成多個微服務，那么作為客戶端如何去調用這些微服務呢？如果沒有網關的存在，只能在本地記錄每個微服務的調用地址。

無網關的微服務架構往往存在以下問題：

客戶端多次請求不同的微服務，增加客戶端代碼或配置編寫的復雜性。認證復雜，每個服務都需要獨立認證。存在跨域請求，在一定場景下處理相對復雜。網關的基本功能？

網關是所有微服務的門戶，路由轉發僅僅是最基本的功能，除此之外還有其他的一些功能，比如：認證、鑒權、熔斷、限流、日志監控等等.........

以上這些應用場景會在后續的文章詳細介紹，不是今天的重點。

為什么選擇Spring cloud Gateway？

在1.x版本中都是采用的Zuul網關；但在2.x版本中，zuul的升級一直跳票，Spring Cloud最后自己研發了一個網關替代Zuul，那就是Spring Cloud Gateway。

肯定選擇親兒子Spring Cloud Gateway，它的很多思想都是借鑒zuul，所謂青出于藍而勝于藍，功能和性能肯定是優于zuul，不然Spring Cloud 為嘛要發布它？

重要的一點原因：

Spring Cloud Gateway 基于Spring Boot 2.x、Spring WebFlux和[Project Reactor構建。

對于Spring Boot 的整合方便兼容性以及性能方面不必擔心。

Spring Cloud Gateway幾個必知的術語？路由（route）：gateway的基本構建模塊。它由ID、目標URI、斷言集合和過濾器集合組成。如果聚合斷言結果為真，則匹配到該路由。斷言（Predicate ）：參照Java8的新特性Predicate，允許開發人員匹配HTTP請求中的任何內容，比如頭或參數。過濾器（filter）：可以在返回請求之前或之后修改請求和響應的內容。網關如何搭建？

為什么要放這張圖？

一定要按照上圖中的版本進行適配，否則會出現意想不到的BUG，陳某遇到過，都是淚............

新建cloud-gateway9023，添加如下依賴：

org.springframework.cloud spring-cloud-starter-gateway

注意：一定要去掉spring-boot-starter-web依賴，否則啟動報錯

好了，項目搭建完成，其實就添加這么一個依賴，關于詳細的配置下文介紹。

什么是Predict（斷言）？

Predicate來自于java8的接口。Predicate接受一個輸入參數，返回一個布爾值結果。該接口包含多種默認方法來將Predicate組合成其他復雜的邏輯（比如：與，或，非）。關注公z號：碼猿技術專欄，回復關鍵詞：1111 獲取阿里內部性能調優手冊！

可以用于接口請求參數校驗、判斷新老數據是否有變化需要進行更新操作。

Spring Cloud Gateway內置了許多Predict，這些Predict的源碼在org.springframework.cloud.gateway.handler.predicate包中，有興趣可以閱讀一下。內置的一些斷言如下圖：

內置的斷言

以上11種斷言陳某這里就不再介紹如何配置了，官方文檔寫的很清楚。

官方文檔：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/

下面就以最后一種權重斷言為例介紹一下如何配置。配置如下：

spring: cloud: gateway: ## 路由 routes: ## id只要唯一即可，名稱任意 - id: gateway-provider_1 uri: http://localhost:9024 ## 配置斷言 predicates: ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中 - Path=/gateway/provider/** ## Weight Route Predicate Factory，同一分組按照權重進行分配流量，這里分配了80% ## 第一個group1是分組名，第二個參數是權重 - Weight=group1, 8 ## id必須唯一 - id: gateway-provider_2 ## 路由轉發的uri uri: http://localhost:9025 ## 配置斷言 predicates: ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中 - Path=/gateway/provider/** ## Weight Route Predicate Factory，同一分組按照權重進行分配流量，這里分配了20% ## 第一個group1是分組名，第二個參數是權重 - Weight=group1, 2

routes下就是配置的路由策略，各個組件如下：

id：路由的唯一id，名稱任意uri：路由轉發的uripredicates：斷言配置，可以配置多個

Spring Cloud Gateway中的斷言命名都是有規范的，格式：xxxRoutePredicateFactory。

比如權重的斷言：WeightRoutePredicateFactory?，那么配置時直接取前面的Weight。

默認的路由轉發如果路由到了兩個，則是的按照配置先后順序轉發，上面都配置了路徑：Path=/gateway/provider/**?，如果沒有配置權重，則肯定是轉發到http://localhost:9024。

但是既然配置配置了權重并且相同的分組，則按照權重比例進行分配流量。

什么是過濾器？

過濾器這個概念很熟悉，在Spring mvc 就接觸過，Gateway的過濾器的作用以及生命周期都是類似的。

Gateway的生命周期：

PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集群中選擇請求的微服務、記錄調試信息等。POST：這種過濾器在路由到微服務以后執行。這種過濾器可用來為響應添加標準的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。

Gateway 的Filter從作用范圍可分為兩種:

GatewayFilter：應用到單個路由或者一個分組的路由上（需要在配置文件中配置）。GlobalFilter：應用到所有的路由上（無需配置，全局生效）GatewayFilter（局部過濾器）

Spring Cloud Gateway中內置了許多的局部過濾器，如下圖：

局部過濾器需要在指定路由配置才能生效，默認是不生效的。

以AddResponseHeaderGatewayFilterFactory這個過濾器為例，為原始響應添加Header，配置如下：

瀏覽器請求，發現響應頭中已經有了X-Response-Foo=Bar這個鍵值對，如下圖：

注意：過濾器的名稱只需要寫前綴，過濾器命名必須是xxxGatewayFilterFactory（包括自定義）。

更多過濾器的配置可以看官方文檔：https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/#gatewayfilter-factories

雖說內置的過濾器能夠解決很多場景，但是難免還是有些特殊需求需要定制一個過濾器，下面就來介紹一下如何自定義局部過濾器。

場景：模擬一個授權驗證的過程，如果請求頭或者請求參數中攜帶token則放行，否則直接攔截返回401，代碼如下：

/** * 名稱必須是xxxGatewayFilterFactory形式 * todo：模擬授權的驗證，具體邏輯根據業務完善 */@Component@Slf4jpublic class AuthorizeGatewayFilterFactory extends AbstractGatewayFilterFactory { private static final String AUTHORIZE_TOKEN = "token"; //構造函數，加載Config public AuthorizeGatewayFilterFactory() { //固定寫法 super(AuthorizeGatewayFilterFactory.Config.class); log.info("Loaded GatewayFilterFactory [Authorize]"); } //讀取配置文件中的參數賦值到配置類中 @Override public List shortcutFieldOrder() { //Config.enabled return Arrays.asList("enabled"); } @Override public GatewayFilter apply(AuthorizeGatewayFilterFactory.Config config) { return (exchange, chain) -> { //判斷是否開啟授權驗證 if (!config.isEnabled()) { return chain.filter(exchange); } ServerHttpRequest request = exchange.getRequest(); HttpHeaders headers = request.getHeaders(); //從請求頭中獲取token String token = headers.getFirst(AUTHORIZE_TOKEN); if (token == null) { //從請求頭參數中獲取token token = request.getQueryParams().getFirst(AUTHORIZE_TOKEN); } ServerHttpResponse response = exchange.getResponse(); //如果token為空，直接返回401，未授權 if (StringUtils.isEmpty(token)) { response.setStatusCode(HttpStatus.UNAUTHORIZED); //處理完成，直接攔截，不再進行下去 return response.setComplete(); } /** * todo chain.filter(exchange) 之前的都是過濾器的前置處理 * * chain.filter().then( * 過濾器的后置處理........... * ) */ //授權正常，繼續下一個過濾器鏈的調用 return chain.filter(exchange); }; } @Data @AllArgsConstructor @NoArgsConstructor public static class Config { // 控制是否開啟認證 private boolean enabled; }}

局部過濾器需要在路由中配置才能生效，配置如下：

此時直接訪問：http://localhost:9023/gateway/provider/port，不攜帶token，返回如下圖：

請求參數帶上token：http://localhost:9023/gateway/provider/port?token=abcdcdecd-ddcdeicd12，成功返回，如下圖：

上述的AuthorizeGatewayFilterFactory?只是涉及到了過濾器的前置處理，后置處理是在chain.filter().then()?中的then()?方法中完成的，具體可以看下項目源碼中的TimeGatewayFilterFactory，代碼就不再貼出來了，如下圖：

GlobalFilter（全局過濾器）

全局過濾器應用到全部路由上，無需開發者配置，Spring Cloud Gateway也內置了一些全局過濾器，如下圖：

GlobalFilter?的功能其實和GatewayFilter?是相同的，只是GlobalFilter?的作用域是所有的路由配置，而不是綁定在指定的路由配置上。多個GlobalFilter?可以通過@Order?或者getOrder()?方法指定每個GlobalFilter?的執行順序，order值越小，GlobalFilter執行的優先級越高。

注意，由于過濾器有pre和post兩種類型，pre類型過濾器如果order值越小，那么它就應該在pre過濾器鏈的頂層，post類型過濾器如果order值越小，那么它就應該在pre過濾器鏈的底層。示意圖如下：

當然除了內置的全局過濾器，實際工作中還需要定制過濾器，下面來介紹一下如何自定義。

場景：模擬Nginx的Access Log 功能，記錄每次請求的相關信息。代碼如下：

/** * 實現GlobalFilter */@Slf4j@Component@Order(value = Integer.MIN_VALUE)public class AccessLogGlobalFilter implements GlobalFilter { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { //filter的前置處理 ServerHttpRequest request = exchange.getRequest(); String path = request.getPath().pathWithinApplication().value(); InetSocketAddress remoteAddress = request.getRemoteAddress(); return chain //繼續調用filter .filter(exchange) //filter的后置處理 .then(Mono.fromRunnable(() -> { ServerHttpResponse response = exchange.getResponse(); HttpStatus statusCode = response.getStatusCode(); log.info("請求路徑:{},遠程IP地址:{},響應碼:{}", path, remoteAddress, statusCode); })); }}

好了，全局過濾器不必在路由上配置，注入到IOC容器中即可全局生效。

此時發出一個請求，控制臺打印信息如下：

請求路徑:/gateway/provider/port,遠程IP地址:/0:0:0:0:0:0:0:1:64114,響應碼:200 OK如何集成注冊中心？

上述demo中并沒有集成注冊中心，每次路由配置都是指定固定的服務uri，如下圖：

這樣做有什么壞處呢？

服務的IP的地址一旦修改了，路由配置中的uri必須修改服務集群中無法實現負載均衡

此時就需要集成的注冊中心，使得網關能夠從注冊中心自動獲取uri（負載均衡）。

這里的注冊中心當然選擇Nacos，又不熟悉的小伙伴請看陳某《Spring Cloud 進階》專欄的第一篇文章：五十五張圖告訴你微服務的靈魂擺渡者Nacos究竟有多強？

pom文件中新增Nacos依賴，如下：

com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery

啟動類上開啟注冊中心功能，如下圖：

配置文件中指定nacos注冊中心的地址：

spring: application: ## 指定服務名稱，在nacos中的名字 name: cloud-gateway cloud: nacos: discovery: # nacos的服務地址，nacos-server中IP地址:端口號 server-addr: 127.0.0.1:8848

路由配置中唯一不同的就是路由的uri?，格式：lb://service-name，這是固定寫法：

lb：固定格式，指的是從nacos中按照名稱獲取微服務,并遵循負載均衡策略service-name：nacos注冊中心的服務名稱，這里并不是IP地址形式的

集成Nacos注冊中心完整的配置demo如下：

spring: application: ## 指定服務名稱，在nacos中的名字 name: cloud-gateway cloud: nacos: discovery: # nacos的服務地址，nacos-server中IP地址:端口號 server-addr: 127.0.0.1:8848 gateway: ## 路由 routes: ## id只要唯一即可，名稱任意 - id: gateway-provider_1 ## 使用了lb形式，從注冊中心負載均衡的獲取uri uri: lb://gateway-provider ## 配置斷言 predicates: ## Path Route Predicate Factory斷言，滿足/gateway/provider/**這個請求路徑的都會被路由到http://localhost:9024這個uri中 - Path=/gateway/provider/** ## 配置過濾器（局部） filters: - AddRespnotallow=X-Response-Foo, Bar

為什么指定了lb?就可以開啟負載均衡，前面說過全局過濾器LoadBalancerClientFilter就是負責路由尋址和負載均衡的，可以看到如下源碼：

如何實現動態路由？

上述例子都是將網關的一系列配置寫到項目的配置文件中，一旦路由發生改變必須要重新項目，這樣維護成本很高。

其實我們可以將網關的配置存放到配置中心中，這樣由配置中心統一管理，一旦路由發生改變，只需要在配置中心修改，這樣便能達到一處修改，多出生效的目的。

這里當然要使用Nacos作為配置中心了，添加依賴如下：

com.alibaba.cloud spring-cloud-starter-alibaba-nacos-config

在bootstrap.yml文件中指定Nacos作為配置中心的一些相關配置：

spring: application: ## 指定服務名稱，在nacos中的名字 name: cloud-gateway cloud: nacos: ## todo 此處作為演示，僅僅配置了后綴，其他分組，命名空間根據需要自己配置 config: server-addr: 127.0.0.1:8848 ## 指定文件后綴未yaml file-extension: yaml

在nacos中的public命名空間中創建dataId為cloud-gateway.yaml的配置（未指定環境），配置內容如下：

到這里已經配置完成了。至于效果自己動動小手試試吧...............

如何自定義全局異常處理？

通過前面的測試可以看到一個現象：一旦路由的微服務下線或者失聯了，Spring Cloud Gateway直接返回了一個錯誤頁面，如下圖：

顯然這種異常信息不友好，前后端分離架構中必須定制返回的異常信息。

傳統的Spring Boot 服務中都是使用@ControllerAdvice來包裝全局異常處理的，但是由于服務下線，請求并沒有到達。

因此必須在網關中也要定制一層全局異常處理，這樣才能更加友好的和客戶端交互。

Spring Cloud Gateway提供了多種全局處理的方式，今天陳某只介紹其中一種方式，實現還算比較優雅。

直接創建一個類GlobalErrorExceptionHandler?，實現ErrorWebExceptionHandler?，重寫其中的handle方法，代碼如下：

/** * 用于網關的全局異常處理 * @Order(-1)：優先級一定要比ResponseStatusExceptionHandler低 */@Slf4j@Order(-1)@Component@RequiredArgsConstructorpublic class GlobalErrorExceptionHandler implements ErrorWebExceptionHandler { private final ObjectMapper objectMapper; @SuppressWarnings({"rawtypes", "unchecked", "NullableProblems"}) @Override public Mono handle(ServerWebExchange exchange, Throwable ex) { ServerHttpResponse response = exchange.getResponse(); if (response.isCommitted()) { return Mono.error(ex); } // JOSN格式返回 response.getHeaders().setContentType(MediaType.APPLICATION_JSON); if (ex instanceof ResponseStatusException) { response.setStatusCode(((ResponseStatusException) ex).getStatus()); } return response.writeWith(Mono.fromSupplier(() -> { DataBufferFactory bufferFactory = response.bufferFactory(); try { //todo 返回響應結果，根據業務需求，自己定制 CommonResponse resultMsg = new CommonResponse("500",ex.getMessage(),null); return bufferFactory.wrap(objectMapper.writeValueAsBytes(resultMsg)); } catch (JsonProcessingException e) { log.error("Error writing response", ex); return bufferFactory.wrap(new byte[0]); } })); }}

好了，全局異常處理已經定制完成了，在測試一下，此時正常返回JSON數據了，如下圖：

JSON的樣式根據架構需要自己定制。

總結

Spring Cloud Gateway今天就分享到這里，主要介紹了以下幾個知識點：

為什么需要網關？網關的基本功能如何從零搭建一個微服務網關Predict（斷言）的概念過濾器的概念、Spring Cloud Gateway內置的過濾器以及如何自定義如何集成Nacos注冊中心并且實現負載均衡如何集成Nacos實現動態路由，達到一處修改，多出生效的作用全局異常的處理

你認為Spring Cloud Gateway就介紹完了？不可能，后續還有更深入以及實戰的介紹，下篇文章介紹.....

關鍵詞：

為你推薦

X 關閉

網絡

X 關閉

專題

商用

在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉