為什麼不應該使用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。意思是當網絡交換機出故障會導致不同子網間通訊中斷）——同時我們要能構建足夠彈性的系統來應對它們的發生。

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

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發現服務得不償失。

做出正確的選擇：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就是我們想要的！

補充閱讀


0
分享 2014-12-25

留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容