為什么不應(yīng)該使用ZooKeeper做服務(wù)發(fā)現(xiàn)

英文鏈接:
Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery:
http://www./tech/blog/2014/12/eureka-shouldnt-use-zookeeper-service-discovery/
中文鏈接:
http://blog.csdn.net/jenny8080/article/details/52448403
Eureka vs. Zookeeper：
https://groups.google.com/forum/#%21topic/eureka_netflix/LXKWoD14RFY

Netflix Shares Cloud Load Balancing And Failover Tool: Eureka!

 https://techblog./2012/09/eureka.html

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

ZooKeeper是個 CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數(shù)據(jù)結(jié)果，同時系統(tǒng)對網(wǎng)絡(luò)分割具備容錯性;

在Eureka平臺中，如果某臺服務(wù)器宕機，Eureka不會有類似于ZooKeeper的選舉leader的過程；客戶端請求會自動切換 到新的Eureka節(jié)點；當宕機的服務(wù)器重新恢復(fù)后，Eureka會再次將其納入到服務(wù)器集群管理之中,

所以，再也不用擔心有“掉隊”的服務(wù)器恢復(fù)以后，會從Eureka服務(wù)器集群中剔除出去的風險了。Eureka甚至被設(shè)計用來應(yīng)付范圍更廣 的網(wǎng)絡(luò)分割故障，并實現(xiàn)“0”宕機維護需求。當網(wǎng)絡(luò)分割故障發(fā)生時，每個Eureka節(jié)點，會持續(xù)的對外提供服務(wù)（注：ZooKeeper不會）：接收新 的服務(wù)注冊同時將它們提供給下游的服務(wù)發(fā)現(xiàn)請求。這樣一來，就可以實現(xiàn)在同一個子網(wǎng)中（same side of partition），新發(fā)布的服務(wù)仍然可以被發(fā)現(xiàn)與訪問。 

注： 高延遲與網(wǎng)絡(luò)分割問題 原文為network partitions。意思是當網(wǎng)絡(luò)交換機出故障會導致不同子網(wǎng)間通訊中斷;

正常配置下，Eureka內(nèi)置了心跳服務(wù)，用于淘汰一些“瀕死”的服務(wù)器；如果在Eureka中注冊的服務(wù)， 它的“心跳”變得遲緩時，Eureka會將其整個剔除出管理范圍（這點有點像ZooKeeper的做法）。這是個很好的功能，但是當網(wǎng)絡(luò)分割故障發(fā)生時， 這也是非常危險的；因為，那些因為網(wǎng)絡(luò)問題（注：心跳慢被剔除了）而被剔除出去的服務(wù)器本身是很”健康“的，只是因為網(wǎng)絡(luò)分割故障把Eureka集群分割 成了獨立的子網(wǎng)而不能互訪而已。 

如果Eureka服務(wù)節(jié)點在短時間里丟失了大量的心跳連接（注：可能發(fā)生了網(wǎng)絡(luò)故障），那么這個 Eureka節(jié)點會進入”自我保護模式“，同時保留那些“心跳死亡“的服務(wù)注冊信息不過期。此時，這個Eureka節(jié)點對于新的服務(wù)還能提供注冊服務(wù)，對 于”死亡“的仍然保留，以防還有客戶端向其發(fā)起請求。當網(wǎng)絡(luò)故障恢復(fù)后，這個Eureka節(jié)點會退出”自我保護模式“。所以Eureka的哲學是，同時保 留”好數(shù)據(jù)“與”壞數(shù)據(jù)“總比丟掉任何”好數(shù)據(jù)“要更好，所以這種模式在實踐中非常有效。 

Eureka還有客戶端緩存功能（注：Eureka分為客戶端程序與服務(wù)器端程序兩個部分，客戶端程序負責向外提供注冊與發(fā)現(xiàn)服務(wù)接口）。 所以即便Eureka集群中所有節(jié)點都失效，或者發(fā)生網(wǎng)絡(luò)分割故障導致客戶端不能訪問任何一臺Eureka服務(wù)器；Eureka服務(wù)的消費者仍然可以通過 Eureka客戶端緩存來獲取現(xiàn)有的服務(wù)注冊信息。甚至最極端的環(huán)境下，所有正常的Eureka節(jié)點都不對請求產(chǎn)生相應(yīng)，也沒有更好的服務(wù)器解決方案來解 決這種問題時；得益于Eureka的客戶端緩存技術(shù)，消費者服務(wù)仍然可以通過Eureka客戶端查詢與獲取注冊服務(wù)信息，這點很重要;  由于Eureka客戶端具有注冊表緩存信息，所以即使所有的Eureka服務(wù)器都停機，它們也可以運行得很好;

