2. 程式人生 > >Spring Cloud Gateway-自定義異常處理

Spring Cloud Gateway-自定義異常處理

阿新 • • 發佈：2019-05-11

前提

我們平時在用SpringMVC的時候，只要是經過DispatcherServlet處理的請求，可以通過@ControllerAdvice和@ExceptionHandler自定義不同型別異常的處理邏輯，具體可以參考ResponseEntityExceptionHandler和DefaultHandlerExceptionResolver，底層原理很簡單，就是發生異常的時候搜尋容器中已經存在的異常處理器並且匹配對應的異常型別，匹配成功之後使用該指定的異常處理器返回結果進行Response的渲染，如果找不到預設的異常處理器則用預設的進行兜底(個人認為，Spring在很多功能設計的時候都有這種“有則使用自定義，無則使用預設提供”這種思想十分優雅)。

SpringMVC中提供的自定義異常體系在Spring-WebFlux中並不適用，其實原因很簡單，兩者底層的執行容器並不相同。WebExceptionHandler是Spring-WebFlux的異常處理器頂層介面，因此追溯到子類可以追蹤到DefaultErrorWebExceptionHandler是Spring Cloud Gateway的全域性異常處理器，配置類是ErrorWebFluxAutoConfiguration。

為什麼要自定義異常處理

先畫一個假想但是貼近實際架構圖，定位一下閘道器的作用：

閘道器在整個架構中的作用是：

  1. 路由服務端應用的請求到後端應用。
  2. (聚合)後端應用的響應轉發到服務端應用。

假設閘道器服務總是正常的前提下：

對於第1點來說，假設後端應用不能平滑無損上線，會有一定的機率出現閘道器路由請求到一些後端的“殭屍節點(請求路由過去的時候，應用更好在重啟或者剛好停止)”，這個時候會路由會失敗丟擲異常，一般情況是Connection Refuse。

對於第2點來說，假設後端應用沒有正確處理異常，那麼應該會把異常資訊經過閘道器轉發回到服務端應用，這種情況理論上不會出現異常。

其實還有第3點隱藏的問題，閘道器如果不單單承擔路由的功能，還包含了鑑權、限流等功能，如果這些功能開發的時候對異常捕獲沒有做完善的處理甚至是邏輯本身存在BUG，有可能導致異常沒有被正常捕獲處理，走了預設的異常處理器DefaultErrorWebExceptionHandler

，預設的異常處理器的處理邏輯可能並不符合我們預期的結果。

如何自定義異常處理

我們可以先看預設的異常處理器的配置類ErrorWebFluxAutoConfiguration：

@Configuration
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.REACTIVE)
@ConditionalOnClass(WebFluxConfigurer.class)
@AutoConfigureBefore(WebFluxAutoConfiguration.class)
@EnableConfigurationProperties({ ServerProperties.class, ResourceProperties.class })
public class ErrorWebFluxAutoConfiguration {

    private final ServerProperties serverProperties;

    private final ApplicationContext applicationContext;

    private final ResourceProperties resourceProperties;

    private final List<ViewResolver> viewResolvers;

    private final ServerCodecConfigurer serverCodecConfigurer;

    public ErrorWebFluxAutoConfiguration(ServerProperties serverProperties,
            ResourceProperties resourceProperties,
            ObjectProvider<ViewResolver> viewResolversProvider,
            ServerCodecConfigurer serverCodecConfigurer,
            ApplicationContext applicationContext) {
        this.serverProperties = serverProperties;
        this.applicationContext = applicationContext;
        this.resourceProperties = resourceProperties;
        this.viewResolvers = viewResolversProvider.orderedStream()
                .collect(Collectors.toList());
        this.serverCodecConfigurer = serverCodecConfigurer;
    }

