Eureka與ZooKeeper對比，Eureka的優勢
為什麼不應該使用ZooKeeper做服務發現
背景
很多公司選擇使用ZooKeeper作為Service發現服務（Service Discovery），但是在構建Knewton（Knewton是一個提供個性化教育平臺的公司、學校和出版商可以通過Knewton平臺為學生提供自適應的學習材料）平臺時，我們發現這是個根本性的錯誤。在這邊文章中，我們將用我們在實踐中遇到的問題來說明，為什麼使用ZooKeeper做Service發現服務是個錯誤。
請留意服務部署環境
讓我們從頭開始梳理。我們在部署服務的時候，應該首先考慮服務部署的平臺（平臺環境），然後才能考慮平臺上跑的軟體系統或者如何在選定的平臺上自己構建一套系統。例如，對於雲部署平臺來說，平臺在硬體層面的伸縮（注：作者應該指的是系統的冗餘性設計，即系統遇到單點失效問題，能夠快速切換到其他節點完成任務）與如何應對網路故障是首先要考慮的。當你的服務執行在大量伺服器構建的叢集之上時（注：原話為大量可替換裝置），則肯定會出現單點故障的問題。對於knewton來說，我們雖然是部署在AWS上的，但是在過往的運維中，我們也遇到過形形色色的故障；所以，你應該把系統設計成“故障開放型”（expecting failure）的。其實有很多同樣使用AWS的
永遠不要期望你部署服務的平臺跟其他人是一樣的！當然，如果你在獨自運維一個數據中心，你可能會花很多時間與錢來避免硬體故障與網路分割問題，這是另一種情況了；但是在雲端計算平臺中，如AWS，會產生不同的問題以及不同的解決方式。當你實際使用時你就會明白，但是，你最好提前應對它們（注：指的是上一節說的意外故障、高延遲與網路分割問題）的發生。
ZooKeeper作為發現服務的問題
ZooKeeper（注：ZooKeeper是著名Hadoop的一個子專案，旨在解決大規模分散式應用場景下，服務協調同步（Coordinate Service）的問題；它可以為同在一個分散式系統中的其他服務提供：統一命名服務、配置管理、分散式鎖服務、叢集管理等功能）是個偉大的開源專案，它很成熟，有相當大的社群來支援它的發展，而且在生產環境得到了廣泛的使用；但是用它來做Service發現服務解決方案則是個錯誤。
在分散式系統領域有個著名的CAP定理（C-資料一致性；A-服務可用性；P-服務對網路分割槽故障的容錯性，這三個特性在任何分散式系統中不能同時滿足，最多同時滿足兩個）；ZooKeeper是個CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的資料結果，同時系統對網路分割具備容錯性；但是它不能保證每次服務請求的可用性（注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程式需要重新請求才能獲得結果）。但是別忘了，ZooKeeper是分散式協調服務，它的職責是保證資料（注：配置資料，狀態資料）在其管轄下的所有服務之間保持同步、一致；所以就不難理解為什麼ZooKeeper被設計成CP而不是AP特性的了，如果是AP的，那麼將會帶來恐怖的後果（注：ZooKeeper就像交叉路口的訊號燈一樣，你能想象在交通要道突然訊號燈失靈的情況嗎？）。而且，作為ZooKeeper的核心實現演算法
作為一個分散式協同服務，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發現服務得不償失。
做出正確的選擇：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的功能。
結論
我們來比較一下，在CAP理論中，zk更看重C和P，即一致性和分割槽容錯性。但Eureka更在意的是A和P，A為高可用。zk中有master和follower區別，當進入選舉模式時，就無法正常對外提供服務。但Eureka中，叢集是對等的，地位是相同的，雖不能保證一致性，但至少可以提供註冊服務。 根據不同的業務場景，各有取捨吧。