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

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

一、Spring Cloud核心組件：Eureka

Netflix Eureka

1、Eureka 服務端： 也稱服務注冊中心，同其他服務注冊中心一樣，支持高可用配置。如果Eureka以集群模式部署，當集群中有分片出現(xiàn)故障時，那么Eureka就轉(zhuǎn)入自我保護模式。

它允許在分片故障期間繼續(xù)提供服務的發(fā)現(xiàn)和注冊，當故障分片恢復運行時，集群中其他分片會把它們的狀態(tài)再次同步回來

2、Eureka 客戶端： 主要處理服務的注冊與發(fā)現(xiàn)?？蛻舳朔胀ㄟ^注解和參數(shù)配置的方式，嵌入在客戶端應用程序的代碼中

在應用程序運行時，Eureka客戶端想注冊中心注冊自身提供的服務并周期性地發(fā)送心跳來更新它的服務租約。同時，它也能從服務端查詢當前注冊的服務信息并把它們緩存到本地并周期性地刷新服務狀態(tài)

3、Eureka Server 的高可用實際上就是將自己作為服務向其他注冊中心注冊自己，這樣就可以形成一組互相注冊的服務注冊中心，以實現(xiàn)服務清單的互相同步，達到高可用效果

Eureka詳解

1、服務提供者

A.服務注冊

服務提供者在啟動的時候會通過發(fā)送REST請求的方式將自己注冊到Eureka Server上，同時帶上了自己服務的一些元數(shù)據(jù)信息。

Eureka Server接收到這個REST請求之后，將元數(shù)據(jù)信息存儲在一個雙層結構Map中，其中第一層的key是服務名，第二層的key是具體服務的實例名

B.服務同步

兩個服務提供者分別注冊到了兩個不同的服務注冊中心上，也就是說，它們的信息分別被兩個服務注冊中心所維護。

此時，由于服務注冊中心之間因互相注冊為服務，當服務提供者發(fā)送注冊請求到一個服務注冊中心時，它會將該請求轉(zhuǎn)發(fā)給集群中相連的其他注冊中心，從而實現(xiàn)注冊中心之間的服務同步。

通過服務同步，兩個服務提供者的服務信息就可以通過這兩臺服務注冊中心中的任意一臺獲取到

C.服務續(xù)約

在注冊完服務之后，服務提供者會維護一個心跳用來持續(xù)告訴Eureka Server：“我還活著”，以防止Eureka Server的剔除任務將該服務實例從服務列表中排除出去，我們稱該操作為服務續(xù)約

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

2、服務消費者

A.獲取服務

當我們啟動服務消費者的時候，它會發(fā)送一個REST請求給服務注冊中心，來獲取上面注冊的服務清單。

為了性能考慮，Eureka Server會維護一份只讀的服務清單來返回給客戶端，同時該緩存清單會每隔30秒更新一次

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

B.服務調(diào)用

服務消費者在獲取服務清單后，通過服務名可以獲得具體提供服務的實例名和該實例的元數(shù)據(jù)信息。在Ribbon中會默認采用輪詢的方式進行調(diào)用，從而實現(xiàn)客戶端的負載均衡

對于訪問實例的選擇，Eureka中有Region和Zone的概念，一個Region中可以包含多個Zone，每個服務客戶端需要被注冊到一個Zone中，所以每個客戶端對應一個Region和一個Zone。

在進行服務調(diào)用的時候，優(yōu)先訪問同處一個一個Zone中的服務提供方，若訪問不到，就訪問其他的Zone

C.服務下線

當服務實例進行正常的關閉操作時，它會觸發(fā)一個服務下線的REST請求給EurekaServer，告訴服務注冊中心：“我要下線了”。

服務端在接收到請求之后，將該服務狀態(tài)置為下線（DOWN），并把該下線事件傳播出去

3、服務注冊中心

A.失效剔除

Eureka Server在啟動的時候會創(chuàng)建一個定時任務，默認每隔一段時間（默認為60秒）將當前清單中超時（默認為90秒）沒有續(xù)約的服務剔除出去

B.自我保護

在服務注冊中心的信息面板中出現(xiàn)紅色警告信息：

該警告就是觸發(fā)了Eureka Server的自我保護機制。Eureka Server在運行期間，會統(tǒng)計心跳失敗的比例在15分鐘之內(nèi)是否低于85%，如果出現(xiàn)低于的情況，Eureka Server會將當前的實例注冊信息保護起來，讓這些實例不會過期，盡可能保護這些注冊信息。

但是，在這段保護期間內(nèi)實例若出現(xiàn)問題，那么客戶端很容易拿到實際已經(jīng)不存在的服務實例，會出現(xiàn)調(diào)用失敗的情況，所以客戶端必須要有容錯機制，比如可以使用請求重試、斷路器等機制

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

