本文我們將具體介紹一下Spring Cloud Zuul的另一項核心功能：過濾器。
過濾器的作用
通過上面所述的兩篇我們，我們已經能夠實現請求的路由功能，所以我們的微服務應用提供的接口就可以通過統一的API網關入口被客戶端訪問到了。但是，每個客戶端用戶請求微服務應用提供的接口時，它們的訪問權限往往都需要有一定的限制，系統並不會將所有的微服務接口都對它們開放。然而，目前的服務路由並沒有限制權限這樣的功能，所有請求都會被毫無保留地轉發到具體的應用並返回結果，爲了實現對客戶端請求的安全校驗和權限控制，最簡單和粗暴的方法就是爲每個微服務應用都實現一套用於校驗簽名和鑑別權限的過濾器或攔截器。不過，這樣的做法並不可取，它會增加日後的系統維護難度，因爲同一個系統中的各種校驗邏輯很多情況下都是大致相同或類似的，這樣的實現方式會使得相似的校驗邏輯代碼被分散到了各個微服務中去，冗餘代碼的出現是我們不希望看到的。所以，比較好的做法是將這些校驗邏輯剝離出去，構建出一個獨立的鑑權服務。在完成了剝離之後，有不少開發者會直接在微服務應用中通過調用鑑權服務來實現校驗，但是這樣的做法僅僅只是解決了鑑權邏輯的分離，並沒有在本質上將這部分不屬於業餘的邏輯拆分出原有的微服務應用，冗餘的攔截器或過濾器依然會存在。
對於這樣的問題，更好的做法是通過前置的網關服務來完成這些非業務性質的校驗。由於網關服務的加入，外部客戶端訪問我們的系統已經有了統一入口，既然這些校驗與具體業務無關，那何不在請求到達的時候就完成校驗和過濾，而不是轉發後再過濾而導致更長的請求延遲。同時，通過在網關中完成校驗和過濾，微服務應用端就可以去除各種複雜的過濾器和攔截器了，這使得微服務應用的接口開發和測試複雜度也得到了相應的降低。
爲了在API網關中實現對客戶端請求的校驗，我們將需要使用到Spring Cloud Zuul的另外一個核心功能：過濾器。
Zuul允許開發者在API網關上通過定義過濾器來實現對請求的攔截與過濾，實現的方法非常簡單，我們只需要繼承ZuulFilter抽象類並實現它定義的四個抽象函數就可以完成對請求的攔截和過濾了。
過濾器的實現
比如下面的代碼，我們定義了一個簡單的Zuul過濾器，它實現了在請求被路由之前檢查HttpServletRequest中是否有accessToken參數，若有就進行路由，若沒有就拒絕訪問，返回401 Unauthorized錯誤。
public class AccessFilter extends ZuulFilter {
private static Logger log = LoggerFactory.getLogger(AccessFilter.class);
@Override
public String filterType() {
return "pre";
}
@Override
public int filterOrder() {
return 0;
}
@Override
public boolean shouldFilter() {
return true;
}
@Override
public Object run() {
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
public AccessFilter accessFilter() {
return new AccessFilter();
}
}
在對api-gateway服務完成了上面的改造之後，我們可以重新啓動它，併發起下面的請求，對上面定義的過濾器做一個驗證：
http://localhost:1101/api-a/hello：返回401錯誤
http://localhost:1101/api-a/hello&accessToken=token：正確路由到hello-service的/hello接口，並返回Hello World
到這裏，對於Spring Cloud Zuul過濾器的基本功能就以介紹完畢。java B2B2C Springcloud仿淘寶電子商城系統