深刻理解 Spring Cloud 核心組件與底層原理

• 1、Spring Cloud核心組件：Eureka
• Netflix Eureka
• Eureka詳解
• 一、服務提供者
• 二、服務消費者
• 三、服務註冊中心
• 2、Spring Cloud核心組件：Ribbon
• 3、Spring Cloud核心組件：Feign
• 4、Spring Cloud核心組件：Hystrix
• 5、Spring Cloud核心組件：Zuul
• 6、總結

---

以前一直在看 Spring Cloud 及微服務架構 對 Spring Cloud 的主要組件的原理有了更深刻一點的理解，特意作一下總結。

1、Spring Cloud核心組件：Eureka

Netflix Eureka

一、Eureka服務端： 也稱服務註冊中心，同其餘服務註冊中心同樣，支持高可用配置。若是Eureka以集羣模式部署，當集羣中有分片出現故障時，那麼Eureka就轉入自我保護模式。它容許在分片故障期間繼續提供服務的發現和註冊，當故障分片恢復運行時，集羣中其餘分片會把它們的狀態再次同步回來

二、Eureka客戶端： 主要處理服務的註冊與發現。客戶端服務經過註解和參數配置的方式，嵌入在客戶端應用程序的代碼中，在應用程序運行時，Eureka客戶端想註冊中心註冊自身提供的服務並週期性地發送心跳來更新它的服務租約。同時，它也能從服務端查詢當前註冊的服務信息並把它們緩存到本地並週期性地刷新服務狀態

三、Eureka Server 的高可用實際上就是將本身做爲服務向其餘註冊中心註冊本身，這樣就能夠造成一組互相註冊的服務註冊中心，以實現服務清單的互相同步，達到高可用效果

Eureka詳解

一、服務提供者

A.服務註冊

服務提供者在啓動的時候會經過發送REST請求的方式將本身註冊到Eureka Server上，同時帶上了本身服務的一些元數據信息。Eureka Server接收到這個REST請求以後，將元數據信息存儲在一個雙層結構Map中，其中第一層的key是服務名，第二層的key是具體服務的實例名

B.服務同步

兩個服務提供者分別註冊到了兩個不一樣的服務註冊中心上，也就是說，它們的信息分別被兩個服務註冊中心所維護。此時，因爲服務註冊中心之間因互相註冊爲服務，當服務提供者發送註冊請求到一個服務註冊中心時，它會將該請求轉發給集羣中相連的其餘註冊中心，從而實現註冊中心之間的服務同步。經過服務同步，兩個服務提供者的服務信息就能夠經過這兩臺服務註冊中心中的任意一臺獲取到

C.服務續約

在註冊完服務以後，服務提供者會維護一個心跳用來持續告訴Eureka Server：「我還活着」，以防止Eureka Server的剔除任務將該服務實例從服務列表中排除出去，咱們稱該操做爲服務續約

# 定義服務續約任務的調用間隔時間，默認30秒eureka.instance.lease-renewal-interval-in-seconds=30# 定義服務失效的時間，默認90秒eureka.instance.lease-expiration-duration-in-seconds=90 

二、服務消費者

A.獲取服務

當咱們啓動服務消費者的時候，它會發送一個REST請求給服務註冊中心，來獲取上面註冊的服務清單。爲了性能考慮，Eureka Server會維護一份只讀的服務清單來返回給客戶端，同時該緩存清單會每隔30秒更新一次

# 緩存清單的更新時間，默認30秒eureka.client.registry-fetch-interval-seconds=30 

B.服務調用

服務消費者在獲取服務清單後，經過服務名能夠得到具體提供服務的實例名和該實例的元數據信息。在Ribbon中會默認採用輪詢的方式進行調用，從而實現客戶端的負載均衡

對於訪問實例的選擇，Eureka中有Region和Zone的概念，一個Region中能夠包含多個Zone，每一個服務客戶端須要被註冊到一個Zone中，因此每一個客戶端對應一個Region和一個Zone。在進行服務調用的時候，優先訪問同處一個一個Zone中的服務提供方，若訪問不到，就訪問其餘的Zone

C.服務下線

當服務實例進行正常的關閉操做時，它會觸發一個服務下線的REST請求給EurekaServer，告訴服務註冊中心：「我要下線了」。服務端在接收到請求以後，將該服務狀態置爲下線（DOWN），並把該下線事件傳播出去

三、服務註冊中心

A.失效剔除

Eureka Server在啓動的時候會建立一個定時任務，默認每隔一段時間（默認爲60秒）將當前清單中超時（默認爲90秒）沒有續約的服務剔除出去

B.自我保護

在服務註冊中心的信息面板中出現紅色警告信息：

