首先再說為什麼之前...

我們先來了解下ZooKeeper是什麼...

ZooKeeper是Apache基金會下的一個開源的

高可用的分散式應用協調服務

許多公司都把它用於服務發現....

        但在雲環境中，面對裝置及網路故障時的恢復能力是需要重點考慮的問題。因此，將應用部署在雲上，就必須要預見到硬體故障、網路延遲以及網路分割槽等問題，進而構建出恢復能力強的系統。那為什麼說把ZooKeeper用於服務發現是個錯誤的做法呢...理由如下

        在ZooKeeper中，網路分割槽中的客戶端節點無法到達Quorum時，就會與ZooKeeper失去聯絡，從而也就無法使用其服務發現機制。因此，在用於服務發現時，ZooKeeper無法很好地處理網路分割槽問題。作為一個協調服務，這沒問題。但對於服務發現來說，資訊中可能包含錯誤要好於沒有資訊。雖然可以通過客戶端快取和其它技術彌補這種缺陷，像Pinterest和Airbnb等公司所做的那樣，但這並不能從根本上解決問題，如果Quorum完全不可用，或者叢集分割槽和客戶端都恰好連線到了不屬於這個Quorum但仍然健康的節點，那麼客戶端狀態仍將丟失。    

        更重要地，上述做法的本質是試圖用快取提高一個一致性系統的可用性，即在一個CP系統之上構建AP系統，這根本就是錯誤的方法。服務發現系統從設計之初就應該針對可用性而設計。

        拋開CAP理論不說，ZooKeeper的設定和維護非常困難，以致Knewton多次因為錯誤的使用出現問題。一些看似很簡單的事情，實際操作起來也非常容易出錯，如在客戶端重建Watcher，處理Session和異常。另外，ZooKeeper本身確實也存在一些問題，如ZOOKEEPER-1159、ZOOKEEPER-1576。

由於這些問題的存在，他們切換到了Eureka。這是一個由Netflix開發的、開源的服務發現解決方案，具有可用性高、恢復能力強的特點。相比之下...它有如下優點....

        如果一個伺服器出現問題，Eureka不需要任何型別的選舉，客戶端會自動切換並連線到一個新的Eureka伺服器。當它恢復時，可以自動加入Eureka節點叢集。而且，按照設計，它可以在零停機的情況下處理更廣泛的網路分割槽問題。在出現網路分割槽的情況下，Eureka將繼續接受新的註冊併發布。這可以確保新增服務仍然可以供分割槽同側的任意客戶端使用。

        Eureka有一個服務心跳的概念，可以阻止過期資料：如果一個服務長時間沒有傳送心跳，那麼Eureka將從服務註冊中將其刪除。但在出現網路分割槽、Eureka在短時間內丟失過多客戶端時，它會停用這一機制，進入“自我保護模式”。網路恢復後，它又會自動退出該模式。這樣，雖然它保留的資料中可能存在錯誤，卻不會丟失任何有效資料。

        Eureka在客戶端會有快取。即使所有Eureka伺服器不可用，服務註冊資訊也不會丟失。快取在這裡是恰當的，因為它只在所有Eureka伺服器都沒響應的情況下才會用到。 Eureka就是為服務發現而構建的。它提供了一個客戶端庫，該庫提供了服務心跳、服務健康檢查、自動釋出及快取重新整理等功能。使用ZooKeeper，這些功能都需要自己實現。

        管理簡單，很容易新增和刪除節點。它還提供了一個清晰簡潔的網頁，上面列出了所有的服務及其健康狀況。

         Eureka還提供了REST API，使使用者可以將其整合到其它可能的用途和查詢機制。

總之，雲平臺並不總是可靠...

服務發現需要具備儘可能高的可用性和恢復能力...

而Eureka恰恰是針對這種情況而設計的...

給大家推薦一個程式設計師學習交流群：863621962。群裡有分享的視訊，還有思維導圖 群公告有視訊，都是乾貨的，你可以下載來看。主要分享分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊。