1. 程式人生 > >Eureka的工作原理以及它與ZooKeeper的區別

Eureka的工作原理以及它與ZooKeeper的區別

Eureka的工作原理以及它與ZooKeeper的區別

1、Eureka 簡介:

Eureka 是 Netflix 出品的用於實現服務註冊和發現的工具。 Spring Cloud 集成了 Eureka,並提供了開箱即用的支援。其中, Eureka 又可細分為 Eureka Server 和 Eureka Client。

 

1.基本原理

上圖是來自eureka的官方架構圖,這是基於叢集配置的eureka; 
- 處於不同節點的eureka通過Replicate進行資料同步 
- Application Service為服務提供者 
- Application Client為服務消費者 
- Make Remote Call完成一次服務呼叫

服務啟動後向Eureka註冊,Eureka Server會將註冊資訊向其他Eureka Server進行同步,當服務消費者要呼叫服務提供者,則向服務註冊中心獲取服務提供者地址,然後會將服務提供者地址快取在本地,下次再呼叫時,則直接從本地快取中取,完成一次呼叫。

當服務註冊中心Eureka Server檢測到服務提供者因為宕機、網路原因不可用時,則在服務註冊中心將服務置為DOWN狀態,並把當前服務提供者狀態向訂閱者釋出,訂閱過的服務消費者更新本地快取。

服務提供者在啟動後,週期性(預設30秒)向Eureka Server傳送心跳,以證明當前服務是可用狀態。Eureka Server在一定的時間(預設90秒)未收到客戶端的心跳,則認為服務宕機,登出該例項。

2.Eureka的自我保護機制

在預設配置中,Eureka Server在預設90s沒有得到客戶端的心跳,則登出該例項,但是往往因為微服務跨程序呼叫,網路通訊往往會面臨著各種問題,比如微服務狀態正常,但是因為網路分割槽故障時,Eureka Server登出服務例項則會讓大部分微服務不可用,這很危險,因為服務明明沒有問題。

為了解決這個問題,Eureka 有自我保護機制,通過在Eureka Server配置如下引數,可啟動保護機制

eureka.server.enable-self-preservation=true

它的原理是,當Eureka Server節點在短時間內丟失過多的客戶端時(可能傳送了網路故障),那麼這個節點將進入自我保護模式,不再登出任何微服務,當網路故障回覆後,該節點會自動退出自我保護模式。

自我保護模式的架構哲學是寧可放過一個,決不可錯殺一千

3. 作為服務註冊中心,Eureka比Zookeeper好在哪裡

著名的CAP理論指出,一個分散式系統不可能同時滿足C(一致性)、A(可用性)和P(分割槽容錯性)。由於分割槽容錯性在是分散式系統中必須要保證的,因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。

3.1 Zookeeper保證CP

當向註冊中心查詢服務列表時,我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊,但不能接受服務直接down掉不可用。也就是說,服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況,當master節點因為網路故障與其他節點失去聯絡時,剩餘節點會重新進行leader選舉。問題在於,選舉leader的時間太長,30 ~ 120s, 且選舉期間整個zk叢集都是不可用的,這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下,因網路問題使得zk叢集失去master節點是較大概率會發生的事,雖然服務能夠最終恢復,但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

 

3.2 Eureka保證AP

Eureka看明白了這一點,因此在設計時就優先保證可用性。Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工作,剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連線失敗,則會自動切換至其它節點,只要有一臺Eureka還在,就能保證註冊服務可用(保證可用性),只不過查到的資訊可能不是最新的(不保證強一致性)。除此之外,Eureka還有一種自我保護機制,如果在15分鐘內超過85%的節點都沒有正常的心跳,那麼Eureka就認為客戶端與註冊中心出現了網路故障,此時會出現以下幾種情況: 
1. Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務 
2. Eureka仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其它節點上(即保證當前節點依然可用) 
3. 當網路穩定時,當前例項新的註冊資訊會被同步到其它節點中

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

4. 總結

Eureka作為單純的服務註冊中心來說要比zookeeper更加“專業”,因為註冊服務更重要的是可用性,我們可以接受短期內達不到一致性的狀況。不過Eureka目前1.X版本的實現是基於servlet的Java web應用,它的極限效能肯定會受到影響。期待正在開發之中的2.X版本能夠從servlet中獨立出來成為單獨可部署執行的服務。