(1)Netflix Eureka
1）、Eureka服務端：也稱服務注冊中心，同其他服務注冊中心一樣，支持高可用配置，如果Eureka以集群模式部署，當集群中有分片出現故障時，那么Eureka就轉入自我保護模式，它允許在分片故障期間繼續提供服務的發現和注冊，當故障分片恢復運行時，集群中其他分片會把它們的狀態再次同步回來
2）、Eureka客戶端：主要處理服務的注冊與發現，客戶端服務通過注解和引數配置的方式，嵌入在客戶端應用程式的代碼中，在應用程式運行時，Eureka客戶端向注冊中心注冊自身提供的服務并周期性地發送心跳來更新它的服務租約，同時，它也能從服務端查詢當前注冊的服務資訊并把它們快取到本地并周期性地重繪服務狀態
3）、Eureka Server的高可用實際上就是將自己作為服務向其他注冊中心注冊自己，這樣就可以形成一組互相注冊的服務注冊中心，以實作服務清單的互相同步，達到高可用效果
(2)Eureka詳解
1）、服務提供者
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=902）、服務消費者
A.獲取服務
當我們啟動服務消費者的時候，它會發送一個REST請求給服務注冊中心，來獲取上面注冊的服務清單，為了性能考慮，Eureka Server會維護一份只讀的服務清單來回傳給客戶端，同時該快取清單會每隔30秒更新一次
# 快取清單的更新時間，默認30秒
eureka.client.registry-fetch-interval-seconds=30B.服務呼叫
服務消費者在獲取服務清單后，通過服務名可以獲得具體提供服務的實體名和該實體的元資料資訊，在Ribbon中會默認采用輪詢的方式進行呼叫，從而實作客戶端的負載均衡，面試題推薦：100期面試題匯總
對于訪問實體的選擇，Eureka中有Region和Zone的概念，一個Region中可以包含多個Zone，每個服務客戶端需要被注冊到一個Zone中，所以每個客戶端對應一個Region和一個Zone，在進行服務呼叫的時候，優先訪問同處一個一個Zone中的服務提供方，若訪問不到，就訪問其他的Zone
C.服務下線
當服務實體進行正常的關閉操作時，它會觸發一個服務下線的REST請求給Eureka Server，告訴服務注冊中心：“我要下線了”，服務端在接收到請求之后，將該服務狀態置為下線（DOWN），并把該下線事件傳播出去
3）、服務注冊中心
A.失效剔除
Eureka Server在啟動的時候會創建一個定時任務，默認每隔一段時間（默認為60秒）將當前清單中超時（默認為90秒）沒有續約的服務剔除出去
B.自我保護
在服務注冊中心的資訊面板中出現紅色警告資訊：
該警告就是觸發了Eureka Server的自我保護機制，Eureka Server在運行期間，會統計心跳失敗的比例在15分鐘之內是否低于85%，如果出現低于的情況，Eureka Server會將當前的實體注冊資訊保護起來，讓這些實體不會過期，盡可能保護這些注冊資訊，
但是，在這段保護期間內實體若出現問題，那么客戶端很容易拿到實際已經不存在的服務實體，會出現呼叫失敗的情況，所以客戶端必須要有容錯機制，比如可以使用請求重試、斷路器等機制
# 關閉保護機制，以確保注冊中心可以將不用的實體正確剔除（本地除錯可以使用，線上不推薦）
eureka.server.enable-self-preservation=false二、Spring Cloud核心組件：Ribbon
Ribbon是一個基于HTTP和TCP的客戶端負載均衡器，它可以在通過客戶端中配置的ribbonServerList服務端串列去輪詢訪問以達到服務均衡的作用，
當Ribbon和Eureka聯合使用時，Ribbon的服務實體清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka注冊中心中獲取服務端串列，同時它也會用NIWSDiscoveryPing來取代IPing，它將職責委托給Eureka來確定服務端是否已經啟動
在客戶端負載均衡中，所有客戶端節點都維護著自己要訪問的服務端清單，而這些服務端的清單來自于服務注冊中心（比如Eureka），在客戶端負載均衡中也需要心跳去維護服務端清單的健康性，只是這個步驟需要與服務注冊中心配合完成
通過Spring Cloud Ribbon的封裝，我們在微服務架構中使用客戶端負載均衡呼叫只需要如下兩步：
服務提供者只需要啟動多個服務實體并且注冊到一個注冊中心或是多個相關聯的服務注冊中心 服務消費者直接通過呼叫被@LoadBalanced注解修飾過的RestTemplate來實作面向服務的介面呼叫，面試題推薦：100期面試題匯總
三、Spring Cloud核心組件：Feign
Feign的關鍵機制是使用了動態代理
1）、首先，對某個介面定義了@FeignClient注解，Feign就會針對這個介面創建一個動態代理
2）、接著呼叫介面的時候，本質就是呼叫Feign創建的動態代理
3）、Feign的動態代理會根據在介面上的@RequestMapping等注解，來動態構造要請求的服務的地址
4）、針對這個地址，發起請求、決議回應
Feign是和Ribbon以及Eureka緊密協作的
1）、首先Ribbon會從Eureka Client里獲取到對應的服務注冊表，也就知道了所有的服務都部署在了哪些機器上，在監聽哪些埠
2）、然后Ribbon就可以使用默認的Round Robin演算法，從中選擇一臺機器
3）、Feign就會針對這臺機器，構造并發起請求
四、Spring Cloud核心組件：Hystrix
在微服務架構中，存在著那么多的服務單元，若一個單元出現故障，就很容易因依賴關系而引發故障的蔓延，最終導致整個系統的癱瘓，這樣的架構相較傳統架構更加不穩定，為了解決這樣的問題，產生了斷路器等一系列的服務保護機制
在分布式架構中，當某個服務單元發生故障之后，通過斷路器的故障監控，向呼叫方回傳一個錯誤回應，而不是長時間的等待，這樣就不會使得執行緒因呼叫故障服務被長時間占用不釋放，避免了故障在分布式系統中的蔓延
Hystrix具備服務降級、服務熔斷、執行緒和信號隔離、請求快取、請求合并以及服務監控等強大功能
Hystrix使用艙壁模式實作執行緒池的隔離，它會為每一個依賴服務創建一個獨立的執行緒池，這樣就算某個依賴服務出現延遲過高的情況，也只是對該依賴服務的呼叫產生影響，而不會拖慢其他的依賴服務
五、Spring Cloud核心組件：Zuul
Spring Cloud Zuul通過與Spring Cloud Eureka進行整合，將自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得了所有其他微服務的實體資訊
對于路由規則的維護，Zuul默認會將通過以服務名作為ContextPath的方式來創建路由映射
Zuul提供了一套過濾器機制，可以支持在API網關無附上進行統一呼叫來對微服務介面做前置過濾，已實作對微服務介面的攔截和校驗
六、總結
- Eureka：各個服務啟動時，Eureka Client都會將服務注冊到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊表，從而知道其他服務在哪里
- Ribbon：服務間發起請求的時候，基于Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺
- Feign：基于Feign的動態代理機制，根據注解和選擇的機器，拼接請求URL地址，發起請求
- Hystrix：發起請求是通過Hystrix的執行緒池來走的，不同的服務走不同的執行緒池，實作了不同服務呼叫的隔離，避免了服務雪崩的問題
- Zuul：如果前端、移動端要呼叫后端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務
作者：邋遢的流浪劍客
blog.csdn.net/qq_40378034/article/details/86552677
寫在最后
分享一些Java學習資料獲取方式：點擊鏈接《Java面試BAT通關手冊》，覆寫了Java核心技術、JVM、Java并發、SSM、微服務、資料庫、資料結構等等，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/108960.html
標籤：Java