SpringCloud路由網關Zuul與Ribbon

Zuul淺談

角色功能：

Zuul是netflix開源的一個API Gateway 服務器, 本質上是一個web servlet應用。

ZuulServlet相似SpringMvc的DispatcherServlet，全部的Request都要通過ZuulServlet的處理。做爲一個邊界性質的應用程序，Zuul提供了動態路由、監控、彈性負載和安全功能。Zuul底層利用各類filter實現以下功能：

• 認證和安全 識別每一個須要認證的資源，拒毫不符合要求的請求。
• 性能監測 在服務邊界追蹤並統計數據，提供精確的生產視圖。
• 動態路由 根據須要將請求動態路由到後端集羣。
• 壓力測試 逐漸增長對集羣的流量以瞭解其性能。
• 負載卸載 預先爲每種類型的請求分配容量，當請求超過容量時自動丟棄。
• 靜態資源處理 直接在邊界返回某些響應。

Zuul的核心是一系列的filters，

這些Filter在整個HTTP請求過程當中執行一連串的操做。 

Zuul提供了一個框架，能夠對過濾器進行動態的加載，編譯，運行。過濾器之間沒有直接的相互通訊。他們是經過一個RequestContext的靜態類來進行數據傳遞的。RequestContext類中有ThreadLocal變量來記錄每一個Request所須要傳遞的數據。

Zuul中定義了四種標準過濾器類型，這些過濾器類型對應於請求的典型生命週期，分別是「PRE」、「ROUTING」、「POST」、「ERROR」，整個生命週期能夠用下圖來表示。

• PRE： 這種過濾器在請求被路由以前調用。咱們可利用這種過濾器實現身份驗證、在集羣中選擇請求的微服務、記錄調試信息等。
• ROUTING：這種過濾器將請求路由到微服務。這種過濾器用於構建發送給微服務的請求，並使用Apache HttpClient或Netfilx Ribbon請求微服務。
• POST：這種過濾器在路由到微服務之後執行。這種過濾器可用來爲響應添加標準的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。
• ERROR：在其餘階段發生錯誤時執行該過濾器。 除了默認的過濾器類型，Zuul還容許咱們建立自定義的過濾器類型。例如，咱們能夠定製一種STATIC類型的過濾器，直接在Zuul中生成響應，而不將請求轉發到後端的微服務。
  

自定義Filter：

某些場景下，咱們須要自定義Filter時，只須要繼承ZuulFilter，並重寫裏面的方法就能夠了

Ribbon淺談

負載均衡的實現方式：

• 服務端負載均衡：當瀏覽器向後臺發出請求的時候，會首先向反向代理服務器發送請求，反向代理服務器會根據客戶端部署的ip：port映射表以及負載均衡策略，來決定向哪臺服務器發送請求，通常會使用到nginx反向代理技術。
• 客戶端負載均衡：當瀏覽器向後臺發出請求的時候，客戶端會向服務註冊器(例如：Eureka Server)，拉取註冊到服務器的可用服務信息，而後根據負載均衡策略，直接命中哪臺服務器發送請求。這整個過程都是在客戶端完成的，並不須要反向代理服務器的參與。
  

Spring Cloud Ribbon 是一個基於Http和TCP的客服端負載均衡工具，它是基於Netflix Ribbon實現。Ribbon不須要獨立部署，但它幾乎存在於每一個微服務的基礎設施中。Ribbon 能夠經過在客戶端中配置ribbonServerList來設置服務端列表去輪詢訪問以達到均衡負載的做用。

當Ribbon與Eureka聯合使用時，ribbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka註冊中心中獲取服務實例列表。同時它也會用NIWSDiscoveryPing來取代IPing，它將職責委託給Eureka來肯定服務端是否已經啓動。

當Ribbon與Consul聯合使用時，ribbonServerList會被ConsulServerList來擴展成從Consul獲取服務實例列表。同時由ConsulPing來做爲IPing接口的實現。

咱們在使用Spring Cloud Ribbon的時候，不管是與Eureka仍是Consul結合，都會在引入Spring Cloud Eureka或Spring Cloud Consul依賴的時候經過自動化配置來加載上述所說的配置內容，因此咱們能夠快速在Spring Cloud中實現服務間調用的負載均衡。

下面咱們實現Ribbon示例。

輪詢策略：

• BestAvailableRule:最大可用策略，即先過濾出故障服務器後，選擇一個當前併發請求數最小的；
• AvailabilityFilteringRule:可用過濾策略，先過濾出故障的或併發請求大於閾值一部分服務實例，而後再以線性輪詢的方式從過濾後的實例清單中選出一個；
• RoundRobinRule:輪詢策略，Ribbon以輪詢的方式選擇服務器，這個是默認值。因此示例中所啓動的兩個服務會被循環訪問；
• RandomRule:隨機選擇，也就是說Ribbon會隨機從服務器列表中選擇一個進行訪問；
• WeightedResponseTimeRule:帶有加權的輪詢策略，對各個服務器響應時間進行加權處理，而後在採用輪詢的方式來獲取相應的服務器；
• RetryRule：對選定的負載均衡策略機上重試機制，在一個配置時間段內當選擇server不成功，則一直嘗試使用subRule的方式選擇一個可用的server；
• ZoneAvoidanceRule:區域感知策略，先使用主過濾條件（區域負載器，選擇最優區域）對全部實例過濾並返回過濾後的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數（默認1）和最小過濾百分比（默認0），最後對知足條件的服務器則使用RoundRobinRule(輪詢方式)選擇一個服務器實例。