摘要:在這里,會將上下文中載入的拼接成,然后調用其方法的,它是的處理請求業務的起點。添加相關依賴之后,會有這個。路由權重相關配置功能相關實現類,這個我們這里不關心。
我們繼續分析上一節提到的 WebHandler
,經過將請求封裝成 ServerWebExchange 的 HttpWebHandlerAdapter 之后,請求會經過 ExceptionHandlingWebHandler
之前有網友私信問過筆者,如何給 Spring Cloud Gateway 加全局異常處理器,其實和給基于 Spring-Flux 的異步 Web 服務加是一樣的,都是通過實現并注冊一個 WebExceptionHandler
Bean:
public interface WebExceptionHandler { Mono handle(ServerWebExchange exchange, Throwable ex);}
這些 Bean,就是在 ExceptionHandlingWebHandler 被加入到整個請求處理鏈路中的:
ExceptionHandlingWebHandler.java
@Overridepublic Mono handle(ServerWebExchange exchange) { Mono completion; try { //這里其實就是組裝后面的鏈路,即調用后面的 FilteringWebHandler 的 handle completion = super.handle(exchange); } catch (Throwable ex) { completion = Mono.error(ex); } for (WebExceptionHandler handler : this.exceptionHandlers) { completion = completion.onErrorResume(ex -> handler.handle(exchange, ex)); } return completion;}
從源碼可以看出,這里將每個 WebExceptionHandler
作為 Mono 的異常處理 onErrorResume
加入了鏈路。onErrorResume
的意思是如果鏈路前面發生異常,則在這里捕獲住異常同時調用 handler.handle(exchange, ex)
進行處理,如果使用阻塞代碼理解,就相當于:
try { //前面的鏈路} catch(Throwable ex) { return handler.handle(exchange, ex)}
這里我們看到有多個 WebExceptionHandler
,都會在鏈路后面追加 onErrorResume
,其實就相當于:
completion.onErrorResume(ex -> webExceptionHandler1.handle(exchange, ex)).onErrorResume(ex -> webExceptionHandler2.handle(exchange, ex)).onErrorResume(ex -> webExceptionHandler3.handle(exchange, ex))...
轉換成阻塞代碼理解,其實就是:
try { completion} catch(Throwable e1) { try { return webExceptionHandler1.handle(exchange, e1) } catch(Throwable e2) { try { return webExceptionHandler2.handle(exchange, ex) } catch(Throwable e2) { return webExceptionHandler3.handle(exchange, ex) //如果還有就繼續疊加 } }}
當 WebExceptionHandler 可以處理這個異常的時候,他的 handle
方法會返回一個真正的響應,否則會返回異常,例如:
public class WebExceptionHandler1 implements WebExceptionHandler { @Override public Mono handle(ServerWebExchange exchange, Throwable ex) { //如果是 ResponseStatusException 則使用異常里面的響應碼和 HTTP 頭填充響應的響應碼和 HTTP 頭 if (ex instanceof ResponseStatusException) { ServerHttpResponse response = exchange.getResponse(); ResponseStatusException responseStatusException = (ResponseStatusException) ex; response.setRawStatusCode(responseStatusException.getRawStatusCode()); responseStatusException.getResponseHeaders() .forEach((name, values) -> values.forEach(value -> response.getHeaders().add(name, value))); //返回響應完成 return response.setComplete(); } //拋出異常,繼續鏈路異常處理 return Mono.error(ex); }}
轉換成同步代碼去理解其實就是:
if (ex instanceof ResponseStatusException) { ServerHttpResponse response = exchange.getResponse(); ResponseStatusException responseStatusException = (ResponseStatusException) ex; response.setRawStatusCode(responseStatusException.getRawStatusCode()); responseStatusException.getResponseHeaders() .forEach((name, values) -> values.forEach(value -> response.getHeaders().add(name, value))); //返回響應完成 return response.setComplete();}//拋出異常,繼續鏈路異常處理throw ex;
如果大家想封裝自己統一的錯誤響應,可以通過實現這個接口進行實現。
接下來進入 FilteringWebHandler,注意是 org.springframework.web.server.handler.FilteringWebHandler
而不是 Spring Cloud Gateway 的 org.springframework.cloud.gateway.handler.FilteringWebHandler
。在這里,會將上下文中載入的 WebFilter 拼接成 DefaultWebFilterChain
,然后調用其 filter 方法:
private final DefaultWebFilterChain chain;public FilteringWebHandler(WebHandler handler, List filters) { super(handler); this.chain = new DefaultWebFilterChain(handler, filters);}@Overridepublic Mono handle(ServerWebExchange exchange) { return this.chain.filter(exchange);}
Spring Cloud Gateway 的 FilteringWebHandler, 它是 Spring Cloud Gateway 的處理請求業務的起點。在這里我們即將進入整個 Spring Cloud Gateway 的 Filter 鏈路,包括每個路徑自己的 GatewayFilter
以及全局的 GlobalGatewayFilter
,都是在這里開始被處理組裝成完整調用鏈路的。我們后面還會提到
由于我們的項目依賴中包含了 Spring Cloud Sleuth 以及 Prometheus 的依賴,所以我們這里的 WebFilter 會包括三個:
org.springframework.boot.actuate.metrics.web.reactive.server.MetricsWebFilter
:添加 Prometheus 相關依賴之后,會有這個 MetricsWebFilter,用于記錄請求處理耗時,采集相關指標。org.springframework.cloud.sleuth.instrument.web.TraceWebFilter
:添加 Spring Cloud Sleuth 相關依賴之后,會有這個 TraceWebFilter。org.springframework.cloud.gateway.handler.predicate.WeightCalculatorWebFilter
:Spring Cloud Gateway 路由權重相關配置功能相關實現類,這個我們這里不關心。其具體流程,我們在下一節中繼續詳細分析。
微信搜索“我的編程喵”關注公眾號,每日一刷,輕松提升技術,斬獲各種offer:
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/125367.html
摘要:在這里,會將上下文中載入的拼接成,然后調用其方法的,它是的處理請求業務的起點。添加相關依賴之后,會有這個。路由權重相關配置功能相關實現類,這個我們這里不關心。 本系列代碼地址:??https://github.com/JoJoTec/spring-cloud-parent??我們繼續分析上一節提到的 ??WebHandle...
摘要:將請求封裝成將請求封裝成的接口定義是但是最外層傳進來的參數是和,需要將他們封裝成,這個工作就是在中做的。其實主要任務就是將各種參數封裝成除了和本次請求相關的和,還有會話管理器,編碼解碼器配置,國際化配置還有用于擴展。本系列代碼地址:https://github.com/JoJoTec/spring-cloud-parent接下來,將進入我們升級之路的又一大模塊,即網關模塊。網關模塊我們廢棄了...
摘要:添加相關依賴之后,會有這個。接著,根據的源碼分析,會繼續鏈路,到達下一個,即。在中,我們會計算出路由并發送請求到符合條件的。這個是的,會讀取配置并生成路由。本系列代碼地址:https://github.com/JoJoTec/spring-cloud-parent我們繼續分析上一節提到的 WebHandler。加入 Spring Cloud Sleuth 以及 Prometheus 相關依賴...
摘要:升級之路版基本流程講解抽象類本系列代碼地址我們繼續分析上一節提到的。添加相關依賴之后,會有這個。路由權重相關配置功能相關實現類,這個我們這里不關心。這個是的,會讀取配置并生成路由。 本系列代碼地址:??https://github.com/JoJoTec/spring-cloud-parent??我們繼續分析上一節提到的 ...
摘要:對于異步的請求,使用的是異步客戶端即。要實現的配置設計以及使用舉例要實現的配置設計以及使用舉例首先,我們要實現的,其包含三個重試重試的要在負載均衡之前,因為重試的時候,我們會從負載均衡器獲取另一個實例進行重試,而不是在同一個實例上重試多次。 本系列代碼地址:https://github.com/JoJoTec/spring-cloud-parent 為何需要封裝異步 HT...
閱讀 3735·2023-01-11 11:02
閱讀 4244·2023-01-11 11:02
閱讀 3050·2023-01-11 11:02
閱讀 5180·2023-01-11 11:02
閱讀 4737·2023-01-11 11:02
閱讀 5534·2023-01-11 11:02
閱讀 5313·2023-01-11 11:02
閱讀 3990·2023-01-11 11:02