Spring Cloud Zuul與網關中間件

內容來源：2017年5月6日，SpringCloud 中國社區創始人許進在「Spring Cloud中國社區技術沙龍-北京站」進行《Spring Cloud Zuul與網關中間件》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：1501 | 4分鐘閱讀

嘉賓演講視頻回顧及PPT地址：t.cn/RnP2eZZ

摘要

SpringCloud 中國社區創始人許進在本次演講中爲你們分享本身在Spring Cloud Zuul與網關中間件的一些研發經驗。

網關介紹

API網關提供API全託管服務，豐富的API管理功能，輔助企業管理⼤規模的API，以下降管理成本和安全風險。——來自阿里雲的定義。

包括協議適配、協議轉發、安全策略(WAF)、防刷，流量量、監控日誌。

網關經常使用功能

統一接入：爲各類無線應用提供統一接入服務；

高性能、高併發、高可靠性；

負載均衡，容災切換（異地多活）。

安全防禦：和安所有合做，IP黑名單，URL黑名單；

風防控制，防惡意攻擊等。

協議適配：前端系統（http、http2）後端業務系統（RPC）；

長、短連接支持；

根據前端請求路由至相應的SOA服務並執行，返回結果給前端。

流量管控：服務降級；熔斷；路由（異地多活中的應用）。

上圖是在異地多活中網關的位置。在異地多活中，網關可能須要開發一個filter，它主要是作用戶分片的路由。好比一個用戶在上海幫助北京的朋友下單，應該經過網關路由分片到北京的機房，在北京的機房中把全部服務調用或者數據落地等等所有作完。因此網關在異地多活中也是至關重要的。

Spring Cloud Zuul

SpringCloud Zuul經過與Spring Cloud Eureka進行整合，將自身註冊到Eureka Server中，與Eureka，Ribbon，Hystrix等整合，同時從Eureka中得到了全部其它微服務的實例信息。

首先一個http請求進來以後，必定會通過Zuul的Servlet，也可能會通過Zuul Filter Runner。Runner是統管全部Filter鏈的順序或者數據的交互，Filter Runner主要是管理整個Zuul的生命週期。

用戶請求進來後會有不少信息，經過Request Context的上下文在Zuul的生命週期中進行傳遞。

FilterLoader是當Zuul啓動的時候會從本地或從動態Filter裏的指定目錄將Filter進行裝載。

如圖所示，Zuul除了自定義Filter以外，主要分爲四種Filter類型。一種是「pre」 Filters（易處理Filter），一種是「routing」 Filters，就是服務路由的Filter。還有一種「post」 Filters，以及「error」 Filters。只要任何一個環節或者自定義的Filters出現異常以後，都會帶着Request Context上下文信息直接跳到「error」 Filters。若是所有流程跑完以後都沒有一個error的話，確定會調用到內部服務。

請求轉發

當註解爲@EnableZuulProxy時，測試轉發。經過訪問⽹網關的URL: http://localhost:8041/api-url/sc/order/1

能夠正常地把請求的url轉發到http://localhost:8000/sc/order/2

默認路由規則

說明默認狀況下，Zuul會代理理全部註冊到Eureka Server的微服務，而且Zuul的路由規則以下：

http://ZUUL_HOST:ZUUL_PORT/微服務在Eureka上的serviceId/**

會被轉發到serviceId對應的微服務。

http://localhost:8040/sc-zuul-first-provider/sc/order/2

網關的負載均衡

http://localhost:8040/sc-zuul-first-provider/sc/order/2

經過網關訪問服務提供者，負載均衡打出對應的日誌

爲何要自研網關

1.網關配置實時生效，配置灰度，回滾等。

2.網關的性能，特別是防刷，限流，WAF等。

3.動態Filter，目前Zuul能夠作到動態Filter，Filter配置下發，實時動態Filter。

4.對網關的監控，告警，流量調撥，網關集羣。

5.流程審計，增長Dsboard便捷的操做。

基於Netty的GW架構和Zuul的設計差很少，可是在細節方面好比Filter面的處理方式、基於Netty的高性能網關入口以及Request Context的上下文處理，都有不一樣的地方。

對外的GW最好的方式就是以輕量的client端引入到GW-server中。由於包括服務治理等必定是由服務治理內部的一些服務註冊與發現進行處理，client主要是作一個轉發或者一些簡單功能處理。

這樣作的好處就是，當網關和服務治理框架升級的時候，二者之間的耦合就至關低了，網關隨着版本的迭代能夠自行升級。至於內部的REST服務或RPC服務只是經過client端作一個薄薄的轉發，這樣就能夠作到解耦。

Filter只須要作單一職責。如上圖所示，Filter有一個抽象的接口，當Filter啓動的時候會對數據進行一些處理。還有一個抽象的Filter主要是作一些每一個Filter自己數據的CRUD。

Filter數據的CRUD

每一個Fliter有本身的緩存數據，緩存數據的CRUD經過觀察者模式按key更新。

網關設計原則

1.每一個Filter基於責任鏈，只作專注的一件事。

2.每一個Filter有各自獨立的數據。

3.損耗性能的Filter順序日後放。

4.啓動讀取配置順序，先遠端，若遠端失敗，則讀取本地。

5.集羣網關，要注意數據的diff和灰度。

6. 儘可能作到和服務治理框架解耦，易於接入，易於升級。

我今天的分享就到這裏，謝謝你們！