    @Bean
    @ConditionalOnMissingBean(value = ErrorWebExceptionHandler.class,
            search = SearchStrategy.CURRENT)
    @Order(-1)
    public ErrorWebExceptionHandler errorWebExceptionHandler(
            ErrorAttributes errorAttributes) {
        DefaultErrorWebExceptionHandler exceptionHandler = new DefaultErrorWebExceptionHandler(
                errorAttributes, this.resourceProperties,
                this.serverProperties.getError(), this.applicationContext);
        exceptionHandler.setViewResolvers(this.viewResolvers);
        exceptionHandler.setMessageWriters(this.serverCodecConfigurer.getWriters());
        exceptionHandler.setMessageReaders(this.serverCodecConfigurer.getReaders());
        return exceptionHandler;
    }

    @Bean
    @ConditionalOnMissingBean(value = ErrorAttributes.class,
            search = SearchStrategy.CURRENT)
    public DefaultErrorAttributes errorAttributes() {
        return new DefaultErrorAttributes(
                this.serverProperties.getError().isIncludeException());
    }
}

注意到兩個Bean例項ErrorWebExceptionHandler和DefaultErrorAttributes都使用了@ConditionalOnMissingBean註解，也就是我們可以通過自定義實現去覆蓋它們。先自定義一個CustomErrorWebFluxAutoConfiguration（除了ErrorWebExceptionHandler的自定義實現，其他直接拷貝ErrorWebFluxAutoConfiguration）：

@Configuration
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.REACTIVE)
@ConditionalOnClass(WebFluxConfigurer.class)
@AutoConfigureBefore(WebFluxAutoConfiguration.class)
@EnableConfigurationProperties({ServerProperties.class, ResourceProperties.class})
public class CustomErrorWebFluxAutoConfiguration {

    private final ServerProperties serverProperties;

    private final ApplicationContext applicationContext;

    private final ResourceProperties resourceProperties;

    private final List<ViewResolver> viewResolvers;

    private final ServerCodecConfigurer serverCodecConfigurer;

    public CustomErrorWebFluxAutoConfiguration(ServerProperties serverProperties,
                                               ResourceProperties resourceProperties,
                                               ObjectProvider<ViewResolver> viewResolversProvider,
                                               ServerCodecConfigurer serverCodecConfigurer,
                                               ApplicationContext applicationContext) {
        this.serverProperties = serverProperties;
        this.applicationContext = applicationContext;
        this.resourceProperties = resourceProperties;
        this.viewResolvers = viewResolversProvider.orderedStream()
                .collect(Collectors.toList());
        this.serverCodecConfigurer = serverCodecConfigurer;
    }

    @Bean
    @ConditionalOnMissingBean(value = ErrorWebExceptionHandler.class,
            search = SearchStrategy.CURRENT)
    @Order(-1)
    public ErrorWebExceptionHandler errorWebExceptionHandler(ErrorAttributes errorAttributes) {
        // TODO 這裡完成自定義ErrorWebExceptionHandler實現邏輯
        return null;
    }

    @Bean
    @ConditionalOnMissingBean(value = ErrorAttributes.class, search = SearchStrategy.CURRENT)
    public DefaultErrorAttributes errorAttributes() {
        return new DefaultErrorAttributes(this.serverProperties.getError().isIncludeException());
    }
}

ErrorWebExceptionHandler的實現，可以直接參考DefaultErrorWebExceptionHandler，甚至直接繼承DefaultErrorWebExceptionHandler，覆蓋對應的方法即可。這裡直接把異常資訊封裝成下面格式的Response返回，最後需要渲染成JSON格式：

{
  "code": 200,
  "message": "描述資訊",
  "path" : "請求路徑",
  "method": "請求方法"
}

我們需要分析一下DefaultErrorWebExceptionHandler中的一些原始碼：

// 封裝異常屬性
protected Map<String, Object> getErrorAttributes(ServerRequest request, boolean includeStackTrace) {
    return this.errorAttributes.getErrorAttributes(request, includeStackTrace);
}

// 渲染異常Response
protected Mono<ServerResponse> renderErrorResponse(ServerRequest request) {
    boolean includeStackTrace = isIncludeStackTrace(request, MediaType.ALL);
    Map<String, Object> error = getErrorAttributes(request, includeStackTrace);
    return ServerResponse.status(getHttpStatus(error))
            .contentType(MediaType.APPLICATION_JSON_UTF8)
            .body(BodyInserters.fromObject(error));
}

