來源：https://www.cnblogs.com/jieqing/p/8394001.html

剛開始看到Eureka這個(gè)單詞的時(shí)候真心不會(huì)念，查了后發(fā)現(xiàn)他有一個(gè)好聽的名字，來，大家一起念 [ j?'rik? ]

簡介

Eureka本身是Netflix開源的一款提供服務(wù)注冊(cè)和發(fā)現(xiàn)的產(chǎn)品，并且提供了相應(yīng)的Java封裝。在它的實(shí)現(xiàn)中，節(jié)點(diǎn)之間相互平等，部分注冊(cè)中心的節(jié)點(diǎn)掛掉也不會(huì)對(duì)集群造成影響，即使集群只剩一個(gè)節(jié)點(diǎn)存活，也可以正常提供發(fā)現(xiàn)服務(wù)。哪怕是所有的服務(wù)注冊(cè)節(jié)點(diǎn)都掛了，Eureka
Clients（客戶端）上也會(huì)緩存服務(wù)調(diào)用的信息。這就保證了我們微服務(wù)之間的互相調(diào)用足夠健壯。
Zookeeper主要為大型分布式計(jì)算提供開源的分布式配置服務(wù)、同步服務(wù)和命名注冊(cè)。曾經(jīng)是Hadoop項(xiàng)目中的一個(gè)子項(xiàng)目，用來控制集群中的數(shù)據(jù)，目前已升級(jí)為獨(dú)立的頂級(jí)項(xiàng)目。很多場(chǎng)景下也用它作為Service發(fā)現(xiàn)服務(wù)解決方案。

對(duì)比

在分布式系統(tǒng)中有個(gè)著名的CAP定理（C-數(shù)據(jù)一致性；A-服務(wù)可用性；P-服務(wù)對(duì)網(wǎng)絡(luò)分區(qū)故障的容錯(cuò)性，這三個(gè)特性在任何分布式系統(tǒng)中不能同時(shí)滿足，最多同時(shí)滿足兩個(gè)）；

Zookeeper

Zookeeper是基于CP來設(shè)計(jì)的，即任何時(shí)刻對(duì)Zookeeper的訪問請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分割具備容錯(cuò)性，但是它不能保證每次服務(wù)請(qǐng)求的可用性。從實(shí)際情況來分析，在使用Zookeeper獲取服務(wù)列表時(shí)，如果zookeeper正在選主，或者Zookeeper集群中半數(shù)以上機(jī)器不可用，那么將無法獲得數(shù)據(jù)。所以說，Zookeeper不能保證服務(wù)可用性。
誠然，在大多數(shù)分布式環(huán)境中，尤其是涉及到數(shù)據(jù)存儲(chǔ)的場(chǎng)景，數(shù)據(jù)一致性應(yīng)該是首先被保證的，這也是zookeeper設(shè)計(jì)成CP的原因。但是對(duì)于服務(wù)發(fā)現(xiàn)場(chǎng)景來說，情況就不太一樣了：針對(duì)同一個(gè)服務(wù)，即使注冊(cè)中心的不同節(jié)點(diǎn)保存的服務(wù)提供者信息不盡相同，也并不會(huì)造成災(zāi)難性的后果。

因?yàn)閷?duì)于服務(wù)消費(fèi)者來說，能消費(fèi)才是最重要的——拿到可能不正確的服務(wù)實(shí)例信息后嘗試消費(fèi)一下，也好過因?yàn)闊o法獲取實(shí)例信息而不去消費(fèi)。

（嘗試一下可以快速失敗，之后可以更新配置并重試）所以，對(duì)于服務(wù)發(fā)現(xiàn)而言，可用性比數(shù)據(jù)一致性更加重要——AP勝過CP。

Eureka

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

如果某臺(tái)Eureka Server宕機(jī)，Eureka Client的請(qǐng)求會(huì)自動(dòng)切換到新的EurekaServer節(jié)點(diǎn)，當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后，Eureka會(huì)再次將其納入到服務(wù)器集群管理之中。當(dāng)節(jié)點(diǎn)開始接受客戶端請(qǐng)求時(shí)，所有的操作都會(huì)進(jìn)行replicateToPeer（節(jié)點(diǎn)間復(fù)制）操作，將請(qǐng)求復(fù)制到其他EurekaServer當(dāng)前所知的所有節(jié)點(diǎn)中。

一個(gè)新的Eureka Server節(jié)點(diǎn)啟動(dòng)后，會(huì)首先嘗試從鄰近節(jié)點(diǎn)獲取所有實(shí)例注冊(cè)表信息，完成初始化。EurekaServer通過getEurekaServiceUrls()方法獲取所有的節(jié)點(diǎn)，并且會(huì)通過心跳續(xù)約的方式定期更新。默認(rèn)配置下，如果EurekaServer在一定時(shí)間內(nèi)沒有接收到某個(gè)服務(wù)實(shí)例的心跳，EurekaServer將會(huì)注銷該實(shí)例（默認(rèn)為90秒，通過eureka.instance.lease-expiration-duration-in-seconds配置）。當(dāng)Eureka Server節(jié)點(diǎn)在短時(shí)間內(nèi)丟失過多的心跳時(shí)（比如發(fā)生了網(wǎng)絡(luò)分區(qū)故障），那么這個(gè)節(jié)點(diǎn)就會(huì)進(jìn)入自我保護(hù)模式。

什么是自我保護(hù)模式？

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

總結(jié)

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

所以理論上Eureka是更適合作注冊(cè)中心。而現(xiàn)實(shí)環(huán)境中大部分項(xiàng)目可能會(huì)使用ZooKeeper，那是因?yàn)榧翰粔虼螅⑶一静粫?huì)遇到用做注冊(cè)中心的機(jī)器一半以上都掛了的情況。所以實(shí)際上也沒什么大問題。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