什麼是Spring Zuul？

這裏是修真院後端小課堂，每篇分享文從

【背景介紹】【知識剖析】【常見問題】【解決方案】【編碼實戰】【擴展思考】【更多討論】【參考文獻】

八個方面深度解析後端知識/技能，本篇分享的是：

【什麼是Spring Zuul？】

 

1.背景介紹
spring cloud簡介

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。

Spring並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

2.知識剖析
（1）Spring Cloud Netflix 簡介

首先Netflix是一家成功實踐微服務架構的互聯網公司，Netflix把它的整個微服務框架棧開源貢獻給了社區。後來，Spring Cloud對Netflix開源組件進一步封裝，方便Spring開發人員構建微服務基礎框架。

Spring Cloud Netflix的功能十分強大，包括Eureka，Ribbon，hystrix，Feign，Zuul等組件，結合到一塊兒，讓服務的調用、路由也變得異常容易。Spring Cloud Netflix做爲Spring的重量級整合框架，使用它也意味着咱們能從Spring獲取到巨大的便利。Spring Cloud的其餘子項目，好比Spring Cloud Stream、Spring Cloud Config等等，都爲微服務的各類需求提供了一站式的解決方案。

 

（2）Spring Cloud Netflix主要組件介紹

其核心組件是用於服務註冊與發現的Eureka：Eureka由多個instance(服務實例)組成，這些服務實例能夠分爲兩種：Eureka Server和Eureka Client。爲了便於理解，咱們將Eureka client再分爲Service Provider和Service Consumer。以下圖所示：

1）Eureka Server：服務的註冊中心，負責維護註冊的服務列表。

2）Service Provider：服務提供方，做爲一個Eureka Client，向Eureka Server作服務註冊、續約和下線等操做，註冊的主要數據包括服務名、機器ip、端口號、域名等等。

3）Service Consumer：服務消費方，做爲一個Eureka Client，向Eureka Server獲取Service Provider的註冊信息，並經過遠程調用與Service Provider進行通訊。

Service Provider和Service Consumer不是嚴格的概念，Service Consumer也能夠隨時向Eureka Server註冊，來讓本身變成一個Service Provider。Spring Cloud針對服務註冊與發現，進行了一層抽象，並提供了三種實現：Eureka、Consul、Zookeeper。目前支持得最好的就是Eureka，其次是Consul，最後是Zookeeper。

 

（3）服務註冊：Service Provider本質上是一個Eureka Client。

它啓動時，會調用服務註冊方法，向Eureka Server註冊本身的信息。Eureka Server會維護一個已註冊服務的列表，這個列表爲一個嵌套的hash map：第一層，application name和對應的服務實例。 第二層，服務實例及其對應的註冊信息，包括IP，端口號等。

當實例狀態發生變化時（如自身檢測認爲Down的時候），也會向Eureka Server更新本身的服務狀態。續約的方式與服務註冊基本一致，會週期性地向Eureka Server發送心跳以續約本身的信息，避免本身的註冊信息被剔除。

 

（4）Service Consumer本質上也是一個Eureka Client（它也會向Eureka Server註冊，只是這個註冊信息可有可無罷了）。

它啓動後，會從Eureka Server上獲取全部實例的註冊信息，包括IP地址、端口等，並緩存到本地。這些信息默認每30秒更新一次。

基於Service Consumer獲取到的服務實例信息，咱們就能夠進行服務調用了。而Spring Cloud也爲Service Consumer提供了豐富的服務調用工具：

1)Ribbon，實現客戶端的負載均衡。

2)Hystrix，斷路器。

3)Feign，RESTful Web Service客戶端，整合了Ribbon和Hystrix。

 

（5）服務調用端熔斷——Hystrix

Netflix建立了一個名爲Hystrix的庫,實現了斷路器的模式。「斷路器」自己是一種開關裝置，當某個服務單元發生故障以後，經過斷路器的故障監控（相似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方沒法處理的異常，這樣就保證了服務調用方的線程不會被長時間、沒必要要地佔用，從而避免了故障在分佈式系統中的蔓延，甚至雪崩。

（6）服務調用端代碼抽象和封裝——Feign

Feign是一個聲明式的Web Service客戶端，它的目的就是讓Web Service調用更加簡單。它整合了Ribbon和Hystrix，從而讓咱們再也不須要顯式地使用這兩個組件。Feign還提供了HTTP請求的模板，經過編寫簡單的接口和插入註解，咱們就能夠定義好HTTP請求的參數、格式、地址等信息。接下來，Feign會徹底代理HTTP的請求，咱們只須要像調用方法同樣調用它就能夠完成服務請求。

3.常見問題
（1）Spring Cloud Netflix的優點?

對於微服務的治理而言，核心就是服務的註冊和發現。所以選擇哪一個組件，很大程度上要看它對於服務註冊與發現的解決方案。在這個領域，開源架構不少，最多見的是Zookeeper，但這並非惟一選擇。

在分佈式系統領域有個著名的CAP定理：C—數據一致性，A—服務可用性，P—服務對網絡分區故障的容錯性。這三個特性在任何分佈式系統中不能同時知足，最多同時知足兩個。

Zookeeper保證的是CP，即它不能保證每次服務請求的可用性。對於大多數涉及到數據存儲的分佈式環境，數據一致性應該是首先被保證的。可是對於服務發現而言，可用性比數據一致性更加劇要，即AP賽過CP。而Spring Cloud Netflix在設計Eureka時遵照的就是AP原則。

 

（2）實際開發Eureka的過程當中，有時會碰見Service Consumer獲取到Server Provider的信息有延遲？

Eureka官網提到服務端的更改可能須要2分鐘才能傳播到全部客戶端。這是由於Eureka有三處緩存和一處延遲形成的。

1）Eureka Server對註冊列表進行緩存，默認時間爲30s。

2）Eureka Client對獲取到的註冊信息進行緩存，默認時間爲30s。

3）Ribbon會從上面提到的Eureka Client獲取服務列表，將負載均衡後的結果緩存30s。

4）若是不是在Spring Cloud環境下使用這些組件(Eureka, Ribbon)，服務啓動後並不會立刻向Eureka註冊，而是須要等到第一次發送心跳請求時纔會註冊。心跳請求的發送間隔默認是30s。Spring Cloud對此作了修改，服務啓動後會立刻註冊。

 

（3）Feign具備以下特性：

可插拔的註解支持，包括Feign註解和JAX-RS註解

支持可插拔的HTTP編碼器和解碼器

支持Hystrix和它的Fallback

支持Ribbon的負載均衡

支持HTTP請求和響應的壓縮

 

（4）服務器端負載均衡和客戶端負載均衡的區別？

1）服務器端負載均衡：例如Nginx，經過Nginx進行負載均衡，先發送請求，而後經過負載均衡算法，在多個服務器之間選擇一個進行訪問；即在服務器端再進行負載均衡算法分配。

2）客戶端負載均衡：例如spring cloud中的ribbon，客戶端會有一個服務器地址列表，在發送請求前經過負載均衡算法選擇一個服務器，而後進行訪問，這是客戶端負載均衡；即在客戶端就進行負載均衡算法分配。