服務發現：Zookeeper vs etcd vs Consul

本文對比了Zookeeper、etcd和Consul三種服務發現工具，探討了最佳的服務發現解決方案，僅供參考。

若是使用預約義的端口，服務越多，發生衝突的可能性越大，畢竟，不可能有兩個服務監聽同一個端口。管理一個擁擠的比方說被幾百個服務所使用的全部端口的列表，自己就是一個挑戰，添加到該列表後，這些服務須要的數據庫和數量會日益增多。所以咱們應該部署無需指定端口的服務，而且讓Docker爲咱們分配一個隨機的端口。惟一的問題是咱們須要發現端口號，而且讓別人知道。

當咱們開始在一個分佈式系統上部署服務到其中一臺服務器上時，事情會變得更加複雜，咱們能夠選擇預先定義哪臺服務器運行哪一個服務的方式，但這會致使不少問題。咱們應該盡咱們所能儘可能利用服務器資源，可是若是預先定義每一個服務的部署位置，那麼要實現儘可能利用服務器資源是幾乎不可能的。另外一個問題是服務的自動伸縮將會很是困難，更不用說自動恢復了，比方說服務器故障。另外一方面，若是咱們將服務部署到某臺只有最少數量的容器在運行的服務器上，咱們須要添加IP地址到數據列表中，這些數據須要能夠被發現並存儲在某處。

當咱們須要存儲和發現一些與正在工做的服務相關的信息時，還有不少其餘的例子。

爲了可以定位服務，咱們須要至少接下來的兩個有用的步驟。
服務註冊——該步驟存儲的信息至少包括正在運行的服務的主機和端口信息
服務發現——該步驟容許其餘用戶能夠發如今服務註冊階段存儲的信息。

除了上述的步驟，咱們還須要考慮其餘方面。若是一個服務中止工做並部署/註冊了一個新的服務實例，那麼該服務是否應該註銷呢？當有相同服務的多個副本時咋辦？咱們該如何作負載均衡呢？若是一個服務器宕機了咋辦？全部這些問題都與註冊和發現階段緊密關聯。如今，咱們限定只在服務發現的範圍裏（常見的名字，圍繞上述步驟）以及用於服務發現任務的工具，它們中的大多數採用了高可用的分佈式鍵/值存儲。
服務發現工具

服務發現工具的主要目標是用來服務查找和相互對話，爲此該工具須要知道每一個服務，這不是一個新概念，在Docker以前就已經存在不少相似的工具了，然而，容器帶給了這些工具一個全新水平的需求。

服務發現背後的基本思想是對於服務的每個新實例（或應用程序），可以識別當前環境和存儲相關信息。存儲的註冊表信息自己一般採用鍵/值對的格式，因爲服務發現常常用於分佈式系統，因此要求這些信息可伸縮、支持容錯和分佈式集羣中的全部節點。這種存儲的主要用途是給全部感興趣的各方提供最起碼諸如服務IP地址和端口這樣的信息，用於它們之間的相互通信，這些數據還常常擴展到其它類型的信息服務發現工具傾向於提供某種形式的API，用於服務自身的註冊以及服務信息的查找。

比方說咱們有兩個服務，一個是提供方，另外一個是第一個服務的消費者，一旦部署了服務提供方，就須要在服務發現註冊表中存儲其信息。接着，當消費者試圖訪問服務提供者時，它首先查詢服務註冊表，使用獲取到的IP地址和端口來調用服務提供者。爲了與註冊表中的服務提供方的具體實現解耦，咱們經常採用某種代理服務。這樣消費者老是向固定IP地址的代理請求信息，代理再依次使用服務發現來查×××提供方信息並重定向請求，在本文中咱們稍後經過反向代理來實現。如今重要的是要理解基於三種角色（服務消費者、提供者和代理）的服務發現流程。

服務發現工具要查找的是數據，至少咱們應該可以找出服務在哪裏？服務是否健康和可用？配置是什麼樣的？既然咱們正在多臺服務器上構建一個分佈式系統，那麼該工具須要足夠健壯，保證其中一個節點的宕機不會危及數據，同時，每一個節點應該有徹底相同的數據副本，進一步地，咱們但願可以以任何順序啓動服務、殺死服務或者替換服務的新版本，咱們還應該可以從新配置服務而且查看到數據相應的變化。