// 返回路由方法基於ServerResponse的物件
@Override
protected RouterFunction<ServerResponse> getRoutingFunction(ErrorAttributes errorAttributes) {
    return route(acceptsTextHtml(), this::renderErrorView).andRoute(all(), this::renderErrorResponse);
}

// HTTP響應狀態碼的封裝，原來是基於異常屬性的status屬性進行解析的
protected HttpStatus getHttpStatus(Map<String, Object> errorAttributes) {
    int statusCode = (int) errorAttributes.get("status");
    return HttpStatus.valueOf(statusCode);
}

確定三點：

  1. 最後封裝到響應體的物件來源於DefaultErrorWebExceptionHandler#getErrorAttributes()，並且結果是一個Map<String, Object>例項轉換成的位元組序列。
  2. 原來的RouterFunction實現只支援HTML格式返回，我們需要修改為JSON格式返回(或者說支援所有格式返回)。
  3. DefaultErrorWebExceptionHandler#getHttpStatus()是響應狀態碼的封裝，原來的邏輯是基於異常屬性getErrorAttributes()的status屬性進行解析的。

自定義的JsonErrorWebExceptionHandler如下：

public class JsonErrorWebExceptionHandler extends DefaultErrorWebExceptionHandler {

    public JsonErrorWebExceptionHandler(ErrorAttributes errorAttributes,
                                        ResourceProperties resourceProperties,
                                        ErrorProperties errorProperties,
                                        ApplicationContext applicationContext) {
        super(errorAttributes, resourceProperties, errorProperties, applicationContext);
    }

    @Override
    protected Map<String, Object> getErrorAttributes(ServerRequest request, boolean includeStackTrace) {
        // 這裡其實可以根據異常型別進行定製化邏輯
        Throwable error = super.getError(request);
        Map<String, Object> errorAttributes = new HashMap<>(8);
        errorAttributes.put("message", error.getMessage());
        errorAttributes.put("code", HttpStatus.INTERNAL_SERVER_ERROR.value());
        errorAttributes.put("method", request.methodName());
        errorAttributes.put("path", request.path());
        return errorAttributes;
    }

    @Override
    protected RouterFunction<ServerResponse> getRoutingFunction(ErrorAttributes errorAttributes) {
        return RouterFunctions.route(RequestPredicates.all(), this::renderErrorResponse);
    }

    @Override
    protected HttpStatus getHttpStatus(Map<String, Object> errorAttributes) {
        // 這裡其實可以根據errorAttributes裡面的屬性定製HTTP響應碼
        return HttpStatus.INTERNAL_SERVER_ERROR;
    }
}

配置類CustomErrorWebFluxAutoConfiguration新增JsonErrorWebExceptionHandler：

@Bean
@ConditionalOnMissingBean(value = ErrorWebExceptionHandler.class, search = SearchStrategy.CURRENT)
@Order(-1)
public ErrorWebExceptionHandler errorWebExceptionHandler(ErrorAttributes errorAttributes) {
    JsonErrorWebExceptionHandler exceptionHandler = new JsonErrorWebExceptionHandler(
                errorAttributes,
                resourceProperties,
                this.serverProperties.getError(),
                applicationContext);
    exceptionHandler.setViewResolvers(this.viewResolvers);
    exceptionHandler.setMessageWriters(this.serverCodecConfigurer.getWriters());
    exceptionHandler.setMessageReaders(this.serverCodecConfigurer.getReaders());
    return exceptionHandler;
}

很簡單，這裡把異常的HTTP響應狀態碼統一為HttpStatus.INTERNAL_SERVER_ERROR(500)，改造的東西並不多，只要瞭解原來異常處理的上下文邏輯即可。

測試

測試場景一：只啟動閘道器，下游服務不啟動的情況下直接呼叫下游服務：

curl http://localhost:9090/order/host