二、Spring Cloud核心組件：Ribbon

Ribbon是一個基于HTTP和TCP的客戶端負載均衡器，它可以在通過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到服務均衡的作用。

當Ribbon和Eureka聯(lián)合使用時，Ribbon的服務實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka注冊中心中獲取服務端列表。

同時它也會用NIWSDiscoveryPing來取代IPing，它將職責委托給Eureka來去定服務端是否已經(jīng)啟動

在客戶端負載均衡中，所有客戶端節(jié)點都維護著自己要訪問的服務端清單，而這些服務端的清單來自于服務注冊中心（比如Eureka）。

在客戶端負載均衡中也需要心跳去維護服務端清單的健康性，只是這個步驟需要與服務注冊中心配合完成。

通過Spring Cloud Ribbon的封裝，我們在微服務架構中使用客戶端負載均衡調(diào)用只需要如下兩步：

1、 服務提供者只需要啟動多個服務實例并且注冊到一個注冊中心或是多個相關聯(lián)的服務注冊中心

2、 服務消費者直接通過調(diào)用被@LoadBalanced注解修飾過的RestTemplate來實現(xiàn)面向服務的接口調(diào)用

三、Spring Cloud核心組件：Feign

Feign的關鍵機制是使用了動態(tài)代理

1、 首先，對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理

2、 接著調(diào)用接口的時候，本質(zhì)就是調(diào)用Feign創(chuàng)建的動態(tài)代理

3、 Feign的動態(tài)代理會根據(jù)在接口上的@RequestMapping等注解，來動態(tài)構造要請求的服務的地址

4、 針對這個地址，發(fā)起請求、解析響應

Feign是和Ribbon以及Eureka緊密協(xié)作的

1、 首先Ribbon會從Eureka Client里獲取到對應的服務注冊表，也就知道了所有的服務都部署在了哪些機器上，在監(jiān)聽哪些端口

2、 然后Ribbon就可以使用默認的Round Robin算法，從中選擇一臺機器

3、 Feign就會針對這臺機器，構造并發(fā)起請求

四、Spring Cloud核心組件：Hystrix

在微服務架構中，存在著那么多的服務單元，若一個單元出現(xiàn)故障，就很容易因依賴關系而引發(fā)故障的蔓延，最終導致整個系統(tǒng)的癱瘓，這樣的架構相較傳統(tǒng)架構更加不穩(wěn)定。

為了解決這樣的問題，產(chǎn)生了斷路器等一系列的服務保護機制

在分布式架構中，當某個服務單元發(fā)生故障之后，通過斷路器的故障監(jiān)控，向調(diào)用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調(diào)用故障服務被長時間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延

Hystrix具備服務降級、服務熔斷、線程和信號隔離、請求緩存、請求合并以及服務監(jiān)控等強大功能

Hystrix使用艙壁模式實現(xiàn)線程池的隔離，它會為每一個依賴服務創(chuàng)建一個獨立的線程池，這樣就算某個依賴服務出現(xiàn)延遲過高的情況，也只是對該依賴服務的調(diào)用產(chǎn)生影響，而不會拖慢其他的依賴服務

五、Spring Cloud核心組件：Zuul

Spring Cloud Zuul通過與Spring Cloud Eureka進行整合，將自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得了所有其他微服務的實例信息

對于路由規(guī)則的維護，Zuul默認會將通過以服務名作為ContextPath的方式來創(chuàng)建路由映射

Zuul提供了一套過濾器機制，可以支持在API網(wǎng)關無附上進行統(tǒng)一調(diào)用來對微服務接口做前置過濾，已實現(xiàn)對微服務接口的攔截和校驗

六、總結

Eureka： 各個服務啟動時，Eureka Client都會將服務注冊到Eureka Server，并且EurekaClient還可以反過來從Eureka Server拉取注冊表，從而知道其他服務在哪里

Ribbon： 服務間發(fā)起請求的時候，基于Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺

Feign： 基于Feign的動態(tài)代理機制，根據(jù)注解和選擇的機器，拼接請求URL地址，發(fā)起請求

Hystrix： 發(fā)起請求是通過Hystrix的線程池來走的，不同的服務走不同的線程池，實現(xiàn)了不同服務調(diào)用的隔離，避免了服務雪崩的問題

Zuul： 如果前端、移動端要調(diào)用后端系統(tǒng)，統(tǒng)一從Zuul網(wǎng)關進入，由Zuul網(wǎng)關轉(zhuǎn)發(fā)請求給對應的服務

End

作者：邋遢的流浪劍客,本文版權歸作者所有

blog.csdn.net/qq_40378034/article/details/86552677

特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