讓咱們看一下一些經常使用的選項來完成咱們上面設定的目標。
手動配置

大多數服務仍然是須要手動管理的，咱們預先決定在何處部署服務、如何配置和但願無論什麼緣由，服務都將繼續正常工做，直到天荒地老。這樣的目標不是能夠輕易達到的。部署第二個服務實例意味着咱們須要啓動全程的手動處理，咱們須要引入一臺新的服務器，或者找出哪一臺服務器資源利用率較低，而後建立一個新的配置集並啓動服務。狀況或許會變得愈來愈複雜，比方說，硬件故障致使的手動管理下的反應時間變得很慢。可見性是另一個痛點，咱們知道什麼是靜態配置，畢竟是咱們預先準備好的，然而，大多數的服務有不少動態生成的信息，這些信息不是輕易可見的，也沒有一個單獨的地方供咱們在須要時參考這些數據。

反應時間會不可避免的變慢，鑑於存在許多須要手動處理的移動組件，故障恢復和監控也會變得很是難以管理。

儘管在過去或者當服務/服務器數量不多的時候有藉口不作這項工做，隨着服務發現工具的出現，這個藉口已經不存在了。
Zookeeper

Zookeeper是這種類型的項目中歷史最悠久的之一，它起源於Hadoop，幫助在Hadoop集羣中維護各類組件。它很是成熟、可靠，被許多大公司（YouTube、eBay、雅虎等）使用。其數據存儲的格式相似於文件系統，若是運行在一個服務器集羣中，Zookeper將跨全部節點共享配置狀態，每一個集羣選舉一個領袖，客戶端能夠鏈接到任何一臺服務器獲取數據。

Zookeeper的主要優點是其成熟、健壯以及豐富的特性，然而，它也有本身的缺點，其中採用Java開發以及複雜性是罪魁禍首。儘管Java在許多方面很是偉大，而後對於這種類型的工做仍是太沉重了，Zookeeper使用Java以及至關數量的依賴使其對於資源競爭很是飢渴。由於上述的這些問題，Zookeeper變得很是複雜，維護它須要比咱們指望從這種類型的應用程序中得到的收益更多的知識。這部分地是因爲豐富的特性反而將其從優點轉變爲累贅。應用程序的特×××越多，就會有越大的可能性不須要這些特性，所以，咱們最終將會爲這些不須要的特性付出複雜度方面的代價。

Zookeeper爲其餘項目至關大的改進鋪平了道路，「大數據玩家「在使用它，由於沒有更好的選擇。今天，Zookeeper已經老態龍鍾了，咱們有了更好的選擇。
etcd

etcd是一個採用HTTP協議的健/值對存儲系統，它是一個分佈式和功能層次配置系統，可用於構建服務發現系統。其很容易部署、安裝和使用，提供了可靠的數據持久化特性。它是安全的而且文檔也十分齊全。

etcd比Zookeeper是比更好的選擇，由於它很簡單，然而，它須要搭配一些第三方工具才能夠提供服務發現功能。

如今，咱們有一個地方來存儲服務相關信息，咱們還須要一個工具能夠自動發送信息給etcd。但在這以後，爲何咱們還須要手動把數據發送給etcd呢？即便咱們但願手動將信息發送給etcd，咱們一般狀況下也不會知道是什麼信息。記住這一點，服務可能會被部署到一臺運行最少數量容器的服務器上，而且隨機分配一個端口。理想狀況下，這個工具應該監視全部節點上的Docker容器，而且每當有新容器運行或者現有的一個容器中止的時候更新etcd，其中的一個能夠幫助咱們達成目標的工具就是Registrator。
Registrator

Registrator經過檢查容器在線或者中止運行狀態自動註冊和去註冊服務，它目前支持etcd、Consul和SkyDNS 2。

