原文連接:Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery！

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

【編者的話】本文作者通過ZooKeeper與Eureka作為Service發(fā)現(xiàn)服務(wù)（注：WebServices體系中的UDDI就是個發(fā)現(xiàn)服務(wù)）的優(yōu)劣對比沥匈，分享了Knewton在云計算平臺部署服務(wù)的經(jīng)驗蔗喂。本文雖然略顯偏激，但是看得出Knewton在云平臺方面是非常有經(jīng)驗的高帖，這篇文章從實踐角度出發(fā)分別從云平臺特點缰儿、CAP原理以及運維三個方面對比了ZooKeeper與Eureka兩個系統(tǒng)作為發(fā)布服務(wù)的優(yōu)劣，并提出了在云平臺構(gòu)建發(fā)現(xiàn)服務(wù)的方法論散址。

背景

很多公司選擇使用ZooKeeper作為Service發(fā)現(xiàn)服務(wù)（Service Discovery）乖阵，但是在構(gòu)建Knewton（Knewton是一個提供個性化教育平臺的公司、學(xué)校和出版商可以通過Knewton平臺為學(xué)生提供自適應(yīng)的學(xué)習(xí)材料）平臺時预麸，我們發(fā)現(xiàn)這是個根本性的錯誤瞪浸。在這邊文章中，我們將用我們在實踐中遇到的問題來說明吏祸，為什么使用ZooKeeper做Service發(fā)現(xiàn)服務(wù)是個錯誤对蒲。

請留意服務(wù)部署環(huán)境

讓我們從頭開始梳理。我們在部署服務(wù)的時候贡翘，應(yīng)該首先考慮服務(wù)部署的平臺（平臺環(huán)境）蹈矮，然后才能考慮平臺上跑的軟件系統(tǒng)或者如何在選定的平臺上自己構(gòu)建一套系統(tǒng)。例如鸣驱，對于云部署平臺來說泛鸟，平臺在硬件層面的伸縮（注：作者應(yīng)該指的是系統(tǒng)的冗余性設(shè)計，即系統(tǒng)遇到單點失效問題踊东，能夠快速切換到其他節(jié)點完成任務(wù)）與如何應(yīng)對網(wǎng)絡(luò)故障是首先要考慮的北滥。當(dāng)你的服務(wù)運行在大量服務(wù)器構(gòu)建的集群之上時（注：原話為大量可替換設(shè)備）勺美，則肯定會出現(xiàn)單點故障的問題。對于knewton來說碑韵，我們雖然是部署在AWS上的，但是在過往的運維中缎脾，我們也遇到過形形色色的故障祝闻；所以，你應(yīng)該把系統(tǒng)設(shè)計成“故障開放型”（expecting failure）的遗菠。其實有很多同樣使用AWS的公司跟我們遇到了（同時有很多書是介紹這方面的）相似的問題联喘。你必須能夠提前預(yù)料到平臺可能會出現(xiàn)的問題如：意外故障（注：原文為box failure，只能意會到作者指的是意外彈出的錯誤提示框）辙纬，高延遲與網(wǎng)絡(luò)分割問題（注：原文為network partitions豁遭。意思是當(dāng)網(wǎng)絡(luò)交換機(jī)出故障會導(dǎo)致不同子網(wǎng)間通訊中斷）——同時我們要能構(gòu)建足夠彈性的系統(tǒng)來應(yīng)對它們的發(fā)生。

永遠(yuǎn)不要期望你部署服務(wù)的平臺跟其他人是一樣的贺拣！當(dāng)然蓖谢，如果你在獨自運維一個數(shù)據(jù)中心，你可能會花很多時間與錢來避免硬件故障與網(wǎng)絡(luò)分割問題譬涡，這是另一種情況了闪幽；但是在云計算平臺中，如AWS涡匀，會產(chǎn)生不同的問題以及不同的解決方式盯腌。當(dāng)你實際使用時你就會明白，但是陨瘩，你最好提前應(yīng)對它們（注：指的是上一節(jié)說的意外故障腕够、高延遲與網(wǎng)絡(luò)分割問題）的發(fā)生。

