Spring Cloud中服務治理Eureka是怎么樣的

這篇文章將為大家詳細講解有關Spring Cloud中服務治理Eureka是怎么樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

一、請說說eureka和zookeeper兩個的區別&為什么微服務服務治理選擇Eureka,而不是zookeeper？

所謂的CAP原則:C:Consistency一致性  A:Availability可用性 P:Partition tolerance分區容錯性

一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由于分區容錯性P在是分布式系統中必須要保證的,因此我們只能在A和C之間進行權衡

zookeeper遵守CP

當向注冊中心查詢服務列表時,我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息,但不能接受服務直接down掉不可用。也就是說,服務注冊功能對一致性的要求要高于可用性。

但是zookeeper會出現這樣一種情況,當 master節點因為網絡故障與其他節點失去聯系時,剩余節點會重新進行leader選舉。

問題在于,選舉leader的時間太長,30~120s,目選舉期間整個zookeeper集群都是不可用的,這就導致在選舉期間注冊服務癱瘓。

在云部署的環境下,因網絡問題使得zookeeper 集群失去 master節點是較大概率會發生的事,雖然服務能夠最終恢復,但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。

或許這個回答太過于抽象  用一種其他說法來說 就是 ：

當有一個zookeeper掛了,那其他的zookeeper會進行一次選舉(強一致性 ： 我一定要保持數據一致性）,而在此選舉期間zookeeper是不可用的,而當前 有用戶正在使用,用戶就不爽了

eureka遵守AP

Eureka:看明白了這一點,因此在設計時就優先保證可用性。

Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工作,剩余的節點依然可以提供注冊和查詢服務。

而Eureka的客戶端在向某個Eureka注冊時,如果發現連接失敗,則會自動切換至其它節點,

只要有一臺Eureka還在,就能保證注冊服務可用(保證可用性),只不過查到的信息可能不是最新的不保證強一致性)。

除此之外, Eureka還有一種自我保護機制,如果在15分鐘內超過85%的節點都沒有正常的心跳,那么 Eurekas就認為客戶端與注冊中心出現了網絡故障,此時會出現以下幾種情況:

1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務

2. Eureka仍然能夠接受新服務的注冊和査詢請求,但是不會被同步到其它節點上(即保證當前節點依然可用)

3.當網絡穩定時,當前實例新的注冊信息會被同步到其它節點中

因此, Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像 zookeeper那樣使整個注冊服務癱瘓。

基本原理

服務啟動后向Eureka注冊，Eureka Server會將注冊信息向其他Eureka Server進行同步。

當消費者調用提供者，則向服務注冊中心獲取服務提供者地址，然后將服務提供者地址緩存到本地，下次再調用的時候，直接從本地緩存中讀取，完成一次調用。

當服務注冊中心EurekaServer檢測到提供者，由于宕機、網絡原因等不可用時，則在服務注冊中心將服務置為Down狀態，并把當前服務提供者的狀態向訂閱者發布，訂閱過的消費者更新本地緩存。

服務提供者在啟動后，周期性(默認30秒)向Eureka Server發送心跳，以證明當前服務時可用狀態。Eureka Server在一定時間(默認90秒)未收到客戶端的心跳，則認為服務宕機，注銷該實例。

總結：選擇Eureka作為服務注冊中心更好，因為注冊服務更重要的是可用性，我們可以接受短時間內達不到一致性的狀況。

二、Eureka高可用原理

默認情況下Eureka是讓服務注冊中心，不注冊自己

Eureka高可用實際上將自己作為服務向其他服務注冊中心注冊自己，這樣就可以形成一組相互注冊的服務注冊中心，從而實現服務清單的互相同步，達到高可用效果。

關于Spring Cloud中服務治理Eureka是怎么樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。