在上一篇《Spring Cloud源碼分析(四)Zuul：核心過濾器》一文中，我們詳細介紹了Spring Cloud Zuul中自己實現的一些核心過濾器，以及這些過濾器在請求生命周期中的不同作用。我們會發現在這些核心過濾器中并沒有實現error階段的過濾器。那么這些過濾器可以用來做什么呢?接下來，本文將介紹如何利用error過濾器來實現統一的異常處理。

[[191637]]

過濾器中拋出異常的問題

首先，我們可以來看看默認情況下，過濾器中拋出異常Spring Cloud Zuul會發生什么現象。我們創建一個pre類型的過濾器，并在該過濾器的run方法實現中拋出一個異常。比如下面的實現，在run方法中調用的doSomething方法將拋出RuntimeException異常。

public class ThrowExceptionFilter extends ZuulFilter { 
    private static Logger log = LoggerFactory.getLogger(ThrowExceptionFilter.class); 
    @Override 
    public String filterType() { 
        return "pre"; 
    } 
    @Override 
    public int filterOrder() { 
        return 0; 
    } 
    @Override 
    public boolean shouldFilter() { 
        return true; 
    } 
    @Override 
    public Object run() { 
        log.info("This is a pre filter, it will throw a RuntimeException"); 
        doSomething(); 
        return null; 
    } 
    private void doSomething() { 
        throw new RuntimeException("Exist some errors..."); 
    } 
} 

運行網關程序并訪問某個路由請求，此時我們會發現：在API網關服務的控制臺中輸出了ThrowExceptionFilter的過濾邏輯中的日志信息，但是并沒有輸出任何異常信息，同時發起的請求也沒有獲得任何響應結果。為什么會出現這樣的情況呢?我們又該如何在過濾器中處理異常呢?

解決方案一：嚴格的try-catch處理

回想一下，我們在上一節中介紹的所有核心過濾器，是否還記得有一個post過濾器SendErrorFilter是用來處理異常信息的?根據正常的處理流程，該過濾器會處理異常信息，那么這里沒有出現任何異常信息說明很有可能就是這個過濾器沒有被執行。所以，我們不妨來詳細看看SendErrorFilter的shouldFilter函數：

public boolean shouldFilter() { 
    RequestContext ctx = RequestContext.getCurrentContext(); 
    return ctx.containsKey("error.status_code") && !ctx.getBoolean(SEND_ERROR_FILTER_RAN, false); 
} 

可以看到該方法的返回值中有一個重要的判斷依據ctx.containsKey("error.status_code")，也就是說請求上下文中必須有error.status_code參數，我們實現的ThrowExceptionFilter中并沒有設置這個參數，所以自然不會進入SendErrorFilter過濾器的處理邏輯。那么我們要如何用這個參數呢?我們可以看一下route類型的幾個過濾器，由于這些過濾器會對外發起請求，所以肯定會有異常需要處理，比如RibbonRoutingFilter的run方法實現如下：

public Object run() { 
    RequestContext context = RequestContext.getCurrentContext(); 
    this.helper.addIgnoredHeaders(); 
    try { 
        RibbonCommandContext commandContext = buildCommandContext(context); 
        ClientHttpResponse response = forward(commandContext); 
        setResponse(response); 
        return response; 
    } 
    catch (ZuulException ex) { 
        context.set(ERROR_STATUS_CODE, ex.nStatusCode); 
        context.set("error.message", ex.errorCause); 
        context.set("error.exception", ex); 
    } 
    catch (Exception ex) { 
        context.set("error.status_code", HttpServletResponse.SC_INTERNAL_SERVER_ERROR); 
        context.set("error.exception", ex); 
    } 
    return null; 
} 

可以看到，整個發起請求的邏輯都采用了try-catch塊處理。在catch異常的處理邏輯中并沒有做任何輸出操作，而是往請求上下文中添加一些error相關的參數，主要有下面三個參數：

• error.status_code：錯誤編碼
• error.exception：Exception異常對象
• error.message：錯誤信息

其中，error.status_code參數就是SendErrorFilter過濾器用來判斷是否需要執行的重要參數。分析到這里，實現異常處理的大致思路就開始明朗了，我們可以參考RibbonRoutingFilter的實現對ThrowExceptionFilter的run方法做一些異常處理的改造，具體如下：

