爲何不要把ZooKeeper用於服務發現

ZooKeeper是Apache基金會下的一個開源的、高可用的分佈式應用協調服務。許多公司都把它用於服務發現。但在雲環境中，面對設備及網絡故障時的恢復能力是須要重點考慮的問題。所以，將應用部署在雲上，就必需要預見到硬件故障、網絡延遲以及網絡分區等問題，進而構建出恢復能力強的系統。Peter Kelley是個性化教育初創公司Knewton的一名軟件工程師。他認爲，從根本上講，把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偏偏是針對這種狀況而設計的。