進一步了解 Eureka

Eureka基本架構(gòu)圖

architecture-overview

上圖簡要描述了Eureka的基本架構(gòu)，由3個角色組成：

1. Eureka Server

   • 提供服務(wù)注冊和發(fā)現(xiàn)

2. Service Provider

   • 服務(wù)提供者，服務(wù)啟動的時候會將自己的服務(wù)信息注冊到Eureka

3. Service Consumer

   • 服務(wù)消費者，從Eureka中獲取已注的服務(wù)信息，用于調(diào)用服務(wù)生產(chǎn)者

需要注意一點是：一個Service Provider既可以是Service Consumer，也可以是Service Provider。

集群模式下的Eureka

上圖更進一步的展示了3個角色之間的交互。

1. Service Provider會向Eureka Server做Register（服務(wù)注冊）、Renew（服務(wù)續(xù)約）、Cancel（服務(wù)下線）等操作。
2. Eureka Server之間會做注冊服務(wù)的同步，從而保證狀態(tài)一致
3. Service Consumer會向Eureka Server獲取注冊服務(wù)列表，并消費服務(wù)

Eureka的工作原理

Eureka 組件分為兩部分：Eureka server和 Eureka client。而客戶端又分為 Application Service 客戶端和 Application Client 客戶端兩種。

Eureka 的工作機制每個 region 都有自己的 Eureka 服務(wù)器集群，每個 zone 至少要有一個 Eureka 服務(wù)器以應(yīng)對 zone 

名詞解釋

Renew:續(xù)約

Renew（服務(wù)續(xù)約）操作由Service Provider定期調(diào)用，類似于heartbeat。目的是隔一段時間Service Provider調(diào)用接口，告訴Eureka Server它還活著沒掛，不要把它踢掉。通俗的說就是它們兩之間的心跳檢測，

避免服務(wù)提供者被剔除掉

Cancel（服務(wù)下線）

一般在Service Provider掛了或shut down的時候調(diào)用，用來把自身的服務(wù)從Eureka Server中刪除，以防客戶端調(diào)用到不存在的服務(wù)。

Fetch Registries(獲取注冊信息)，

Fetch Registries由Service Consumer(服務(wù)消費者)調(diào)用，用來獲取Eureka Server上注冊的服務(wù)info。

Eviction(剔除)

Eviction（失效服務(wù)剔除）用來定期在Eureka Server檢測失效的服務(wù)，檢測標準就是超過一定時間沒有Renew的服務(wù)。

Eureka架構(gòu)圖

Eureka架構(gòu)圖如下圖所示，github地址:https://github.com/netflix/eureka
document地址:https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

Application Service 在啟動時注冊到 Eureka 服務(wù)器，之后每 30 秒鐘發(fā)送心跳以更新自身狀態(tài),即Renew(續(xù)約)。如果該客戶端沒能發(fā)送心跳更新，它將在 90 秒之后被其注冊的 Eureka 服務(wù)器剔除，即Eviction(剔除)。

來自任意 zone 的 Application Client 可以獲取這些注冊信息(每隔 30 秒查看一次)并依此定位到在任何區(qū)域可以給自己提供服務(wù)的提供者(即Fetch Registries)，進而進行遠程調(diào)用。

服務(wù)提供者本身攜帶的Eureka Client既能服務(wù)注冊，服務(wù)續(xù)約，也能通過client定位服務(wù)和調(diào)用其它的服務(wù)。

Renew(服務(wù)續(xù)約)

服務(wù)續(xù)約 Renew操作會在Service Provider端定期發(fā)起，用來通知Eureka Server自己還活著

eureka.instance.leaseRenewalIntervalInSeconds

 Renew頻率。默認是30秒，也就是每30秒會向Eureka Server發(fā)起Renew操作。

eureka.instance.leaseExpirationDurationInSeconds

服務(wù)失效時間。默認是90秒，也就是如果Eureka Server在90秒內(nèi)沒有接收到來自Service Provider的Renew操作，就會把Service Provider剔除。