ZooKeeper作為發(fā)現(xiàn)服務(wù)的問題

ZooKeeper（注：ZooKeeper是著名Hadoop的一個子項目舌劳，旨在解決大規(guī)模分布式應(yīng)用場景下帚湘，服務(wù)協(xié)調(diào)同步（Coordinate Service）的問題；它可以為同在一個分布式系統(tǒng)中的其他服務(wù)提供：統(tǒng)一命名服務(wù)蒿囤、配置管理客们、分布式鎖服務(wù)、集群管理等功能）是個偉大的開源項目材诽，它很成熟底挫，有相當(dāng)大的社區(qū)來支持它的發(fā)展，而且在生產(chǎn)環(huán)境得到了廣泛的使用脸侥；但是用它來做Service發(fā)現(xiàn)服務(wù)解決方案則是個錯誤建邓。

在分布式系統(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ò)分割具備容錯性；但是它不能保證每次服務(wù)請求的可用性（注：也就是在極端環(huán)境下诡渴，ZooKeeper可能會丟棄一些請求捐晶，消費者程序需要重新請求才能獲得結(jié)果）。但是別忘了妄辩，ZooKeeper是分布式協(xié)調(diào)服務(wù)惑灵，它的職責(zé)是保證數(shù)據(jù)（注：配置數(shù)據(jù)，狀態(tài)數(shù)據(jù)）在其管轄下的所有服務(wù)之間保持同步眼耀、一致英支；所以就不難理解為什么ZooKeeper被設(shè)計成CP而不是AP特性的了，如果是AP的哮伟，那么將會帶來恐怖的后果（注：ZooKeeper就像交叉路口的信號燈一樣干花，你能想象在交通要道突然信號燈失靈的情況嗎？）楞黄。而且把敢，作為ZooKeeper的核心實現(xiàn)算法Zab，就是解決了分布式系統(tǒng)下數(shù)據(jù)如何在多個服務(wù)之間保持同步問題的谅辣。

作為一個分布式協(xié)同服務(wù)修赞，ZooKeeper非常好，但是對于Service發(fā)現(xiàn)服務(wù)來說就不合適了桑阶；因為對于Service發(fā)現(xiàn)服務(wù)來說就算是返回了包含不實的信息的結(jié)果也比什么都不返回要好柏副；再者，對于Service發(fā)現(xiàn)服務(wù)而言蚣录，寧可返回某服務(wù)5分鐘之前在哪幾個服務(wù)器上可用的信息割择，也不能因為暫時的網(wǎng)絡(luò)故障而找不到可用的服務(wù)器，而不返回任何結(jié)果。所以說，用ZooKeeper來做Service發(fā)現(xiàn)服務(wù)是肯定錯誤的激况，如果你這么用就慘了！

而且更何況玛歌，如果被用作Service發(fā)現(xiàn)服務(wù)，ZooKeeper本身并沒有正確的處理網(wǎng)絡(luò)分割的問題擎椰；而在云端支子，網(wǎng)絡(luò)分割問題跟其他類型的故障一樣的確會發(fā)生；所以最好提前對這個問題做好100%的準(zhǔn)備达舒。就像Jepsen在ZooKeeper網(wǎng)站上發(fā)布的博客中所說：在ZooKeeper中值朋，如果在同一個網(wǎng)絡(luò)分區(qū)（partition）的節(jié)點數(shù)（nodes）數(shù)達(dá)不到ZooKeeper選取Leader節(jié)點的“法定人數(shù)”時叹侄，它們就會從ZooKeeper中斷開，當(dāng)然同時也就不能提供Service發(fā)現(xiàn)服務(wù)了昨登。