// 響應結果
{"path":"/order/host","code":500,"message":"Connection refused: no further information: localhost/127.0.0.1:9091","method":"GET"}

測試場景二：下游服務正常啟動和呼叫，閘道器自身丟擲異常。

在閘道器應用自定義一個全域性過濾器並且故意丟擲異常：

@Component
public class ErrorGlobalFilter implements GlobalFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        int i = 1/0;
        return chain.filter(exchange);
    }
}
curl http://localhost:9090/order/host

// 響應結果
{"path":"/order/host","code":500,"message":"/ by zero","method":"GET"}

響應結果和定製的邏輯一致，並且後臺的日誌也列印了對應的異常堆疊。

小結

筆者一直認為，做異常分類和按照分類處理是工程裡面十分重要的一環。筆者在所在公司負責的系統中，堅持實現異常分類捕獲，主要是需要區分可以重試補償以及無法重試需要及時預警的異常，這樣子才能針對可恢復異常定製自愈邏輯，對不能恢復的異常及時預警和人為介入。所以，Spring Cloud Gateway這個技術棧也必須調研其自定義異常的處理邏輯。

原文連結

  • GitHub Page：http://www.throwable.club/2019/05/11/spring-cloud-gateway-custom-exception-handler
  • Coding Page：http://throwable.coding.me/2019/05/11/spring-cloud-gateway-custom-exception-handler