public Object run() { 
    log.info("This is a pre filter, it will throw a RuntimeException"); 
    RequestContext ctx = RequestContext.getCurrentContext(); 
    try { 
        doSomething(); 
    } catch (Exception e) { 
        ctx.set("error.status_code", HttpServletResponse.SC_INTERNAL_SERVER_ERROR); 
        ctx.set("error.exception", e); 
    } 
     return null; 
} 

通過上面的改造之后，我們再嘗試訪問之前的接口，這個時候我們可以得到如下響應內容：

{ 
    "timestamp": 1481674980376, 
    "status": 500, 
    "error": "Internal Server Error", 
    "exception": "java.lang.RuntimeException", 
    "message": "Exist some errors..." 
} 

此時，我們的異常信息已經被SendErrorFilter過濾器正常處理并返回給客戶端了，同時在網關的控制臺中也輸出了異常信息。從返回的響應信息中，我們可以看到幾個我們之前設置在請求上下文中的內容，它們的對應關系如下：

• status：對應error.status_code參數的值
• exception：對應error.exception參數中Exception的類型
• message：對應error.exception參數中Exception的message信息。對于message的信息，我們在過濾器中還可以通過ctx.set("error.message", "自定義異常消息");來定義更友好的錯誤信息。SendErrorFilter會優先取error.message來作為返回的message內容，如果沒有的話才會使用Exception中的message信息

解決方案二：ErrorFilter處理

通過上面的分析與實驗，我們已經知道如何在過濾器中正確的處理異常，讓錯誤信息能夠順利地流轉到后續的SendErrorFilter過濾器來組織和輸出。但是，即使我們不斷強調要在過濾器中使用try-catch來處理業務邏輯并往請求上下文添加異常信息，但是不可控的人為因素、意料之外的程序因素等，依然會使得一些異常從過濾器中拋出，對于意外拋出的異常又會導致沒有控制臺輸出也沒有任何響應信息的情況出現，那么是否有什么好的方法來為這些異常做一個統一的處理呢?

這個時候，我們就可以用到error類型的過濾器了。由于在請求生命周期的pre、route、post三個階段中有異常拋出的時候都會進入error階段的處理，所以我們可以通過創建一個error類型的過濾器來捕獲這些異常信息，并根據這些異常信息在請求上下文中注入需要返回給客戶端的錯誤描述，這里我們可以直接沿用在try-catch處理異常信息時用的那些error參數，這樣就可以讓這些信息被SendErrorFilter捕獲并組織成消息響應返回給客戶端。比如，下面的代碼就實現了這里所描述的一個過濾器：

public class ErrorFilter extends ZuulFilter { 
    Logger log = LoggerFactory.getLogger(ErrorFilter.class); 
    @Override 
    public String filterType() { 
        return "error"; 
    } 
    @Override 
    public int filterOrder() { 
        return 10; 
    } 
    @Override 
    public boolean shouldFilter() { 
        return true; 
    } 
    @Override 
    public Object run() { 
        RequestContext ctx = RequestContext.getCurrentContext(); 
        Throwable throwable = ctx.getThrowable(); 
        log.error("this is a ErrorFilter : {}", throwable.getCause().getMessage()); 
        ctx.set("error.status_code", HttpServletResponse.SC_INTERNAL_SERVER_ERROR); 
        ctx.set("error.exception", throwable.getCause()); 
        return null; 
    } 
} 

在將該過濾器加入到我們的API網關服務之后，我們可以嘗試使用之前介紹try-catch處理時實現的ThrowExceptionFilter(不包含異常處理機制的代碼)，讓該過濾器能夠拋出異常。這個時候我們再通過API網關來訪問服務接口。此時，我們就可以在控制臺中看到ThrowExceptionFilter過濾器拋出的異常信息，并且請求響應中也能獲得如下的錯誤信息內容，而不是什么信息都沒有的情況了。

{ 
    "timestamp": 1481674993561, 
    "status": 500, 
    "error": "Internal Server Error", 
    "exception": "java.lang.RuntimeException", 
    "message": "Exist some errors..." 
} 

【本文為51CTO專欄作者“翟永超”的原創稿件，轉載請通過51CTO聯系作者獲取授權】

戳這里，看該作者更多好文