在上篇文章中我們了解了 Spring Cloud Zuul 作為網關所具備的最基本功能：路由（Router），下面我們將關注 Spring Cloud Zuul 的另一核心功能：過濾器（Filter）。
Filter 的作用
我們已經能夠實現請求的路由功能，所以我們的微服務應用提供的接口就可以通過統一的 API 網關入口被客戶端訪問到了。
但是，每個客戶端用戶請求微服務應用提供的接口時，它們的訪問權限往往都需要有一定的限制，系統並不會將所有的微服務接口都對它們開放。然而，目前的服務路由並沒有限制權限這樣的功能，所有請求都會被毫無保留地轉發到具體的應用並返回結果。
為了實現對客戶端請求的安全校驗和權限控制，最簡單和粗暴的方法就是為每個微服務應用都實現一套用於校驗簽名和鑒別權限的過濾器或攔截器。不過，這樣的做法並不可取，它會增加日后的系統維護難度，因為同一個系統中的各種校驗邏輯很多情況下都是大致相同或類似的，這樣的實現方式會使得相似的校驗邏輯代碼被分散到了各個微服務中去，冗余代碼的出現是我們不希望看到的。所以，比較好的做法是將這些校驗邏輯剝離出去，構建出一個獨立的鑒權服務。在完成了剝離之后，有不少開發者會直接在微服務應用中通過調用鑒權服務來實現校驗，但是這樣的做法僅僅只是解決了鑒權邏輯的分離，並沒有在本質上將這部分不屬於業余的邏輯拆分出原有的微服務應用，冗余的攔截器或過濾器依然會存在。
對於這樣的問題，更好的做法是通過前置的網關服務來完成這些非業務性質的校驗。由於網關服務的加入，外部客戶端訪問我們的系統已經有了統一入口，既然這些校驗與具體業務無關，那何不在請求到達的時候就完成校驗和過濾，而不是轉發后再過濾而導致更長的請求延遲。同時，通過在網關中完成校驗和過濾，微服務應用端就可以去除各種復雜的過濾器和攔截器了，這使得微服務應用的接口開發和測試復雜度也得到了相應的降低。
Filter 的生命周期
Filter 的生命周期有 4 個，分別是 “PRE”、“ROUTING”、“POST” 和“ERROR”，整個生命周期可以用下圖來表示
Zuul 大部分功能都是通過過濾器來實現的，這些過濾器類型對應於請求的典型生命周期。
- PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集群中選擇請求的微服務、記錄調試信息等。
- ROUTING：這種過濾器將請求路由到微服務。這種過濾器用於構建發送給微服務的請求，並使用 Apache HttpClient 或 Netfilx Ribbon 請求微服務。
- POST：這種過濾器在路由到微服務以后執行。這種過濾器可用來為響應添加標准的 HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。
- ERROR：在其他階段發生錯誤時執行該過濾器。 除了默認的過濾器類型，Zuul 還允許我們創建自定義的過濾器類型。例如，我們可以定制一種 STATIC 類型的過濾器，直接在 Zuul 中生成響應，而不將請求轉發到后端的微服務。
Zuul 中默認實現的 Filter
| 類型 | 順序 | 過濾器 | 功能 |
|---|---|---|---|
| pre | -3 | ServletDetectionFilter | 標記處理 Servlet 的類型 |
| pre | -2 | Servlet30WrapperFilter | 包裝 HttpServletRequest 請求 |
| pre | -1 | FormBodyWrapperFilter | 包裝請求體 |
| route | 1 | DebugFilter | 標記調試標志 |
| route | 5 | PreDecorationFilter | 處理請求上下文供后續使用 |
| route | 10 | RibbonRoutingFilter | serviceId 請求轉發 |
| route | 100 | SimpleHostRoutingFilter | url 請求轉發 |
| route | 500 | SendForwardFilter | forward 請求轉發 |
| post | 0 | SendErrorFilter | 處理有錯誤的請求響應 |
| post | 1000 | SendResponseFilter | 處理正常的請求響應 |
如何禁用指定的 Filter
可以在 application.yml 中配置需要禁用的 filter，格式為zuul.<SimpleClassName>.<filterType>.disable=true。
比如要禁用org.springframework.cloud.netflix.zuul.filters.post.SendResponseFilter就設置
zuul:
SendResponseFilter:
post:
disable: true
自定義 Filter
首先自定義一個 Filter，繼承 ZuulFilter 抽象類，在 run() 方法中添加具體業務邏輯，具體如下：
1 package com.carry.springcloud; 2
3 import javax.servlet.http.HttpServletRequest; 4
5 import com.netflix.zuul.ZuulFilter; 6 import com.netflix.zuul.context.RequestContext; 7
8 public class MyFilter extends ZuulFilter { 9
10 /**
11 * 過濾器的類型，它決定過濾器在請求的哪個生命周期中執行。 這里定義為pre，代表會在請求被路由之前執行。 12 * 13 * @return
14 */
15 @Override 16 public String filterType() { 17 return "pre"; 18 } 19
20 /**
21 * filter執行順序，通過數字指定。 數字越大，優先級越低。 22 * 23 * @return
24 */
25 @Override 26 public int filterOrder() { 27 return 0; 28 } 29
30 /**
31 * 判斷該過濾器是否需要被執行。這里我們直接返回了true，因此該過濾器對所有請求都會生效。 實際運用中我們可以利用該函數來指定過濾器的有效范圍。 32 * 33 * @return
34 */
35 @Override 36 public boolean shouldFilter() { 37 return true; 38 } 39
40 /**
41 * 過濾器的具體邏輯 42 * 43 * @return
44 */
45 @Override 46 public Object run() { 47 RequestContext ctx = RequestContext.getCurrentContext(); 48 HttpServletRequest request = ctx.getRequest(); 49
50 String token = request.getParameter("token"); 51 if (token == null || token.isEmpty()) { 52 ctx.setSendZuulResponse(false); 53 ctx.setResponseStatusCode(401); 54 ctx.setResponseBody("token is empty"); 55 } 56 return null; 57 } 58 }
在上面實現的過濾器代碼中，我們通過繼承ZuulFilter抽象類並重寫了下面的四個方法來實現自定義的過濾器。這四個方法分別定義了：
filterType()：過濾器的類型，它決定過濾器在請求的哪個生命周期中執行。這里定義為pre，代表會在請求被路由之前執行。filterOrder()：過濾器的執行順序。當請求在一個階段中存在多個過濾器時，需要根據該方法返回的值來依次執行。通過數字指定，數字越大，優先級越低。shouldFilter()：判斷該過濾器是否需要被執行。這里我們直接返回了true，因此該過濾器對所有請求都會生效。實際運用中我們可以利用該函數來指定過濾器的有效范圍。run()：過濾器的具體邏輯。這里我們通過ctx.setSendZuulResponse(false)令 Zuul 過濾該請求，不對其進行路由，然后通過ctx.setResponseStatusCode(401)設置了其返回的錯誤碼，當然我們也可以進一步優化我們的返回，比如，通過ctx.setResponseBody(body)對返回 body 內容進行編輯等。
在實現了自定義過濾器之后，它並不會直接生效，我們還需要為其創建具體的 Bean 才能啟動該過濾器，比如，在應用主類中增加如下內容：
1 package com.carry.springcloud; 2
3 import org.springframework.boot.SpringApplication; 4 import org.springframework.boot.autoconfigure.SpringBootApplication; 5 import org.springframework.cloud.netflix.zuul.EnableZuulProxy; 6 import org.springframework.context.annotation.Bean; 7
8 @EnableZuulProxy 9 @SpringBootApplication 10 public class ServiceApiGatewayApplication { 11
12 public static void main(String[] args) { 13 SpringApplication.run(ServiceApiGatewayApplication.class, args); 14 } 15
16 @Bean 17 public MyFilter myFilter() { 18 return new MyFilter(); 19 } 20 }
重新啟動service-api-gateway，並發起下面的請求，對上面定義的過濾器做一個驗證：
- 訪問 http://localhost:9100/service-consumer-ribbon/getPoducerInfo 返回
token is empty
- 訪問 http://localhost:9100/service-consumer-ribbon/getPoducerInfo?token=123 正確路由到service-consumer-ribbon的
/getPoducerInfo接口
