為什麼不應該使用ZooKeeper做服務發現
為什麼不應該使用ZooKeeper做服務發現 【編者的話】本文作者通過ZooKeeper與Eureka作為 Service發現服務 （注：WebServices體系中的UDDI就是個發現服務）的優劣對比，分享了Knewton在雲計算平台部署服務的經驗。 本文雖然略顯偏激，但是看得出Knewton在雲平台方面是非常有經驗的，這篇文章從實踐角度出發分別從雲平台特點、CAP原理以及運維三個方面對比了ZooKeeper與Eureka兩個系統作為發布服務的優劣，並提出了在雲平台構建發現服務的方法論。 背景 很多公司選擇使用 ZooKeeper 作為Service發現服務（Service Discovery），但是在構建 Knewton （Knewton是一個提供個性化教育平台的公司、學校和出版商可以通過Knewton平台為學生提供自適應的學習材料）平台時，我們發現這是個根本性的錯誤。 在這邊文章中，我們將用我們在實踐中遇到的問題來說明，為什麼使用ZooKeeper做Service發現服務是個錯誤。 請留意服務部署環境 讓我們從頭開始梳理。 我們在部署服務的時候，應該首先考慮服務部署的平台（平台環境），然後才能考慮平台上跑的軟件系統或者如何在選定的平台上自己構建一套系統。 例如，對於雲部署平台來說，平台在硬件層面的伸縮（注：作者應該指的是系統的冗餘性設計，即係統遇到單點失效問題，能夠快速切換到其他節點完成任務）與如何應對網絡故障是首先要考慮的。 當你的服務運行在大量服務器構建的集群之上時（注：原話為大量可替換設備），則肯定會出現單點故障的問題。 對於knewton來說，我們雖然是部署在AWS上的，但是在過往的運維中，我們也遇到過形形色色的故障；所以，你應該把系統設計成“故障開放型”（expecting failure）的。 其實有很多同樣使用AWS的 公司 跟我們遇到了（同時有很多 書 是介紹這方面的）相似的問題。 你必須能夠提前預料到平台可能會出現的問題如：意外故障（注：原文為box failure，只能意會到作者指的是意外彈出的錯誤提示框），高延遲與 網絡分割問題 （注：原文為network partitions。意思是當網絡交換機出故障會導致不同子網間通訊中斷）——同時我們要能構建足夠彈性的系統來應對它們的發生。 ...