【編者的話】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的目的。