該警告就是觸發了Eureka Server的自我保護機制。Eureka Server在運行期間，會統計心跳失敗的比例在15分鐘以內是否低於85%，若是出現低於的狀況，Eureka Server會將當前的實例註冊信息保護起來，讓這些實例不會過時，儘量保護這些註冊信息。可是，在這段保護期間內實例若出現問題，那麼客戶端很容易拿到實際已經不存在的服務實例，會出現調用失敗的狀況，因此客戶端必需要有容錯機制，好比可使用請求重試、斷路器等機制

# 關閉保護機制，以確保註冊中心能夠將不用的實例正確剔除（本地調試可使用，線上不推薦）eureka.server.enable-self-preservation=false 

2、Spring Cloud核心組件：Ribbon

Ribbon是一個基於HTTP和TCP的客戶端負載均衡器，它能夠在經過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到服務均衡的做用。當Ribbon和Eureka聯合使用時，Ribbon的服務實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka註冊中心中獲取服務端列表。同時它也會用NIWSDiscoveryPing來取代IPing，它將職責委託給Eureka來去定服務端是否已經啓動

在客戶端負載均衡中，全部客戶端節點都維護着本身要訪問的服務端清單，而這些服務端的清單來自於服務註冊中心（好比Eureka）。在客戶端負載均衡中也須要心跳去維護服務端清單的健康性，只是這個步驟須要與服務註冊中心配合完成。整編：微信公衆號，團隊：uyunku

經過Spring Cloud Ribbon的封裝，咱們在微服務架構中使用客戶端負載均衡調用只須要以下兩步：

一、 服務提供者只須要啓動多個服務實例而且註冊到一個註冊中心或是多個相關聯的服務註冊中心

二、 服務消費者直接經過調用被@LoadBalanced註解修飾過的RestTemplate來實現面向服務的接口調用

3、Spring Cloud核心組件：Feign

Feign的關鍵機制是使用了動態代理

一、 首先，對某個接口定義了@FeignClient註解，Feign就會針對這個接口建立一個動態代理

二、 接着調用接口的時候，本質就是調用Feign建立的動態代理

三、 Feign的動態代理會根據在接口上的@RequestMapping等註解，來動態構造要請求的服務的地址

四、 針對這個地址，發起請求、解析響應

Feign是和Ribbon以及Eureka緊密協做的

一、 首先Ribbon會從Eureka Client裏獲取到對應的服務註冊表，也就知道了全部的服務都部署在了哪些機器上，在監聽哪些端口

二、 而後Ribbon就可使用默認的Round Robin算法，從中選擇一臺機器

三、 Feign就會針對這臺機器，構造併發起請求

4、Spring Cloud核心組件：Hystrix

在微服務架構中，存在着那麼多的服務單元，若一個單元出現故障，就很容易因依賴關係而引起故障的蔓延，最終致使整個系統的癱瘓，這樣的架構相較傳統架構更加不穩定。爲了解決這樣的問題，產生了斷路器等一系列的服務保護機制

在分佈式架構中，當某個服務單元發生故障以後，經過斷路器的故障監控，向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間佔用不釋放，避免了故障在分佈式系統中的蔓延

Hystrix具有服務降級、服務熔斷、線程和信號隔離、請求緩存、請求合併以及服務監控等強大功能

Hystrix使用艙壁模式實現線程池的隔離，它會爲每個依賴服務建立一個獨立的線程池，這樣就算某個依賴服務出現延遲太高的狀況，也只是對該依賴服務的調用產生影響，而不會拖慢其餘的依賴服務

5、Spring Cloud核心組件：Zuul

Spring Cloud Zuul經過與Spring Cloud Eureka進行整合，將自身註冊爲Eureka服務治理下的應用，同時從Eureka中得到了全部其餘微服務的實例信息

對於路由規則的維護，Zuul默認會將經過以服務名做爲ContextPath的方式來建立路由映射

Zuul提供了一套過濾器機制，能夠支持在API網關無附上進行統一調用來對微服務接口作前置過濾，已實現對微服務接口的攔截和校驗。整編：微信公衆號，技術團隊，ID：ku

6、總結

Eureka： 各個服務啓動時，Eureka Client都會將服務註冊到Eureka Server，而且EurekaClient還能夠反過來從Eureka Server拉取註冊表，從而知道其餘服務在哪裏

Ribbon： 服務間發起請求的時候，基於Ribbon作負載均衡，從一個服務的多臺機器中選擇一臺

Feign： 基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求URL地址，發起請求

Hystrix： 發起請求是經過Hystrix的線程池來走的，不一樣的服務走不一樣的線程池，實現了不一樣服務調用的隔離，避免了服務雪崩的問題

Zuul： 若是前端、移動端要調用後端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務

本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分佈式等教程，一共30G，須要本身領取。
傳送門：https://mp.weixin.qq.com/s/igMojff-bbmQ6irCGO3mqA