寫在前面

    在對比zookeeper和Eureka之前,首先來了解一個原則,那就是CAP原則,這是啥??????

分散式領域CAP理論，
Consistency(一致性), 資料一致更新，所有資料變動都是同步的
Availability(可用性), 好的響應效能
Partition tolerance(分割槽容忍性) 可靠性
定理：任何分散式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分散式系統，而是應該進行取捨。
關係資料庫的ACID模型擁有 高一致性 + 可用性 很難進行分割槽：
Atomicity原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。
Consistency一致性. 在事務開始或結束時，資料庫應該在一致狀態。
Isolation隔離層. 事務將假定只有它自己在操作資料庫，彼此不知曉。
Durability. 一旦事務完成，就不能返回。
跨資料庫兩段提交事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支援2PC。因為2PC是反模式，儘量不要使用2PC，使用BASE來回避

分散式系統的CAP理論：理論首先把分散式系統中的三個特性進行了如下歸納：

● 一致性（C）：在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本），換句話就是說，任何時刻，所用的應用程式都能訪問得到相同的資料。
● 可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性），換句話就是說，任何時候，任何應用程式都可以讀寫資料。
● 分割槽容錯性（P）：以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇，換句話說，系統可以跨網路分割槽線性的伸縮和擴充套件。


如上圖所示意，不可能設計出既滿足一致性，有滿足可用性還同時滿足分割槽容錯性的系統。

進入正題

在瞭解完了CAP原則,我們進入正題,學習一下Eureka和zookeeper這兩個的區別

Eureka:是基於REST（Representational State Transfer）服務，主要以AWS雲服務為支撐，提供服務發現並實現負載均衡和故障轉移。我們稱此服務為Eureka服務。Eureka提供了Java客戶端元件，Eureka Client，方便與服務端的互動。客戶端內建了基於round-robin實現的簡單負載均衡。在Netflix，為Eureka提供更為複雜的負載均衡方案進行封裝，以實現高可用，它包括基於流量、資源利用率以及請求返回狀態的加權負載均衡。

zookeeper:是一個高效的分散式協調服務，可以提供配置資訊管理、命名、分散式同步、叢集管理、資料庫切換等服務。它不適合用來儲存大量資訊，可以用來儲存一些配置、釋出與訂閱等少量資訊。Hadoop、Storm、訊息中介軟體、RPC服務框架、分散式資料庫同步系統，這些都是Zookeeper的應用場景。

其中他們都可以被用作分散式系統中的服務治理,作為註冊中心,提供服務的註冊與發現功能

區別:

Zookeeper保證CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得zk叢集失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。
Eureka保證AP(很多時間為了保證服務高可用,我們的保證AP)
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連線失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的資訊可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況： 
1. Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務 
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用) 
3. 當網路穩定時，當前例項新的註冊資訊會被同步到其它節點中
因此， Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
5. 總結
Eureka作為單純的服務註冊中心來說要比zookeeper更加“專業”，因為註冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。不過Eureka目前1.X版本的實現是基於servlet的java web應用，它的極限效能肯定會受到影響。期待正在開發之中的2.X版本能夠從servlet中獨立出來成為單獨可部署執行的服務。