本篇作為《Spring Cloud微服務實戰》一書關于Spring Cloud Zuul網關在Dalston版本對異常處理的補充。沒有看過本書的讀書也不要緊，可以先閱讀我之前的兩篇博文：《Spring Cloud實戰小貼士：Zuul統一異常處理(一)》和《Spring Cloud實戰小貼士：Zuul統一異常處理(二)》，這兩篇文章都詳細介紹和分析了Spring Cloud Zuul在過濾器設計中對異常處理的不足。同時，在這兩篇文章中，也針對不足之處做了相應的解決方案。不過，這些方案都是基于Brixton版本所做的，在***的Dalston版本中，Spring Cloud Zuul做了一些優化，所以我們不再需要做這些擴展就已經能夠正確的處理異常信息了。那么，在Dalston版中，Spring Cloud Zuul中做了怎么樣的修改以達到之前我們自己擴展的效果呢?

過濾器類型的變更

讀者是否還記得我們之前分析了Spring Cloud Zuul自帶的核心過濾器有哪些呢?我們先根據下圖回憶一下：

這次主要將SendErrorFilter過濾器的類型從POST改為了ERROR，所以核心過濾器變成了如下圖的結構：

處理邏輯的變化

既然過濾器類型發生了變化，那么請求的處理生命周期就會有所變化。在變化之前，各階段過濾器的流轉如下圖所示：

針對異常情況，在圖中我們標出了不同的顏色。從pre和route階段拋出的異常將會進入error階段，再進入到post階段進行返回。由于SendErrorFilter需要判斷請求上下文中是否包含error.status_code屬性：有的話就用SendErrorFilter處理錯誤結果;沒有的話就用SendResponseFilter返回正常結果，但是error.status_code屬性默認是在各個階段過濾器中自己put進去的，這就導致，各個階段過濾器拋出異常之后，是沒有辦法返回錯誤結果的。因此，我們擴展了一個ErrorFilter來捕獲異常，然后手工的設置error.status_code屬性，讓SendErrorFilter能正常運作。

通過上面你的改造，從pre和route階段的異常都能處理了，但是post階段拋出異常后，是不會再進入post階段的，這使得ErrorFilter設置了設置error.status_code屬性之后，也沒有過濾器去組織返回結果，所以我們通過繼承SendErrorFilter在error階段增加了一個返回錯誤信息的過濾器。

而這次在Dalston版本中，做了很巧妙的變動：就是上文所述的對SendErrorFilter過濾器類型的變更，這一變動使得所有階段的異常都會被SendErrorFilter處理，直接解決的上面的第二個問題。當然只是做個變動還是不夠的，為了區分SendErrorFilter和SendResponseFitler分別處理出現異常和未出現異常的情況，修改原來根據error.status_code屬性判斷的邏輯，而是改為根據請求上下文中是否包含Throwable來作為基本依據，而這個對象是在過濾器出現異常之后，Zuul往請求上下文中置入的，所以可以更為準確的判斷當前請求處理是否出現了異常，而不再需要我們之前擴展的ErrorFilter了。

public class SendErrorFilter extends ZuulFilter {    
    @Override 
    public boolean shouldFilter() { 
        RequestContext ctx = RequestContext.getCurrentContext(); 
        return ctx.containsKey("error.status_code") 
                && !ctx.getBoolean(SEND_ERROR_FILTER_RAN, false); 
    } 
    ... 
} 
public class SendResponseFilter extends ZuulFilter { 
    @Override 
    public boolean shouldFilter() { 
        RequestContext context = RequestContext.getCurrentContext(); 
        return context.getThrowable() == null 
            && (!context.getZuulResponseHeaders().isEmpty() 
                || context.getResponseDataStream() != null 
                || context.getResponseBody() != null); 
    } 
    ... 
} 

所以，***修改之后，整個處理邏輯變為如下圖所示的流程：

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

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