Spring Cloud(十一):服務網關 Zuul(過濾器)【Finchley 版】
在上篇文章中我們了解了 Spring Cloud Zuul 作為網關所具備的最基本功能:路由(Router)。本文我們將關注 Spring Cloud Zuul 的另一核心功能:過濾器(Filter)。
Filter 的作用
我們已經能夠實現請求的路由功能,所以我們的微服務應用提供的接口就可以通過統一的 API 網關入口被客戶端訪問到了。
但是,每個客戶端用戶請求微服務應用提供的接口時,它們的訪問權限往往都需要有一定的限制,系統並不會將所有的微服務接口都對它們開放。然而,目前的服務路由並沒有限制權限這樣的功能,所有請求都會被毫無保留地轉發到具體的應用並返回結果。
為了實現對客戶端請求的安全校驗和權限控制,最簡單和粗暴的方法就是為每個微服務應用都實現一套用於校驗簽名和鑒別權限的過濾器或攔截器。不過,這樣的做法並不可取,它會增加日后的系統維護難度,因為同一個系統中的各種校驗邏輯很多情況下都是大致相同或類似的,這樣的實現方式會使得相似的校驗邏輯代碼被分散到了各個微服務中去,冗余代碼的出現是我們不希望看到的。所以,比較好的做法是將這些校驗邏輯剝離出去,構建出一個獨立的鑒權服務。在完成了剝離之后,有不少開發者會直接在微服務應用中通過調用鑒權服務來實現校驗,但是這樣的做法僅僅只是解決了鑒權邏輯的分離,並沒有在本質上將這部分不屬於業余的邏輯拆分出原有的微服務應用,冗余的攔截器或過濾器依然會存在。
對於這樣的問題,更好的做法是通過前置的網關服務來完成這些非業務性質的校驗。由於網關服務的加入,外部客戶端訪問我們的系統已經有了統一入口,既然這些校驗與具體業務無關,那何不在請求到達的時候就完成校驗和過濾,而不是轉發后再過濾而導致更長的請求延遲。同時,通過在網關中完成校驗和過濾,微服務應用端就可以去除各種復雜的過濾器和攔截器了,這使得微服務應用的接口開發和測試復雜度也得到了相應的降低。
為了在 API 網關中實現對客戶端請求的校驗,我們將需要使用到 Spring Cloud Zuul 的另外一個核心功能:過濾器。
Zuul 允許開發者在 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
就設置
1 |
zuul: |
自定義 Filter
我們假設有這樣一個場景,因為服務網關應對的是外部的所有請求,為了避免產生安全隱患,我們需要對請求做一定的限制,比如請求中含有 Token 便讓請求繼續往下走,如果請求不帶 Token 就直接返回並給出提示。
首先自定義一個 Filter,繼承 ZuulFilter 抽象類,在 run() 方法中驗證參數是否含有 Token,具體如下:
1 |
public class TokenFilter extends ZuulFilter { |
在上面實現的過濾器代碼中,我們通過繼承ZuulFilter
抽象類並重寫了下面的四個方法來實現自定義的過濾器。這四個方法分別定義了:
filterType()
:過濾器的類型,它決定過濾器在請求的哪個生命周期中執行。這里定義為pre
,代表會在請求被路由之前執行。filterOrder()
:過濾器的執行順序。當請求在一個階段中存在多個過濾器時,需要根據該方法返回的值來依次執行。通過數字指定,數字越大,優先級越低。shouldFilter()
:判斷該過濾器是否需要被執行。這里我們直接返回了true
,因此該過濾器對所有請求都會生效。實際運用中我們可以利用該函數來指定過濾器的有效范圍。run()
:過濾器的具體邏輯。這里我們通過ctx.setSendZuulResponse(false)
令 Zuul 過濾該請求,不對其進行路由,然后通過ctx.setResponseStatusCode(401)
設置了其返回的錯誤碼,當然我們也可以進一步優化我們的返回,比如,通過ctx.setResponseBody(body)
對返回 body 內容進行編輯等。
在實現了自定義過濾器之后,它並不會直接生效,我們還需要為其創建具體的 Bean 才能啟動該過濾器,比如,在應用主類中增加如下內容:
1 |
|
在對api-gateway
服務完成了上面的改造之后,我們可以重新啟動它,並發起下面的請求,對上面定義的過濾器做一個驗證:
- 訪問 http://localhost:14000/consumer/hello/windmt 返回 401 錯誤和
token is empty
- 訪問 http://localhost:14000/consumer/hello/windmt?token=token 正確路由到
consumer
的/hello
接口,並返回Hello, windmt
我們可以根據自己的需要在服務網關上定義一些與業務無關的通用邏輯實現對請求的過濾和攔截,比如:簽名校驗、權限校驗、請求限流等功能。
相關閱讀
Spring Cloud(一):服務治理技術概覽
Spring Cloud(二):服務注冊與發現 Eureka
Spring Cloud(三):服務提供與調用 Eureka
Spring Cloud(四):服務容錯保護 Hystrix
Spring Cloud(五):Hystrix 監控面板
Spring Cloud(六):Hystrix 監控數據聚合 Turbine
Spring Cloud(七):配置中心(Git 版與動態刷新)
Spring Cloud(八):配置中心(服務化與高可用)
Spring Cloud(九):配置中心(消息總線)
Spring Cloud(十):服務網關 Zuul(路由)
Spring Cloud(十一):服務網關 Zuul(過濾器)
Spring Cloud(十二):分布式鏈路跟蹤(Sleuth 與 Zipkin)
示例代碼:GitHub
參考
Spring Cloud - Router and Filter: Zuul
springcloud(十一):服務網關 Zuul 高級篇
Spring Cloud 構建微服務架構:服務網關(過濾器)【Dalston 版】
- 本文鏈接: https://windmt.com/2018/04/23/spring-cloud-11-zuul-filter/
- 版權聲明: 本博客所有文章除特別聲明外,均采用 CC BY-NC-SA 4.0 許可協議。轉載請注明出處!