(本文完 c-1-d e-a-201905

相關推薦

Spring Cloud Gateway-自定義異常處理

前提 我們平時在用SpringMVC的時候，只要是經過DispatcherServlet處理的請求，可以通過@ControllerAdvice和@ExceptionHandler自定義不同型別異常的處理邏輯，具體可以參考ResponseEntityExceptionHandler和DefaultHandler

Spring Cloud Gateway 自定義限流

在使用Spring Cloud Gateway限流功能時官網提供的限流中的流速以及桶容量是針對所有策略的，意思是隻要配置上那麼所有的都是一樣的，不能根據不同的型別配置不同的引數，例如：A渠道、B渠道，若配置上replenishRate（流速）和burstCapacity（令牌桶容量），那

【本人禿頂程式設計師】Spring Cloud Gateway的全域性異常處理

←←←←←←←←←←←← 我都禿頂了，還不點關注！ Spring Cloud Gateway中的全域性異常處理不能直接用@ControllerAdvice來處理，通過跟蹤異常資訊的丟擲，找到對應的原始碼，自定義一些處理邏輯來符合業務的需求。 閘道器都是給介面做代理轉發的，後端對應的都

Spring Cloud Gateway的全域性異常處理

Spring Cloud Gateway中的全域性異常處理不能直接用@ControllerAdvice來處理，通過跟蹤異常資訊的丟擲，找到對應的原始碼，自定義一些處理邏輯來符合業務的需求。 閘道器都是給介面做代理轉發的，後端對應的都是REST API，返回資料格

Spring Cloud zuul自定義統一異常處理實現

Zuul在springcloud微服務體系中提供filer和router功能，是微服務不可或缺的部分。filer處理預設實現的外還可以自定義進行授權、限流、安全校驗等，router完全可以替代Nginx反向代理。Zuul異常處理就是由SendError

Spring Cloud實戰 | 第九篇：Spring Cloud整合Spring Security OAuth2認證伺服器統一認證自定義異常處理

[本文完整程式碼下載點選](https://github.com/hxrui/youlai-mall.git) # 一. 前言 相信瞭解過我或者看過我之前的系列文章應該多少知道點我寫這些文章包括建立 [有來商城youlai-mall](https://github.com/hxrui/youlai

shiro與spring security如何用自定義異常處理401

背景 現在是前後端分離的時代，後端必然要統一處理返回結果，比如定義一個返回物件 public class ResponseData<T> { /** * 統一返回碼 */ public String rtnCode; /*

在java Spring基礎上實現自定義異常處理框架教程

應用專案大致的體系結構：         該異常處理框架滿足的要求： 完整的異常組織結構異常的統一處理可配置，受管式，方便使用 完整的異常組織結構： 使用者可以方便的定義自己的異常，但所有UncheckedException需要繼承BaseAppRuntimeExce

Spring MVC 全域性異常處理-RESTAPI介面返回統一JSON格式-自定義異常處理--404異常捕捉

寫之前大概兩週草草的將一些程式碼儲存在草稿箱，今天有空來看，結果都沒有了【怨念】—重新整理一下了 —–【轉載請標註出處】 第一部分：需求 第二部分：實現方式 第三部分：404異常捕捉不能實現分析 第四部分：原因和原始碼分析 第五部分：最終總結 需求

Spring boot+Security OAuth2 爬坑日記（4）自定義異常處理 上

為了方便與前端更好的互動，服務端要提供友好統一的資訊返回格式，（他好我也好 ->_-> ），Spring Security OAuth2 提供了自定義異常的入口；我們需要做的就是實現對應的介面，然後將實現的類配置到對應的入口即可。預設的資訊返回格式

關於spring下自定義異常處理的功能

問題：本週在把現有專案整合shiro，問題是前端使用的是angularjs，如果對於單個的Controller，失敗後可以直接在程式碼塊中做try-catch來捕獲異常，進而返回給頁面或者是ajax的

Spring Cloud Feign 自定義配置(重試、攔截與錯誤碼處理) 實踐

# Spring Cloud Feign 自定義配置(重試、攔截與錯誤碼處理) 實踐 [TOC] > 本篇文章主要分享下 Feign 自定義配置的工程實踐，希望你們可以找到些有用的東西，文章已被[公眾號](https://mp.weixin.qq.com/s/lHAMhbrBo5mIkQbitSyfLw)收

Springboot自定義異常處理

tro 定義 異常 handler .get png map spa sta 1.自定義異常類 import lombok.Data; @Data public class UserException extends RuntimeException { pr

自定義異常處理類及錯誤提示類的使用技巧

一.關於自定義處理異常類及聯合自定義錯誤提示類的使用     1.專案內自定義py檔案,使用者存放自定義的錯誤提示類 class BaseResponse(object):     def __init__(self):

Spring Cloud實戰Zuul統一異常處理

Spring Cloud實戰Zuul統一異常處理   Spring Cloud Zuul中自己實現的一些核心過濾器，以及這些過濾器在請求生命週期中的不同作用。我們會發現在這些核心過濾器中並沒有實現error階段的過濾器。那麼這些過濾器可以用來做什麼呢？接下來，本文將介紹如何利用er

springboot錯誤資訊返回與自定義異常處理

在很多系統中，我們可能在執行時出現各種異常，有系統異常，程式碼異常，自定義的異常。這時候我們就要把這些錯誤異常資訊返回去給客戶端檢視才知道是哪裡出問題。這裡我們就說說spring boot的異常處理。   springboot錯誤資訊返回: 實際上，如果我們訪問一個url,不同

datatables自定義異常處理

關閉alert提示,改為控制檯輸出錯誤 $.fn.dataTable.ext.errMode = 'none'; $('#example') .on( 'error.dt', function ( e, settings, techNote, message ) {

java自定義異常處理類

/*** * 為什麼使用自定義異常? * 更加精確定位具體異常資訊 * * 繼承RuntimeException,實現RuntimeException的所有構造方法,就是一種自定義異常類 * */ public class ServiceException extends Runti

Java程式設計中Springboot的異常處理與自定義異常處理教程

元旦很快就到來了，提前祝各位元旦快樂，今天給大家分享一個工作中必用一個知識點，就是在Java開發中使用列舉構建自定義異常並應用於springboot的異常處理器。 開始之前我先把這個案例的結構大致說明一下： 1、使用idea建立一個springboot的Gradle/Maven專案，引入we

Python Flask，捕獲異常，捕獲404錯誤，errorhandler()，自定義異常處理函式

  demo.py（捕獲異常，自定義異常處理函式）： # coding:utf-8 from flask import Flask app = Flask(__name__) # 捕獲404異常錯誤 @app.errorhandler(404) # 當發生404錯誤時，會被