在前兩篇文章：服務網(wǎng)關（基礎）身冀、服務網(wǎng)關（路由配置）中，我們了解了Spring Cloud Zuul作為網(wǎng)關所具備的最基本功能：路由括享。本文我們將具體介紹一下Spring Cloud Zuul的另一項核心功能：過濾器搂根。
過濾器的作用
通過上面所述的兩篇我們，我們已經(jīng)能夠?qū)崿F(xiàn)請求的路由功能铃辖，所以我們的微服務應用提供的接口就可以通過統(tǒng)一的API網(wǎng)關入口被客戶端訪問到了剩愧。但是，每個客戶端用戶請求微服務應用提供的接口時娇斩，它們的訪問權限往往都需要有一定的限制仁卷，系統(tǒng)并不會將所有的微服務接口都對它們開放穴翩。然而，目前的服務路由并沒有限制權限這樣的功能锦积，所有請求都會被毫無保留地轉(zhuǎn)發(fā)到具體的應用并返回結果芒帕，為了實現(xiàn)對客戶端請求的安全校驗和權限控制，最簡單和粗暴的方法就是為每個微服務應用都實現(xiàn)一套用于校驗簽名和鑒別權限的過濾器或攔截器丰介。不過背蟆，這樣的做法并不可取，它會增加日后的系統(tǒng)維護難度哮幢，因為同一個系統(tǒng)中的各種校驗邏輯很多情況下都是大致相同或類似的淆储，這樣的實現(xiàn)方式會使得相似的校驗邏輯代碼被分散到了各個微服務中去，冗余代碼的出現(xiàn)是我們不希望看到的家浇。所以本砰，比較好的做法是將這些校驗邏輯剝離出去，構建出一個獨立的鑒權服務钢悲。在完成了剝離之后点额，有不少開發(fā)者會直接在微服務應用中通過調(diào)用鑒權服務來實現(xiàn)校驗，但是這樣的做法僅僅只是解決了鑒權邏輯的分離莺琳，并沒有在本質(zhì)上將這部分不屬于業(yè)余的邏輯拆分出原有的微服務應用还棱，冗余的攔截器或過濾器依然會存在。
對于這樣的問題惭等，更好的做法是通過前置的網(wǎng)關服務來完成這些非業(yè)務性質(zhì)的校驗珍手。由于網(wǎng)關服務的加入，外部客戶端訪問我們的系統(tǒng)已經(jīng)有了統(tǒng)一入口辞做，既然這些校驗與具體業(yè)務無關琳要，那何不在請求到達的時候就完成校驗和過濾，而不是轉(zhuǎn)發(fā)后再過濾而導致更長的請求延遲秤茅。同時稚补，通過在網(wǎng)關中完成校驗和過濾，微服務應用端就可以去除各種復雜的過濾器和攔截器了框喳，這使得微服務應用的接口開發(fā)和測試復雜度也得到了相應的降低课幕。
為了在API網(wǎng)關中實現(xiàn)對客戶端請求的校驗，我們將需要使用到Spring Cloud Zuul的另外一個核心功能：過濾器五垮。
Zuul允許開發(fā)者在API網(wǎng)關上通過定義過濾器來實現(xiàn)對請求的攔截與過濾乍惊，實現(xiàn)的方法非常簡單，我們只需要繼承ZuulFilter抽象類并實現(xiàn)它定義的四個抽象函數(shù)就可以完成對請求的攔截和過濾了放仗。
過濾器的實現(xiàn)
比如下面的代碼润绎，我們定義了一個簡單的Zuul過濾器，它實現(xiàn)了在請求被路由之前檢查HttpServletRequest中是否有accessToken參數(shù)，若有就進行路由凡橱，若沒有就拒絕訪問小作，返回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;
}
}
在上面實現(xiàn)的過濾器代碼中稼钩，我們通過繼承ZuulFilter抽象類并重寫了下面的四個方法來實現(xiàn)自定義的過濾器顾稀。這四個方法分別定義了：
-
filterType：過濾器的類型，它決定過濾器在請求的哪個生命周期中執(zhí)行坝撑。這里定義為pre静秆，代表會在請求被路由之前執(zhí)行。 -
filterOrder：過濾器的執(zhí)行順序巡李。當請求在一個階段中存在多個過濾器時抚笔，需要根據(jù)該方法返回的值來依次執(zhí)行。 -
shouldFilter：判斷該過濾器是否需要被執(zhí)行侨拦。這里我們直接返回了true殊橙，因此該過濾器對所有請求都會生效。實際運用中我們可以利用該函數(shù)來指定過濾器的有效范圍狱从。 -
run：過濾器的具體邏輯膨蛮。這里我們通過ctx.setSendZuulResponse(false)令zuul過濾該請求，不對其進行路由季研，然后通過ctx.setResponseStatusCode(401)設置了其返回的錯誤碼敞葛，當然我們也可以進一步優(yōu)化我們的返回，比如与涡，通過ctx.setResponseBody(body)對返回body內(nèi)容進行編輯等惹谐。
在實現(xiàn)了自定義過濾器之后，它并不會直接生效驼卖，我們還需要為其創(chuàng)建具體的Bean才能啟動該過濾器氨肌，比如，在應用主類中增加如下內(nèi)容：
@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服務完成了上面的改造之后款慨，我們可以重新啟動它儒飒，并發(fā)起下面的請求，對上面定義的過濾器做一個驗證：
-
http://localhost:1101/api-a/hello：返回401錯誤 -
http://localhost:1101/api-a/hello&accessToken=token：正確路由到hello-service的/hello接口檩奠，并返回Hello World
到這里，對于Spring Cloud Zuul過濾器的基本功能就以介紹完畢附帽。讀者可以根據(jù)自己的需要在服務網(wǎng)關上定義一些與業(yè)務無關的通用邏輯實現(xiàn)對請求的過濾和攔截埠戳，比如：簽名校驗、權限校驗蕉扮、請求限流等功能整胃。
進階閱讀
為了更好的理解和擴展Spring Cloud Zuul，我們可以閱讀下面這些文章喳钟，有助于深入的了解其內(nèi)部運行機制屁使，以指導我們合理的編寫過濾器邏輯：
