簡介

Eureka本身是Netflix開源的一款提供服務注冊和發現的產品，并且提供了相應的Java封裝。在它的實現中，節點之間相互平等，部分注冊中心的節點掛掉也不會對集群造成影響，即使集群只剩一個節點存活，也可以正常提供發現服務。哪怕是所有的服務注冊節點都掛了，Eureka Clients(客戶端)上也會緩存服務調用的信息。這就保證了我們微服務之間的互相調用足夠健壯。

[[312490]]

Zookeeper主要為大型分布式計算提供開源的分布式配置服務、同步服務和命名注冊。曾經是Hadoop項目中的一個子項目，用來控制集群中的數據，目前已升級為獨立的頂級項目。很多場景下也用它作為Service發現服務解決方案。

對比

在分布式系統中有個著名的CAP定理(C-數據一致性;A-服務可用性;P-服務對網絡分區故障的容錯性，這三個特性在任何分布式系統中不能同時滿足，最多同時滿足兩個)。

Zookeeper

Zookeeper是基于CP來設計的，即任何時刻對Zookeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是它不能保證每次服務請求的可用性。從實際情況來分析，在使用Zookeeper獲取服務列表時，如果zookeeper正在選主，或者Zookeeper集群中半數以上機器不可用，那么將無法獲得數據。所以說，Zookeeper不能保證服務可用性。

誠然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是zookeeper設計成CP的原因。但是對于服務發現場景來說，情況就不太一樣了：針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也并不會造成災難性的后果。因為對于服務消費者來說，能消費才是最重要的——拿到可能不正確的服務實例信息后嘗試消費一下，也好過因為無法獲取實例信息而不去消費。(嘗試一下可以快速失敗，之后可以更新配置并重試)所以，對于服務發現而言，可用性比數據一致性更加重要——AP勝過CP。 

Eureka

而Spring Cloud Netflix在設計Eureka時遵守的就是AP原則。Eureka Server也可以運行多個實例來構建集群，解決單點問題，但不同于ZooKeeper的選舉leader的過程，Eureka Server采用的是Peer to Peer對等通信。這是一種去中心化的架構，無master/slave區分，每一個Peer都是對等的。在這種架構中，節點通過彼此互相注冊來提高可用性，每個節點需要添加一個或多個有效的serviceUrl指向其他節點。每個節點都可被視為其他節點的副本。

如果某臺Eureka Server宕機，Eureka Client的請求會自動切換到新的Eureka Server節點，當宕機的服務器重新恢復后，Eureka會再次將其納入到服務器集群管理之中。當節點開始接受客戶端請求時，所有的操作都會進行replicateToPeer(節點間復制)操作，將請求復制到其他Eureka Server當前所知的所有節點中。

一個新的Eureka Server節點啟動后，會首先嘗試從鄰近節點獲取所有實例注冊表信息，完成初始化。Eureka Server通過getEurekaServiceUrls()方法獲取所有的節點，并且會通過心跳續約的方式定期更新。默認配置下，如果Eureka Server在一定時間內沒有接收到某個服務實例的心跳，Eureka Server將會注銷該實例(默認為90秒，通過eureka.instance.lease-expiration-duration-in-seconds配置)。當Eureka Server節點在短時間內丟失過多的心跳時(比如發生了網絡分區故障)，那么這個節點就會進入自我保護模式。

什么是自我保護模式?默認配置下，如果Eureka Server每分鐘收到心跳續約的數量低于一個閾值(instance的數量(60/每個instance的心跳間隔秒數)自我保護系數)，并且持續15分鐘，就會觸發自我保護。在自我保護模式中，Eureka Server會保護服務注冊表中的信息，不再注銷任何服務實例。當它收到的心跳數重新恢復到閾值以上時，該Eureka Server節點就會自動退出自我保護模式。它的設計哲學前面提到過，那就是寧可保留錯誤的服務注冊信息，也不盲目注銷任何可能健康的服務實例。該模式可以通過eureka.server.enable-self-preservation = false來禁用，同時eureka.instance.lease-renewal-interval-in-seconds可以用來更改心跳間隔，eureka.server.renewal-percent-threshold可以用來修改自我保護系數(默認0.85)。

總結

ZooKeeper基于CP，不保證高可用，如果zookeeper正在選主，或者Zookeeper集群中半數以上機器不可用，那么將無法獲得數據。Eureka基于AP，能保證高可用，即使所有機器都掛了，也能拿到本地緩存的數據。作為注冊中心，其實配置是不經常變動的，只有發版和機器出故障時會變。對于不經常變動的配置來說，CP是不合適的，而AP在遇到問題時可以用犧牲一致性來保證可用性，既返回舊數據，緩存數據。

所以理論上Eureka是更適合做注冊中心。而現實環境中大部分項目可能會使用ZooKeeper，那是因為集群不夠大，并且基本不會遇到用做注冊中心的機器一半以上都掛了的情況。所以實際上也沒什么大問題。