Consul vs. Eureka

Eureka是一種服務發現工具。 該體系結構主要是客戶端/伺服器，每個資料中心有一組Eureka伺服器，通常每個可用區域一個。 通常，Eureka的客戶使用嵌入式SDK來註冊和發現服務。 對於非本地整合的客戶端，使用Ribbon等邊車通過Eureka透明地發現服務。

Eureka使用盡力而為的複製提供弱一致的服務檢視。 當客戶端向伺服器註冊時，該伺服器將嘗試複製到其他伺服器但不提供保證。 服務註冊的生存時間很短（TTL），要求客戶端對伺服器進行心跳檢測。 不健康的服務或節點將停止心跳，導致它們超時並從登錄檔中刪除。 發現請求可以路由到任何服務，由於盡力複製，這些服務可以提供過時或丟失的資料。 這種簡化的模型允許輕鬆的叢集管理和高可擴充套件性。

Consul提供了一系列超級功能，包括更豐富的執行狀況檢查，鍵/值儲存和多資料中心感知。 Consul需要每個資料中心中的一組伺服器，以及每個客戶端上的代理，類似於使用像Ribbon這樣的邊車。 Consul代理允許大多數應用程式不知道Consul，通過配置檔案執行服務註冊以及通過DNS或負載平衡器sidecars進行發現。

Consul提供強大的一致性保證，因為伺服器使用Raft協議複製狀態。 Consul支援豐富的執行狀況檢查，包括TCP，HTTP，Nagios / Sensu相容指令碼或基於的Eureka的TTL。 客戶端節點參與基於gossip的健康檢查，該檢查分發健康檢查的工作，而不像集中式心跳，這成為可擴充套件性挑戰。 發現請求被路由到當選的Consul領導者，這使他們預設情況下非常一致。 允許過時讀取的客戶端允許任何伺服器處理其請求，從而允許像Eureka一樣的線性可伸縮性。

Consul的強烈一致性意味著它可以用作領導者選舉和叢集協調的鎖定服務。 Eureka不提供類似的保證，並且通常需要為需要執行協調或具有更強一致性需求的服務執行ZooKeeper。

Consul提供了支援面向服務的體系結構所需的功能工具包。 這包括服務發現，還包括豐富的執行狀況檢查，鎖定，鍵/值，多資料中心聯合，事件系統和ACL。 Consul和consul-template和envconsul等工具生態系統都試圖最大限度地減少整合所需的應用程式更改，以避免需要通過SDK進行本機整合。 Eureka是更大的Netflix OSS套件的一部分，該套件期望應用程式相對同質且緊密整合。 因此，Eureka只解決了有限的一部分問題，期望其他工具如ZooKeeper可以同時使用。