Spring Cloud Eureka的基礎架構

基礎架構

• 服務註冊中心：Eureka提供的服務端，提供服務註冊於發現的功能，也就是在上一節中咱們實現的eureka-server

• 服務提供者：提供服務的應用，能夠是springBoot應用，也能夠是其餘技術平臺且遵循Eureka通訊機制的應用。它將
  

　　　　　　　　本身提供的服務註冊到Eureka，以供其餘應用發現，也就是上一節中咱們實現的HELLO-SERVICE應用。

• 服務消費者：消費者應用從服務註冊中心獲取服務列表，從而使消費者能夠知道從何處調用其所須要的服務，在上一節

　　　　　　　　使用了Ribbon來實現服務消費，另外後續還需介紹是哦那個Feign的消費方式。

不少時候客戶端既是服務提供者也是服務消費者。

 

服務治理機制

 

　　根據上面的結構，咱們來詳細瞭解一下，從服務註冊開始到服務調用，及各個元素涉及的一些重要通訊行爲

服務提供者

　　1.服務註冊

　　　　　　「服務提供者」在啓動的時候會經過發送REST請求的方式將本身註冊到EurekaServer上，同時帶了自身服務的一些元

數據信息。Eureka Server接收到這個REST請求以後，將元素據信息存儲在一個雙層結構的MAP中，其中，第一層的key是服務名，

第二層的key是具體服務的實例名。一個服務有多個實例的狀況下，這些內容就是以這樣的雙層Map形式存儲的。

　　　　在服務註冊時，須要確認下eureka.client.register-with-eureka=true 參數是否正確，該值默認爲true。若設置爲false將不會啓動註冊操做。

　　2.服務同步。

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

此時，因爲服務註冊中心之間因互相註冊爲服務，當服務提供者發送註冊請求到一個服務註冊中心時，它會將請求轉發給集羣中

相連的其餘註冊中心，從而實現註冊中心之間的服務同步。經過服務同步，兩個服務提供者的服務信息就能夠經過這兩臺服務註冊中心的任意一臺獲取。

　　3.服務續約

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

咱們稱該操做爲服務續約。（Renew）

　　

服務消費者

　　1.獲取服務

　　　　　　到這裏，在服務註冊中心已經註冊了一個服務，而且該服務有兩個實例。當咱們啓動服務消費者的時候，它會發送一個REST請求給服務註冊中心，來獲取

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

　　　　　　

 

 　　2.服務調用

　　　　　　服務消費者在獲取服務清單後，經過服務名能夠得到具體提供服務的實例名和該實例的元數據信息。由於有這些服務實例

的詳細信息，因此客戶端能夠根據本身的須要決定具體調用哪一個實例，在Ribbon中會默認採用輪詢的方式進行調用，從而使客戶端負載均衡。

　　　　　　對於訪問實例的選擇，Eureka中有Region和Zone的概念，一個Region中能夠包含多個Zone，每一個服務客戶端須要被註冊到一個

Zone中，因此每一個客戶端對應一個Region和一個Zone。在進行服務調用的時候，優先訪問同處一個Zone中的服務提供方。

　　3.服務下線

 　　　　　　在系統運行過程當中必然會面臨關閉或重啓服務的某個實例的狀況，在服務關閉期間，咱們天然不但願客戶端會繼續調用關閉了的實例。因此在客戶端

程序中，當服務實例進行正常的關閉操做時，它會出發一個服務下線的REST請求給EurekaServer，告訴服務註冊中心：」我要下線了「。服務端接收到請求以後，將

該服務狀態置爲down。並把下線事件傳播出去。

 

服務註冊中心

　　1.失效剔除　

　　　　　　有些時候，咱們的服務實例並不必定會正常下線，可能因爲內存溢出，網絡故障等緣由使服務不能正常工做，而服務註冊中心未

收到」服務下線「的請求。爲了從服務列表中將這些沒法提供服務的實例剔除。Eureka Server在啓動的時候會建立一個定時任務，默認每隔一段時間

（默認60s）將當前清單中超時（默認爲90s）沒有續約的服務剔除出去。

　　2.自我保護

　　　　　　當咱們在本地調試基於Eureka的程序時，基本上都會碰到一個這樣的問題，在服務註冊宗信的信息面板出現類下面

的警告信息：

實際上，該警告就出發了Eureka Server的自我保護機制。服務註冊到Eureka Server以後，會維護一個心跳鏈接，告訴Eureka Server本身還活着。

Eureka Server在運行期間，會統計心跳失敗的比例在15分鐘以內是否低於80%，若是出現低於的狀況，Eureka Server會將當前的實例註冊信息保護起來

讓這些實例不會過時，儘量保護這些註冊信息。可是，這段保護期間內實例出現問題，那麼客戶端很容易拿到實際已經不存在的服務實例，會出現調用失敗的狀況，

因此客戶端必需要有容錯機制，好比可使用請求重試，斷路器機制等。