溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×

忘記密碼？

登錄注冊×

獲取短信驗證碼

其他方式登錄

點擊登錄注冊即表示同意《億速云用戶服務條款》

用戶登錄×

賬戶密碼登錄

請使用微信掃描上方二維碼

使用幫助

請求超時！

請點擊重新獲取二維碼

Eureka為什么會比ZooKeeper優秀

發布時間：2021-12-23 16:55:34 來源：億速云閱讀：143 作者：柒染欄目：大數據

本篇文章為大家展示了Eureka為什么會比ZooKeeper優秀，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

1. 前言

服務注冊中心，給客戶端提供可供調用的服務列表，客戶端在進行遠程服務調用時，根據服務列表然后選擇服務提供方的服務地址進行服務調用。服務注冊中心在分布式系統中大量應用，是分布式系統中不可或缺的組件，例如rocketmq的name server，hdfs中的namenode，dubbo中的zk注冊中心，spring cloud中的服務注冊中心eureka。

在spring cloud中，除了可以使用eureka作為注冊中心外，還可以通過配置的方式使用zookeeper作為注冊中心。既然這樣，我們該如何選擇注冊中心的實現呢？

著名的CAP理論指出，一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由于分區容錯性在是分布式系統中必須要保證的，因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。

2. Zookeeper保證CP

當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一致性。但是zk會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。在云部署的環境下，因網絡問題使得zk集群失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。

3. Eureka保證AP

Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊或如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的注冊信息會被同步到其它節點中

因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。

4. 更深入的探討

下面轉發一篇更深入探討zookeeper與eureka作為注冊中心區別的問題，文章轉發自

http://dockone.io/article/78 ，該文翻譯了國外的一篇文章。

4.1 為什么不應該使用ZooKeeper做服務發現

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

4.2 背景

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

4.3 請留意服務部署環境

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

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

4.4 ZooKeeper作為發現服務的問題

ZooKeeper（注：ZooKeeper是著名Hadoop的一個子項目，旨在解決大規模分布式應用場景下，服務協調同步（Coordinate Service）的問題；它可以為同在一個分布式系統中的其他服務提供：統一命名服務、配置管理、分布式鎖服務、集群管理等功能）是個偉大的開源項目，它很成熟，有相當大的社區來支持它的發展，而且在生產環境得到了廣泛的使用；但是用它來做Service發現服務解決方案則是個錯誤。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關于Service發現服務通過本文我們想說明兩點：

1、留意服務運行的硬件平臺；

2、時刻關注你要解決的問題，然后決定使用什么平臺。Knewton就是從這兩個方面考慮使用Eureka替換ZooKeeper來作為service發現服務的。云部署平臺是充滿不可靠性的，Eureka可以應對這些缺陷；同時Service發現服務必須同時具備高可靠性與高彈性，Eureke就是我們想要的！

上述內容就是Eureka為什么會比ZooKeeper優秀，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。

向AI問一下細節

推薦閱讀：

免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。

上一篇新聞：
如何進行數據湖deltalake中的時間旅行及版本管理
下一篇新聞：
mysql中出現1053錯誤怎么辦

猜你喜歡

AI
助
手

產品服務

地區劃分

專題活動

幫助支持

關于我們

售后咨詢

7*24小時在線電話：400-100-2938

7*24小時在線 QQ：800811969

關注億速云

億速云公眾號

手機網站二維碼

亚洲午夜精品一区二区_中文无码日韩欧免_久久香蕉精品视频_欧美主播一区二区三区美女