Registrator與etcd是一個簡單可是功能強大的組合，能夠運行不少先進的技術。每當咱們打開一個容器，全部數據將被存儲在etcd並傳播到集羣中的全部節點。咱們將決定什麼信息是咱們的。

上述的拼圖遊戲還缺乏一塊，咱們須要一種方法來建立配置文件，與數據都存儲在etcd，經過運行一些命令來建立這些配置文件。
Confd

Confd是一個輕量級的配置管理工具，常見的用法是經過使用存儲在etcd、consul和其餘一些數據登記處的數據保持配置文件的最新狀態，它也能夠用來在配置文件改變時從新加載應用程序。換句話說，咱們能夠用存儲在etcd（或者其餘註冊中心）的信息來從新配置全部服務。

對於etcd、Registrator和Confd組合的最後的思考

當etcd、Registrator和Confd結合時，能夠得到一個簡單而強大的方法來自動化操做咱們全部的服務發現和須要的配置。這個組合還展現了「小」工具正確組合的有效性，這三個小東西能夠如咱們所願正好完成咱們須要達到的目標，若範圍稍微小一些，咱們將沒法完成咱們面前的目標，而另外一方面若是他們設計時考慮到更大的範圍，咱們將引入沒必要要的複雜性和服務器資源開銷。

在咱們作出最後的判決以前，讓咱們看看另外一個有相同目標的工具組合，畢竟，咱們不該該知足於一些沒有可替代方案的選擇。
Consul

Consul是強一致性的數據存儲，使用gossip造成動態集羣。它提供分級鍵/值存儲方式，不只能夠存儲數據，並且能夠用於註冊器件事各類任務，從發送數據改變通知到運行健康檢查和自定義命令，具體如何取決於它們的輸出。

與Zookeeper和etcd不同，Consul內嵌實現了服務發現系統，因此這樣就不須要構建本身的系統或使用第三方系統。這一發現系統除了上述提到的特性以外，還包括節點健康檢查和運行在其上的服務。

Zookeeper和etcd只提供原始的鍵/值隊存儲，要求應用程序開發人員構建他們本身的系統提供服務發現功能。而Consul提供了一個內置的服務發現的框架。客戶只須要註冊服務並經過DNS或HTTP接口執行服務發現。其餘兩個工具須要一個親手製做的解決方案或藉助於第三方工具。

Consul爲多種數據中心提供了開箱即用的原生支持，其中的gossip系統不只能夠工做在同一集羣內部的各個節點，並且還能夠跨數據中心工做。

Consul還有另外一個不錯的區別於其餘工具的功能，它不只能夠用來發現已部署的服務以及其駐留的節點信息，還經過HTTP請求、TTLs（time-to-live）和自定義命令提供了易於擴展的健康檢查特性。
Registrator

Registrator有兩個Consul協議，其中consulkv協議產生相似於etcd協議的結果。

除了一般的IP和端口存儲在etcd或consulkv協議中以外，Registrator consul協議存儲了更多的信息，咱們能夠獲得服務運行節點的信息，以及服務ID和名稱。咱們也能夠藉助於一些額外的環境變量按照必定的標記存儲額外的信息。

Consul-template

confd能夠像和etce搭配同樣用於Consul，不過Consul有本身的模板服務，其更適配Consul。

經過從Consul得到的信息，Consul-template是一個很是方便的建立文件的途徑，還有一個額外的好處就是在文件更新後能夠運行任意命令，正如confd，Consul-template也可使用Go模板格式。

Consul健康檢查、Web界面和數據中心

監控集羣節點和服務的健康狀態與測試和部署它們同樣的重要。雖然咱們應該向着擁有歷來沒有故障的穩定的環境努力，但咱們也應該認可，隨時會有意想不到的故障發生，時刻準備着採起相應的措施。例如咱們能夠監控內存使用狀況，若是達到必定的閾值，那麼遷移一些服務到集羣中的另一個節點，這將是在發生「災難」前執行的一個預防措施。另外一方面，並非全部潛在的故障均可以被及時檢測到並採起措施。單個服務可能會齒白，一個完整的節點也可能因爲硬件故障而中止工做。在這種狀況下咱們應該準備儘快行動，例如一個節點替換爲一個新的並遷移失敗的服務。Consul有一個簡單的、優雅的但功能強大的方式進行健康檢查，當健康閥值達到必定數目時，幫助用戶定義應該執行的操做。

