1.什麼是consul？
Consul 是 HashiCorp 公司推出的開源工具，用於實現分佈式系統的服務發現與配置。與其它分佈式服務註冊與發現的方案，Consul 的方案更“一站式”，內置了服務註冊與發現框 架、分佈一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其它工具（比如 ZooKeeper 等）。使用起來也較 爲簡單。Consul 使用 Go 語言編寫，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安裝包僅包含一個可執行文件，方便部署，與 Docker 等輕量級容器可無縫配合。
2.consul 具有以下性質：
服務發現：consul通過http 方式註冊服務，並且服務與服務之間相互感應。
服務健康監測
key/value 存儲
多數據中心
consul可運行在mac windows linux 等機器上。
3.Consul VS Eureka
Eureka 是一個服務發現工具。該體系結構主要是客戶端/服務器，每個數據中心有一組 Eureka 服務器，通常每個可用區域一個。通常 Eureka 的客戶使用嵌入式 SDK 來註冊和發現服務。對於非本地集成的客戶，官方提供的 Eureka 一些 REST 操作 API，其它語言可以使用這些 API 來實現對 Eureka Server 的操作從而實現一個非 jvm 語言的 Eureka Client。
Eureka 提供了一個弱一致的服務視圖，儘可能的提供服務可用性。當客戶端向服務器註冊時，該服務器將嘗試複製到其它服務器，但不提供保證複製完成。服務註冊的生存時間（TTL）較短，要求客戶端對服務器心跳檢測。不健康的服務或節點停止心跳，導致它們超時並從註冊表中刪除。服務發現可以路由到註冊的任何服務，由於心跳檢測機制有時間間隔，可能會導致部分服務不可用。這個簡化的模型允許簡單的羣集管理和高可擴展性。
Consul 提供了一些列特性，包括更豐富的健康檢查，鍵值對存儲以及多數據中心。Consul 需要每個數據中心都有一套服務，以及每個客戶端的 agent，類似於使用像 Ribbon 這樣的服務。Consul agent 允許大多數應用程序成爲 Consul 不知情者，通過配置文件執行服務註冊並通過 DNS 或負載平衡器 sidecars 發現。
Consul 提供強大的一致性保證，因爲服務器使用 Raft 協議複製狀態 。Consul 支持豐富的健康檢查，包括 TCP，HTTP，Nagios / Sensu 兼容腳本或基於 Eureka 的 TTL。客戶端節點參與基於 Gossip 協議的健康檢查，該檢查分發健康檢查工作，而不像集中式心跳檢測那樣成爲可擴展性挑戰。發現請求被路由到選舉出來的 leader，這使他們默認情況下強一致性。允許客戶端過時讀取取使任何服務器處理他們的請求，從而實現像 Eureka 這樣的線性可伸縮性。
Consul 強烈的一致性意味着它可以作爲領導選舉和集羣協調的鎖定服務。Eureka 不提供類似的保證，並且通常需要爲需要執行協調或具有更強一致性需求的服務運行 ZooKeeper。
Consul 提供了支持面向服務的體系結構所需的一系列功能。這包括服務發現，還包括豐富的運行狀況檢查，鎖定，密鑰/值，多數據中心聯合，事件系統和 ACL。Consul 和 consul-template 和 envconsul 等工具生態系統都試圖儘量減少集成所需的應用程序更改，以避免需要通過 SDK 進行本地集成。Eureka 是一個更大的 Netflix OSS 套件的一部分，該套件預計應用程序相對均勻且緊密集成。因此 Eureka 只解決了一小部分問題，可以和 ZooKeeper 等其它工具可以一起使用。
Consul 強一致性©帶來的是：
服務註冊相比 Eureka 會稍慢一些。因爲 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認爲註冊成功 Leader 掛掉時，重新選舉期間整個 Consul 不可用。保證了強一致性但犧牲了可用性。
Eureka 保證高可用(A)和最終一致性：
服務註冊相對要快，因爲不需要等註冊信息 replicate 到其它節點，也不保證註冊信息是否 replicate 成功 當數據出現不一致時，雖然 A, B 上的註冊信息不完全相同，但每個 Eureka 節點依然能夠正常對外提供服務，這會出現查詢服務信息時如果請求 A 查不到，但請求 B 就能查到。如此保證了可用性但犧牲了一致性。
其它方面，eureka 就是個 servlet 程序，跑在 servlet 容器中; Consul 則是 go 編寫而成。
4. 服務發現和治理
在分佈式系統結構中，往往由成百上千的業務服務組成，爲了容災(節點宕機)、擴容(增加節點)、提高運維效率(動態配置)等原因，需要服務能夠實現靈活發現，避免問題節點等功能，以提高系統穩定性（更多內容，關注微信公衆號：白白家族）。
1 服務發現以及註冊：
當服務Producer 啓動時，會將自己的Ip/host等信息通過發送請求告知 Consul，Consul 接收到 Producer 的註冊信息後，每隔一段時間會向 Producer 發送一個健康檢查的請求，檢驗Producer是否健康。
2 服務調用：
當 Consumer 請求Product時，會先從 Consul 中拿到存儲Product服務的 IP 和 Port 的臨時表(temp table)，從temp table表中任選一個· Producer 的 IP 和 Port， 然後根據這個IP和Port，發送訪問請求；temp table表只包含通過了健康檢查的 Producer 信息，並且每隔一段時間更新
5.consule 核心 agent組件
Agent是一個獨立的程序，通過守護進程的方式，運行在consul集羣中的每個節點上。每個Consul agent維護它自己的服務集合以及檢查註冊和健康信息。agent負責執行自己的健康檢查和更新本地狀態其中，Agent 根據節點的性質，分爲： Agent Server 和 Agent Client
Agent Client:
client將 HTTP 和 DNS 接口請求轉發給局域網內的服務端集羣。
Agent Server:
server 保存client的註冊信息，集羣的配置信息, 維護集羣高可用, 在局域網內與本地客戶端通訊, 通過廣域網與其它數據中心通訊。 每個數據中心的 server 數量推薦爲 3 個或是 5 個,通過 Raft 算法來保證一致性。
6. consul 去中心化思想實現
consul 使用了基於gossip協議的Serf實現，Serf是一個服務發現，編配工具，它去中心化，不像集中式結構那樣統一分配管理； Serf提供成員關係，糾錯檢查，廣播等功能。gossip協議主要是基於UDP，實現任意node-to-node間的通信。Consul正是使用serf 提供的gossip協議來管理成員和廣播消息到集羣。
gossip 協議（gossip protocol）是基於流行病傳播方式的節點或者進程之間信息交換的協議，來確保網絡中所有節點的數據一樣。其中節點間的交互方式主要以下有三種：
· Push：發起信息的節點 A 隨機選擇聯繫節點 B，並向B發送自己的信息，節點 B 在收到信息後，更新比自己新的數據，一般擁有新信息的節點纔會作爲發起節點。
· Pull：發起信息的節點 A 隨機選擇聯繫節點 B，並從對方獲取信息。一般無新信息的節點纔會作爲發起節點。
· Push&Pull：發起信息的節點 A 向選擇的節點 B 發送信息，同時從對方獲取數據，用於更新自己的本地數據。
7. Consul 中的術語
在描述架構之前，我們提供術語表以幫助澄清正在討論的內容：
代理（agent） - 代理是Consul集羣的每個成員上長時間運行的守護程序。它是通過運行consul agent 命令來啓動的。代理能夠以客戶端或服務器模式運行。由於所有節點都必須運行代理，因此將節點稱爲客戶端或服務器更簡單，但代理還有其他實例。所有代理都可以運行DNS或HTTP接口，並負責運行檢查並保持服務同步。
客戶端模式（client agent） - 客戶端是將所有RPC調用轉發到服務器的代理。客戶端是相對無狀態的。客戶端執行的唯一後臺活動是參與LAN gossip pool（局域網 Gossip池）。這會花費非常非常小的資源並且僅消耗少量的網絡帶寬。
服務器模式(server agent) - 服務器是具有擴展責任的代理，包括參與Raft仲裁，維護羣集狀態，響應RPC查詢，與其他數據中心交換WAN Gossip（廣域網Gossip）以及將查詢轉發給領導者或遠程數據中心。
數據中心 （datacenter）- 雖然數據中心的定義似乎很明顯，但必須考慮細微的細節。例如，在EC2中，多個可用區域是否被視爲包含單個數據中心？我們將數據中心定義爲專用，低延遲和高帶寬的網絡環境。這排除了通過公共互聯網的通信，但出於我們的目的，單個EC2區域內的多個可用區域將被視爲單個數據中心的一部分。
共識 （consensus）- 在我們的文檔中使用時，我們使用共識來表示對當選領導者的協議以及對交易順序的協議。由於這些事務應用於有限狀態機，因此我們對共識的定義意味着複製狀態機的一致性。維基百科上更詳細地描述了共識，此處描述了我們的實現。
Gossip - Consul建立在Serf之上，它提供了一個完整的gossip 協議（八卦協議Gossip協議），用於多種用途。 Serf提供成員維護，故障檢測和事件廣播。我們對這些的使用在八卦文檔中有更多描述。Gossip參與隨機的節點到節點的通信，主要是通過UDP。
LAN Gossip - 指局域網八卦池，其中包含位於同一局域網或數據中心的節點。
WAN Gossip - 指僅包含服務器（servers）的WAN八卦池。這些服務器主要位於不同的數據中心，通常通過互聯網或廣域網進行通信。
RPC - 遠程過程調用。這是一種允許客戶端發出服務器請求的請求/響應機制。
8.和Eureka的比較
Eureka因爲是Netflix OSS套件的一部分，2.x停止維護，不過1.x仍然是活躍的。
這裏重點說下consul與Eureka的區別。和其他系統的比較，可點擊此網址自行查看。
Eureka是一種服務發現工具。該體系結構主要是客戶端/服務器，每個數據中心有一組Eureka服務器，通常每個可用區域一個。通常，Eureka的客戶使用嵌入式SDK來註冊和發現服務。對於非本地集成的客戶端，使用Ribbon等邊車通過Eureka透明地發現服務。
Eureka使用盡力而爲的複製提供弱一致的服務視圖。當客戶端向服務器註冊時，該服務器將嘗試複製到其他服務器但不提供保證。服務註冊的生存時間（TTL)很短，要求客戶端對服務器進行心跳檢測。不健康的服務或節點停止心跳後，導致它們超時並從註冊表中刪除。發現請求可以路由到任何服務，由於盡力複製，這些服務可以提供過時或丟失的數據。這種簡化的模型可以實現輕鬆的集羣管理和高可擴展性。
Consul提供了一系列超級功能，包括更豐富的健康檢查，鍵/值存儲和多數據中心感知。 Consul需要每個數據中心中的一組服務器，以及每個客戶端上的代理，類似於使用像Ribbon這樣的邊車。 Consul代理允許大多數應用程序不知道Consul，通過配置文件執行服務註冊以及通過DNS或負載平衡器sidecars進行發現。
Consul提供強一致性保證，因爲服務器使用Raft協議複製狀態。 Consul支持豐富的運行狀況檢查，包括TCP，HTTP，Nagios / Sensu兼容腳本或基於Ture的Eureka。客戶端節點參與基於八卦的健康檢查，該檢查分發健康檢查的工作，而不像集中式心跳，這成爲可擴展性挑戰。發現請求被路由到當選的領事領導者，這允許他們默認情況下是強烈一致的。允許過時讀取的客戶端允許任何服務器處理其請求，從而允許像Eureka一樣的線性可伸縮性。
Consul的強一致性意味着它可以用作領導者選舉和集羣協調的鎖服務。 Eureka不提供類似的保證，並且通常需要爲需要執行協調或具有更強一致性需求的服務運行ZooKeeper。
Consul提供了支持面向服務的體系結構所需的功能工具包。這包括服務發現，還包括豐富的運行狀況檢查，鎖定，鍵/值，多數據中心聯合，事件系統和ACL。 Consul和consul-template和envconsul等生態系統工具都試圖最大限度地減少集成所需的應用程序更改，以避免需要通過SDK進行本機集成。 Eureka是更大的Netflix OSS套件的一部分，該套件期望應用程序相對同質且緊密集成。因此，Eureka只解決了有限的一部分問題，期望其他工具如ZooKeeper可以同時使用。
總結：
Consul 通過Raft協議提供強一致性，而Eureka提供的弱一致性。
Consul 通過Gossip協議更好分發健康檢查的工作，而不是Eureka集中式心跳（要客戶端不停地請求服務端）
由於Raft提供的強一致性，Consul可以用來做領導選擇，集羣協議的鎖服務，而Eureka只能藉助於Zookeeper。