在前兩篇文章：服務網關(基礎)、服務網關(路由配置)中，我們了解了Spring Cloud Zuul作為網關所具備的最基本功能：路由。本文我們將具體介紹一下Spring Cloud Zuul的另一項核心功能：過濾器。

[[204199]]

過濾器的作用

通過上面所述的兩篇我們，我們已經能夠實現請求的路由功能，所以我們的微服務應用提供的接口就可以通過統一的API網關入口被客戶端訪問到了。但是，每個客戶端用戶請求微服務應用提供的接口時，它們的訪問權限往往都需要有一定的限制，系統并不會將所有的微服務接口都對它們開放。

然而，目前的服務路由并沒有限制權限這樣的功能，所有請求都會被毫無保留地轉發到具體的應用并返回結果，為了實現對客戶端請求的安全校驗和權限控制，最簡單和粗暴的方法就是為每個微服務應用都實現一套用于校驗簽名和鑒別權限的過濾器或攔截器。

不過，這樣的做法并不可取，它會增加日后的系統維護難度，因為同一個系統中的各種校驗邏輯很多情況下都是大致相同或類似的，這樣的實現方式會使得相似的校驗邏輯代碼被分散到了各個微服務中去，冗余代碼的出現是我們不希望看到的。

所以，比較好的做法是將這些校驗邏輯剝離出去，構建出一個獨立的鑒權服務。在完成了剝離之后，有不少開發者會直接在微服務應用中通過調用鑒權服務來實現校驗，但是這樣的做法僅僅只是解決了鑒權邏輯的分離，并沒有在本質上將這部分不屬于業余的邏輯拆分出原有的微服務應用，冗余的攔截器或過濾器依然會存在。

對于這樣的問題，更好的做法是通過前置的網關服務來完成這些非業務性質的校驗。由于網關服務的加入，外部客戶端訪問我們的系統已經有了統一入口，既然這些校驗與具體業務無關，那何不在請求到達的時候就完成校驗和過濾，而不是轉發后再過濾而導致更長的請求延遲。同時，通過在網關中完成校驗和過濾，微服務應用端就可以去除各種復雜的過濾器和攔截器了，這使得微服務應用的接口開發和測試復雜度也得到了相應的降低。

為了在API網關中實現對客戶端請求的校驗，我們將需要使用到Spring Cloud Zuul的另外一個核心功能：過濾器。

Zuul允許開發者在API網關上通過定義過濾器來實現對請求的攔截與過濾，實現的方法非常簡單，我們只需要繼承ZuulFilter抽象類并實現它定義的四個抽象函數就可以完成對請求的攔截和過濾了。

過濾器的實現

比如下面的代碼，我們定義了一個簡單的Zuul過濾器，它實現了在請求被路由之前檢查HttpServletRequest中是否有accessToken參數，若有就進行路由，若沒有就拒絕訪問，返回401 Unauthorized錯誤。

public class AccessFilterextends ZuulFilter{ 
 
    private static Logger log = LoggerFactory.getLogger(AccessFilter.class); 
 
    @Override 
    publicStringfilterType(){ 
        return "pre"; 
    } 
 
    @Override 
    public int filterOrder(){ 
        return 0; 
    } 
 
    @Override 
    public boolean shouldFilter(){ 
        return true; 
    } 
 
    @Override 
    publicObjectrun(){ 
        RequestContext ctx = RequestContext.getCurrentContext(); 
        HttpServletRequest request = ctx.getRequest(); 
 
        log.info("send {} request to {}", request.getMethod(), request.getRequestURL().toString()); 
 
        Object accessToken = request.getParameter("accessToken"); 
        if(accessToken == null) { 
            log.warn("access token is empty"); 
            ctx.setSendZuulResponse(false); 
            ctx.setResponseStatusCode(401); 
            return null; 
        } 
        log.info("access token ok"); 
        return null; 
    } 
 
} 

在上面實現的過濾器代碼中，我們通過繼承 ZuulFilter抽象類并重寫了下面的四個方法來實現自定義的過濾器。這四個方法分別定義了：

• filterType：過濾器的類型，它決定過濾器在請求的哪個生命周期中執行。這里定義為 pre，代表會在請求被路由之前執行。
• filterOrder：過濾器的執行順序。當請求在一個階段中存在多個過濾器時，需要根據該方法返回的值來依次執行。
• shouldFilter：判斷該過濾器是否需要被執行。這里我們直接返回了 true，因此該過濾器對所有請求都會生效。實際運用中我們可以利用該函數來指定過濾器的有效范圍。
• run：過濾器的具體邏輯。這里我們通過 ctx.setSendZuulResponse(false)令zuul過濾該請求，不對其進行路由，然后通過 ctx.setResponseStatusCode(401)設置了其返回的錯誤碼，當然我們也可以進一步優化我們的返回，比如，通過 ctx.setResponseBody(body)對返回body內容進行編輯等。

在實現了自定義過濾器之后，它并不會直接生效，我們還需要為其創建具體的Bean才能啟動該過濾器，比如，在應用主類中增加如下內容：

@EnableZuulProxy 
@SpringCloudApplication 
public class Application{ 
 
    public static void main(String[] args){ 
        new SpringApplicationBuilder(Application.class).web(true).run(args); 
    } 
 
    @Bean 
    publicAccessFilteraccessFilter(){ 
        return new AccessFilter(); 
    } 
} 

在對 api-gateway服務完成了上面的改造之后，我們可以重新啟動它，并發起下面的請求，對上面定義的過濾器做一個驗證：

• http://localhost:1101/api-a/hello：返回401錯誤
• http://localhost:1101/api-a/hello&accessToken=token：正確路由到 hello-service的 /hello接口，并返回 HelloWorld

到這里，對于Spring Cloud Zuul過濾器的基本功能就以介紹完畢。讀者可以根據自己的需要在服務網關上定義一些與業務無關的通用邏輯實現對請求的過濾和攔截，比如：簽名校驗、權限校驗、請求限流等功能。

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

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