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

　　背景

很多公司選擇使用 ZooKeeper作為Service發(fā)現(xiàn)服務(Service Discovery)，但是在構建 Knewton(Knewton 是一個提供個性化教育平臺的公司、學校和出版商可以通過Knewton平臺為學生提供自適應的學習材料)平臺時，我們發(fā)現(xiàn)這是個根本性的錯誤。在這邊文章 中，我們將用我們在實踐中遇到的問題來說明，為什么使用ZooKeeper做Service發(fā)現(xiàn)服務是個錯誤。

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

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

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

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

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

在分布式系統(tǒng)領域有個著名的 CAP定理(C- 數(shù)據(jù)一致性;A-服務可用性;P-服務對網(wǎng)絡分區(qū)故障的容錯性，這三個特性在任何分布式系統(tǒng)中不能同時滿足，最多同時滿足兩個);ZooKeeper是個 CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數(shù)據(jù)結(jié)果，同時系統(tǒng)對網(wǎng)絡分割具備容錯性;但是它不能保證每次服務請求的可用性(注：也就 是在極端環(huán)境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結(jié)果)。但是別忘了，ZooKeeper是分布式協(xié)調(diào)服務，它的 職責是保證數(shù)據(jù)(注：配置數(shù)據(jù)，狀態(tài)數(shù)據(jù))在其管轄下的所有服務之間保持同步、一致;所以就不難理解為什么ZooKeeper被設計成CP而不是AP特性 的了，如果是AP的，那么將會帶來恐怖的后果(注：ZooKeeper就像交叉路口的信號燈一樣，你能想象在交通要道突然信號燈失靈的情況嗎?)。而且， 作為ZooKeeper的核心實現(xiàn)算法 Zab，就是解決了分布式系統(tǒng)下數(shù)據(jù)如何在多個服務之間保持同步問題的。

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

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

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

更深層次的原因是，ZooKeeper是按照CP原則構建的，也就是說它能保證每個節(jié)點的數(shù)據(jù)保持一致，而為ZooKeeper加上緩存的做法的 目的是為了讓ZooKeeper變得更加可靠(available);但是，ZooKeeper設計的本意是保持節(jié)點的數(shù)據(jù)一致，也就是CP。所以，這樣 一來，你可能既得不到一個數(shù)據(jù)一致的(CP)也得不到一個高可用的(AP)的Service發(fā)現(xiàn)服務了;因為，這相當于你在一個已有的CP系統(tǒng)上強制栓了 一個AP的系統(tǒng)，這在本質(zhì)上就行不通的!一個Service發(fā)現(xiàn)服務應該從一開始就被設計成高可用的才行!

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

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

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

首先，在Eureka平臺中，如果某臺服務器宕機，Eureka不會有類似于ZooKeeper的選舉leader的過程;客戶端請求會自動切換 到新的Eureka節(jié)點;當宕機的服務器重新恢復后，Eureka會再次將其納入到服務器集群管理之中;而對于它來說，所有要做的無非是同步一些新的服務 注冊信息而已。所以，再也不用擔心有“掉隊”的服務器恢復以后，會從Eureka服務器集群中剔除出去的風險了。Eureka甚至被設計用來應付范圍更廣 的網(wǎng)絡分割故障，并實現(xiàn)“0”宕機維護需求。當網(wǎng)絡分割故障發(fā)生時，每個Eureka節(jié)點，會持續(xù)的對外提供服務(注：ZooKeeper不會)：接收新 的服務注冊同時將它們提供給下游的服務發(fā)現(xiàn)請求。這樣一來，就可以實現(xiàn)在同一個子網(wǎng)中(same side of partition)，新發(fā)布的服務仍然可以被發(fā)現(xiàn)與訪問。

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

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

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

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

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

結(jié)論

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