如果給ZooKeeper加上客戶端緩存（注：給ZooKeeper節(jié)點配上本地緩存）或者其他類似技術(shù)的話可以緩解ZooKeeper因為網(wǎng)絡(luò)故障造成節(jié)點同步信息錯誤的問題趾代。Pinterest與Airbnb公司就使用了這個方法來防止ZooKeeper故障發(fā)生。這種方式可以從表面上解決這個問題丰辣，具體地說稽坤，當(dāng)部分或者所有節(jié)點跟ZooKeeper斷開的情況下，每個節(jié)點還可以從本地緩存中獲取到數(shù)據(jù)糯俗；但是，即便如此睦擂，ZooKeeper下所有節(jié)點不可能保證任何時候都能緩存所有的服務(wù)注冊信息得湘。如果ZooKeeper下所有節(jié)點都斷開了，或者集群中出現(xiàn)了網(wǎng)絡(luò)分割的故障（注：由于交換機(jī)故障導(dǎo)致交換機(jī)底下的子網(wǎng)間不能互訪）顿仇；那么ZooKeeper會將它們都從自己管理范圍中剔除出去淘正，外界就不能訪問到這些節(jié)點了，即便這些節(jié)點本身是“健康”的臼闻，可以正常提供服務(wù)的鸿吆；所以導(dǎo)致到達(dá)這些節(jié)點的服務(wù)請求被丟失了。（注：這也是為什么ZooKeeper不滿足CAP中A的原因）

更深層次的原因是述呐，ZooKeeper是按照CP原則構(gòu)建的惩淳，也就是說它能保證每個節(jié)點的數(shù)據(jù)保持一致，而為ZooKeeper加上緩存的做法的目的是為了讓ZooKeeper變得更加可靠（available）乓搬；但是思犁，ZooKeeper設(shè)計的本意是保持節(jié)點的數(shù)據(jù)一致，也就是CP进肯。所以激蹲，這樣一來，你可能既得不到一個數(shù)據(jù)一致的（CP）也得不到一個高可用的（AP）的Service發(fā)現(xiàn)服務(wù)了江掩；因為学辱，這相當(dāng)于你在一個已有的CP系統(tǒng)上強(qiáng)制栓了一個AP的系統(tǒng)，這在本質(zhì)上就行不通的环形！一個Service發(fā)現(xiàn)服務(wù)應(yīng)該從一開始就被設(shè)計成高可用的才行策泣！

如果拋開CAP原理不管，正確的設(shè)置與維護(hù)ZooKeeper服務(wù)就非常的困難抬吟；錯誤會經(jīng)常發(fā)生着降，導(dǎo)致很多工程被建立只是為了減輕維護(hù)ZooKeeper的難度。這些錯誤不僅存在與客戶端而且還存在于ZooKeeper服務(wù)器本身拗军。Knewton平臺很多故障就是由于ZooKeeper使用不當(dāng)而導(dǎo)致的任洞。那些看似簡單的操作蓄喇，如：正確的重建觀察者（reestablishing watcher）、客戶端Session與異常的處理與在ZK窗口中管理內(nèi)存都是非常容易導(dǎo)致ZooKeeper出錯的交掏。同時妆偏，我們確實也遇到過ZooKeeper的一些經(jīng)典bug：ZooKeeper-1159 與ZooKeeper-1576；我們甚至在生產(chǎn)環(huán)境中遇到過ZooKeeper選舉Leader節(jié)點失敗的情況盅弛。這些問題之所以會出現(xiàn)钱骂，在于ZooKeeper需要管理與保障所管轄服務(wù)群的Session與網(wǎng)絡(luò)連接資源（注：這些資源的管理在分布式系統(tǒng)環(huán)境下是極其困難的）；但是它不負(fù)責(zé)管理服務(wù)的發(fā)現(xiàn)挪鹏，所以使用ZooKeeper當(dāng)Service發(fā)現(xiàn)服務(wù)得不償失见秽。

做出正確的選擇：Eureka的成功

