Consul和ZooKeeper、Doozerd、Etcd的區別
Consul是一個在國外流行的服務發現和配置共享的服務軟件。本文翻譯自Consul的官方文檔，文中重點講述：在與主流同類軟件ZooKeeper、Doozerd以及Etcd比較時，Consul的優勢所在。
ZooKeeper、Doozerd、Etcd在架構上都非常相似，它們都有服務節點（server
node），而這些服務節點的操作都要求達到節點的仲裁數（通常，節點的仲裁數遵循的是簡單多數原則）。此外，它們都是強一致性的，并且提供各種原語。通
過應用程序內部的客戶端lib庫，這些原語可以用來構建復雜的分布式系統。
Consul在一個單一的數據中心內部使用服務節點。在每個數據中心中，為了Consule能夠運行，并且保持強一致性，Consul服務端需要仲裁。然而，Consul原生支持多數據中心，就像一個豐富gossip系統連接服務器節點和客戶端一樣。
當提供K/V存儲的時候，這些系統具有大致相同的語義，讀取是強一致性的，并且在面對網絡分區的時候，為了保持一致性，讀取的可用性是可以犧牲的。然而，當系統應用于復雜情況時，這種差異會變得更加明顯。
這些系統提供的語義對開發人員構建服務發現系統很有吸引力，但更重要的是，強調開發人員要構建這些特性。ZooKeeper只提供一個原始的
K/V值存儲，并要求開發人員構建他們自己的系統來提供服務發現功能。相反的是，Consul提供了一個堅固的框架，這不僅僅是為了提供服務發現功能，也
是為了減少推測工作和開發工作量。客戶端只需簡單地完成服務注冊工作，然后使用一個DNS接口或者HTTP接口就可以執行工作了，而其他系統則需要你定制
自己的解決方案。
一個令人信服的服務發現框架必須包含健康檢測功能，并且考慮失敗的可能性。要是節點失敗或者服務故障了，即使開發人員知道節點A提供Foo服務也
是沒用的。Navie系統利用的是心跳、周期性更新和TTLs，這些系統不僅需要工作量與節點數量成線性關系，并且對服務器的固定數量提出了要求。此外，
故障檢測窗口的存活時間至少要和TTL一樣長。
ZooKeeper提供了臨時節點，這些臨時節點就是K/V條目，當客戶端斷開連接時，這些條目會被刪除。雖然這些臨時節點比一個心跳系統更高
級，但仍存在固有的擴展性問題，并且會增加客戶端的復雜性。與ZooKeeper服務器端連接時，客戶端必須保持活躍，并且去做持續性連接。此
外，ZooKeeper還需要胖客戶端，而胖客戶端是很難編寫，并且胖客戶端會經常導致調試質詢。
Consul使用一個完全不同的架構進行健康檢測。Consul客戶端可以運行在集群中的每一個節點上，而不是擁有服務器節點，這些Consul客戶端屬于一個gossip pool，gossip
pool提供了一些功能，包括分布式健康檢測。gossip協議提供了一個高效的故障檢測工具，這個故障檢測工具可以應用到任意規模的集群，而不僅僅是作
用于特定的服務器組。同時，這個故障檢測工具也支持在本地進行多種健康檢測。與此相反，ZooKeeper的臨時節點只是一個非常原始的活躍度檢測。因為
有了Consul，客戶端可以檢測web服務器是否正在返回200狀態碼，內存利用率是否達到臨界點，是否有足夠的數據存儲盤等。此
外，ZooKeeper會暴露系統的復雜性給客戶端，為了避免ZooKeeper出現的這種情況，Consul只提供一個簡單HTTP接口。
Consul為服務發現、健康檢測、K/V存儲和多數據中心提供了一流的支持。為了支持任意存儲，而不僅僅是簡單的K/V存儲，其他系統都要求工
具和lib庫要率先建立。然而，通過使用客戶端節點，Consul提供了一個簡單的API，這個API的開發只需要瘦客戶端就可以了，
而且，通過使用配置文件和DNS接口，開發人員可以建立完整的服務發現解決方案，最終，達到避免開發API的目的。
原文鏈接：CONSUL VS. ZooKeeper, DOOZERD, ETCD（翻譯：洪國安 校對：李穎杰）
來自：http://dockerone.com/article/300