Eureka的了解及與Zookeeper的差別

Eureka介紹：

Eureka是Netflix的一個子子產品，也是核心子產品之一。Eureka是一個基于REST的服務，用于定位服務，以實作雲端中間層服務發現和故障轉移，服務注冊與發現對于微服務來說是非常重要的，有了服務發現與注冊，隻需要使用服務的辨別符，就可以通路到服務，而不需要修改服務調用的配置檔案了，功能類似于Dubbo的注冊中心，比如Zookeeper;

SpringCloud內建了Eureka，并提供了開箱即用的支援。其中Eureka又可細分為Eureka Server 和Eureka Client.

Eureka基本原理：

伺服器啟動後向Eureka注冊，Eureka Server會将注冊資訊向其他Eureka Server進行同步，當服務消費者需要調用服務提供者時，會向注冊中心擷取服務提供者的位址，然後将位址緩存到本地，下次調用的時候，直接從本地緩存中去取，完成一次調用，當注冊中心檢測到服務提供者當機或者網絡不可用的時候，會向訂閱者釋出服務提供者的狀态，訂閱過的服務消費者會更新本地緩存。服務提供者在啟動後，周期性（預設30秒）向Eureka Server發送心跳，以證明目前服務是可用狀态。Eureka Server在一定的時間（預設90秒）未收到用戶端的心跳，則認為服務當機，登出該執行個體。

Eureka與Zookeeper的差別：

首先了解一下：

關系型資料庫(Mysql, Oracle,SqlServer等)遵循的原則是：ACID原則。

     A：原子性

    C：一緻性

     I：隔離性

   D：持久性

NoSql(redis, Mogodb等)非關系型資料庫遵循的原則是：CAP。

  C：強一緻性

  A：可用性

  P：分區容錯性(服務對網絡分區故障的容錯性)

在分布式領域中有一個很著名的CAP定理，在這個特性中任何分布式系統隻能保證兩個。

Zookeeper保證的是CP

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

Eureka保證的是AP

Eureka看明白了這一點，是以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點挂掉不會影響正常節點的工作，剩餘的節點依然可以提供注冊和查詢服務。而Eureka的用戶端在向某個Eureka注冊時，如果發現連接配接失敗，則會自動切換至其他節點，隻要有一台Eureka還在，就能保住注冊服務的可用性，隻不過查到的資訊可能不是最新的，除此之外，Eureka還有一種自我保護機制，如果在15分鐘内超過85%的節點都沒有正常的心跳，那麼Eureka就認為用戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：

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

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

 3. 當網絡穩定時，目前執行個體新的注冊資訊會被同步到其他節點中

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

Zookeeper的設計理念就是分布式協調服務，保證資料（配置資料，狀态資料）在多個服務系統之間保證一緻性，這也不難看出Zookeeper是屬于CP特性。Eureka是吸取Zookeeper問題的經驗，先保證可用性。