我們把Service發(fā)現(xiàn)服務(wù)從ZooKeeper切換到了Eureka平臺，它是一個開源的服務(wù)發(fā)現(xiàn)解決方案讨盒，由Netflix公司開發(fā)解取。（注：Eureka由兩個組件組成：Eureka服務(wù)器和Eureka客戶端。Eureka服務(wù)器用作服務(wù)注冊服務(wù)器返顺。Eureka客戶端是一個java客戶端禀苦，用來簡化與服務(wù)器的交互、作為輪詢負(fù)載均衡器遂鹊，并提供服務(wù)的故障切換支持振乏。）Eureka一開始就被設(shè)計成高可用與可伸縮的Service發(fā)現(xiàn)服務(wù)，這兩個特點也是Netflix公司開發(fā)所有平臺的兩個特色秉扑。（他們都在討論Eureka）慧邮。自從切換工作開始到現(xiàn)在，我們實現(xiàn)了在生產(chǎn)環(huán)境中所有依賴于Eureka的產(chǎn)品沒有下線維護(hù)的記錄舟陆。我們也被告知過赋咽，在云平臺做服務(wù)遷移注定要遇到失敗吨娜；但是我們從這個例子中得到的經(jīng)驗是脓匿，一個優(yōu)秀的Service發(fā)現(xiàn)服務(wù)在其中發(fā)揮了至關(guān)重要的作用！

首先宦赠，在Eureka平臺中陪毡，如果某臺服務(wù)器宕機(jī)，Eureka不會有類似于ZooKeeper的選舉leader的過程勾扭；客戶端請求會自動切換到新的Eureka節(jié)點毡琉；當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后，Eureka會再次將其納入到服務(wù)器集群管理之中妙色；而對于它來說桅滋，所有要做的無非是同步一些新的服務(wù)注冊信息而已。所以，再也不用擔(dān)心有“掉隊”的服務(wù)器恢復(fù)以后丐谋，會從Eureka服務(wù)器集群中剔除出去的風(fēng)險了芍碧。Eureka甚至被設(shè)計用來應(yīng)付范圍更廣的網(wǎng)絡(luò)分割故障，并實現(xiàn)“0”宕機(jī)維護(hù)需求号俐。當(dāng)網(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)與訪問猪落。

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

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

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

Eureka的構(gòu)架保證了它能夠成為Service發(fā)現(xiàn)服務(wù)。它相對與ZooKeeper來說剔除了Leader節(jié)點的選取或者事務(wù)日志機(jī)制漓帚，這樣做有利于減少使用者維護(hù)的難度也保證了Eureka的在運行時的健壯性母债。而且Eureka就是為發(fā)現(xiàn)服務(wù)所設(shè)計的，它有獨立的客戶端程序庫尝抖，同時提供心跳服務(wù)毡们、服務(wù)健康監(jiān)測、自動發(fā)布服務(wù)與自動刷新緩存的功能昧辽。但是衙熔，如果使用ZooKeeper你必須自己來實現(xiàn)這些功能。Eureka的所有庫都是開源的搅荞，所有人都能看到與使用這些源代碼红氯，這比那些只有一兩個人能看或者維護(hù)的客戶端庫要好。

維護(hù)Eureka服務(wù)器也非常的簡單咕痛，比如痢甘，切換一個節(jié)點只需要在現(xiàn)有EIP下移除一個現(xiàn)有的節(jié)點然后添加一個新的就行。Eureka提供了一個web-based的圖形化的運維界面茉贡，在這個界面中可以查看Eureka所管理的注冊服務(wù)的運行狀態(tài)信息：是否健康塞栅，運行日志等。Eureka甚至提供了Restful-API接口腔丧，方便第三方程序集成Eureka的功能构蹬。

結(jié)論

關(guān)于Service發(fā)現(xiàn)服務(wù)通過本文我們想說明兩點：1、留意服務(wù)運行的硬件平臺悔据；2庄敛、時刻關(guān)注你要解決的問題，然后決定使用什么平臺科汗。Knewton就是從這兩個方面考慮使用Eureka替換ZooKeeper來作為service發(fā)現(xiàn)服務(wù)的藻烤。云部署平臺是充滿不可靠性的，Eureka可以應(yīng)對這些缺陷；同時Service發(fā)現(xiàn)服務(wù)必須同時具備高可靠性與高彈性怖亭，Eureke就是我們想要的涎显！