服務閘道器過濾器

過濾器作用

我們的微服務應用提供的介面就可以透過統一的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();
}
}

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

從現在開始，我這邊會將近期研發的 springcloud 微服務雲架構的搭建過程和精髓記錄下來，幫助更多有興趣研發 spring cloud 框架的朋友， 希望可以幫助更多的好學者。大家來一起探討 spring cloud 架構的搭建過程及如何運用於企業專案。