若是用戶Google搜索「etcd ui」或者「etec dashboard」時，用戶可能看到只有幾個可用的解決方案，可能會問爲何咱們尚未介紹給用戶，這個緣由很簡單，etcd只是鍵/值對存儲，僅此而已。經過一個UI呈現數據沒有太多的用處，由於咱們能夠很容易地經過etcdctl得到這些數據。這並不意味着etcd UI是無用的，但鑑於其有限的使用範圍，它不會產生多大影響。

Consu不只僅是一個簡單的鍵/值對存儲，正如咱們已經看到的，除了存儲簡單的鍵/值對，它還有一個服務的概念以及所屬的數據。它還能夠執行健康檢查，所以成爲一個好的候選dashboard，在上面能夠看到咱們的節點的狀態和運行的服務。最後，它支持了多數據中心的概念。全部這些特性的結合讓咱們從不一樣的角度看到引入dashboard的必要性。

經過Consul Web界面，用戶能夠查看全部的服務和節點、監控健康檢查狀態以及經過切換數據中心讀取設置鍵/值對數據。

對於Consul、Registrator、Template、健康檢查和Web UI的最終思考

Consul以及上述咱們一塊兒探討的工具在不少狀況下提供了比etcd更好的解決方案。這是從心裏深處爲了服務架構和發現而設計的方案，簡單而強大。它提供了一個完整的同時不失簡潔的解決方案，在許多狀況下，這是最佳的服務發現以及知足健康檢查需求的工具。
結論

全部這些工具都是基於類似的原則和架構，它們在節點上運行，須要仲裁來運行，而且都是強一致性的，都提供某種形式的鍵/值對存儲。

Zookeeper是其中最老態龍鍾的一個，使用年限顯示出了其複雜性、資源利用和盡力達成的目標，它是爲了與咱們評估的其餘工具所處的不一樣時代而設計的（即便它不是老得太多）。

etcd、Registrator和Confd是一個很是簡單但很是強大的組合，能夠解決大部分問題，若是不是所有知足服務發現須要的話。它還展現了咱們能夠經過組合很是簡單和特定的工具來得到強大的服務發現能力，它們中的每個都執行一個很是具體的任務，經過精心設計的API進行通信，具有相對自治工做的能力，從架構和功能途徑方面都是微服務方式。

Consul的不一樣之處在於無需第三方工具就能夠原生支持多數據中心和健康檢查，這並不意味着使用第三方工具很差。實際上，在這篇博客裏咱們經過選擇那些表現更佳同時不會引入沒必要要的功能的的工具，盡力組合不一樣的工具。使用正確的工具能夠得到最好的結果。若是工具引入了工做不須要的特性，那麼工做效率反而會降低，另外一方面，若是工具沒有提供工做所須要的特性也是沒有用的。Consul很好地權衡了權重，用盡可能少的東西很好的達成了目標。

Consul使用gossip來傳播集羣信息的方式，使其比etcd更易於搭建，特別是對於大的數據中心。將存儲數據做爲服務的能力使其比etcd僅僅只有健/值對存儲的特性更加完整、更有用（即便Consul也有該選項）。雖然咱們能夠在etcd中經過插入多個鍵來達成相同的目標，Consul的服務實現了一個更緊湊的結果，一般只須要一次查詢就能夠得到與服務相關的全部數據。除此以外，Registrator很好地實現了Consul的兩個協議，使其合二爲一，特別是添加Consul-template到了拼圖中。Consul的Web UI更是錦上添花般地提供了服務和健康檢查的可視化途徑。

我不能說Consul是一個明確的贏家，而是與etcd相比其有一個輕微的優點。服務發現做爲一個概念，以及做爲工具都很新，咱們能夠期待在這一領域會有許多的變化。秉承開放的心態，你們能夠對本文的建議持保留態度，嘗試不一樣的工具而後作出本身的結論。本文出自http://dockone.io/article/667