1. consul的基本介紹
在分佈式架構中，服務治理是一個重要的問題。在沒有服務治理的分佈式集羣中，各個服務之間通過手工或者配置的方式進行服務關係管理，遇到服務關係變化或者增加服務的時候，人肉配置極其麻煩且容易出錯。之前在一個C/C++項目中，採用ZooKeeper進行服務治理，可以很好的維護服務之間的關係，但是使用起來較爲麻煩。現在越來越多新的項目採用consul進行服務治理，各方面的評價都優於ZooKeeper，經過幾天的研究，這裏做一個總結。
zookeeper和consul比較
開發語言方面，zookeeper採用java開發，安裝的時候需要部署java環境；consul採用golang開發，所有依賴都編譯到了可執行程序中，即插即用。
部署方面，zookeeper一般部署奇數個節點方便做簡單多數的選舉機制。consul部署的時候分server節點和client節點（通過不同的啓動參數區分），server節點做leader選舉和數據一致性維護，client節點部署在服務機器上，作爲服務程序訪問consul的接口。
一致性協議方面，zookeeper使用自定義的zab協議，consul的一致性協議採用更流行的Raft。
zookeeper不支持多數據中心，consul可以跨機房支持多數據中心部署，有效避免了單數據中心故障不能訪問的情況。
鏈接方式上，zookeeper client api和服務器保持長連接，需要服務程序自行管理和維護鏈接有效性，服務程序註冊回調函數處理zookeeper事件，並自己維護在zookeeper上建立的目錄結構有效性（如臨時節點維護）；consul 採用DNS或者http獲取服務信息，沒有主動通知，需要自己輪訓獲取。
工具方面，zookeeper自帶一個cli_mt工具，可以通過命令行登錄zookeeper服務器，手動管理目錄結構。consul自帶一個Web UI管理系統， 可以通過參數啓動並在瀏覽器中直接查看信息。
Consul是一個用來實現分佈式系統的服務發現與配置的開源工具。他主要由多個組成部分：
服務發現：客戶端通過Consul提供服務，類似於API,MySQL,或者其他客戶端可以使用Consul發現服務的提供者。使用類似DNS或者HTTP，應用程序和可以很輕鬆的發現他們依賴的服務。
檢查健康：Consul客戶端可以提供與給定服務相關的健康檢查（Web服務器返回200 ok）或者本地節點（“內存利用率低於90%”）。這些信息可以監控集羣的運行情況，並且使訪問遠離不健康的主機組件。
鍵值對存儲：應用程序可以使用Cousul的層級鍵值對。
多數據中心：Consul有開箱及用的多數據中心。
Consul 的角色
client: 客戶端, 無狀態, 將 HTTP 和 DNS 接口請求轉發給局域網內的服務端集羣.
server: 服務端, 保存配置信息, 高可用集羣, 在局域網內與本地客戶端通訊, 通過廣域網與其他數據中心通訊. 每個數據中心的 server 數量推薦爲 3 個或是 5 個.
agent
組成 consul 集羣的每個成員上都要運行一個 agent，可以通過 consul agent 命令來啓動。agent 可以運行在 server 狀態或者 client 狀態。自然的，運行在 server 狀態的節點被稱爲 server 節點；運行在 client 狀態的節點被稱爲 client 節點。
client 節點
負責轉發所有的 RPC 到 server 節點。本身無狀態，且輕量級，因此，可以部署大量的 client 節點。
server 節點
負責組成 cluster 的複雜工作（選舉、狀態維護、轉發請求到 lead），以及 consul 提供的服務（響應 RCP 請求）。考慮到容錯和收斂，一般部署 3 ~ 5 個比較合適。
Consul內幕
術語
代理(agent)：代理是Consul集羣上每個成員的守護進程，它是由consul agent開始運行。代理能夠以客戶端或服務器模式運行。由於所有節點都必須運行代理，所以將節點引用爲客戶端或服務器更爲簡單，但還有其他實例的代理。所有代理可以運行DNS或HTTP接口，並負責運行檢查和保持服務同步。
客戶端：客戶端可以將所有RPC請求轉發到服務器的代理。客戶端是相對無狀態的。客戶端執行的唯一後臺活動是LANgossip池。它消耗最小的資源開銷和少量的網絡帶寬。
服務器端：服務器端是具有擴展的功能的代理，它主要參與維護集羣狀態，響應RPC查詢，與其他數據中心交換WAN gossip ，以及向上級或遠程數據中心轉發查詢。
數據中心：雖然數據中心的定義似乎很明顯，但仍有一些細微的細節必須考慮。我們將一個數據中心定義爲一個私有、低延遲和高帶寬的網絡環境。這不包括通過公共互聯網的通信，但是爲了我們的目的，單個EC2區域內的多個可用區域將被視爲單個數據中心的一部分
Gossip：consul是建立在serf之上的，它提供了一個完整的gossip協議，用在很多地方。Serf提供了成員，故障檢測和事件廣播。Gossip的節點到節點之間的通信使用了UDP協議。
LAN Gossip：指在同一局域網或數據中心的節點上的LAN Gossip池。
WAN Gossip：指包含服務器的WAN Gossip池，這些服務器在不同的數據中心，通過網絡進行通信。
一致性協議採用 Raft 算法,用來保證服務的高可用.
成員管理和消息廣播 採用GOSSIP協議，支持ACL訪問控制。
ACL技術在路由器中被廣泛採用，它是一種基於包過濾的流控制技術。控制列表通過把源地址、目的地址及端口號作爲數據包檢查的基本元素，並可以規定符合條件的數據包是否允許通過。
gossip就是p2p協議。他主要要做的事情是，去中心化。
這個協議就是模擬人類中傳播謠言的行爲而來。首先要傳播謠言就要有種子節點。種子節點每秒都會隨機向其他節點發送自己所擁有的節點列表，以及需要傳播的消息。任何新加入的節點，就在這種傳播方式下很快地被全網所知道。
什麼是服務註冊？
一個服務將其位置信息在“中心註冊節點”註冊的過程。該服務一般會將它的主機IP地址以及端口號進行註冊，有時也會有服務訪問的認證信息，使用協議，版本號，以及關於環境的一些細節信息。
什麼是服務發現？
服務發現可以讓一個應用或者組件發現其運行環境以及其它應用或組件的信息。用戶配置一個服務發現工具就可以將實際容器跟運行配置分離開。常見配置信息包括：ip、端口號、名稱等。
當一項服務存在於多個主機節點上時，client端如何決策獲取相應正確的IP和port。
在傳統情況下，當出現服務存在於多個主機節點上時，都會使用靜態配置的方法來實現服務信息的註冊。
而當在一個複雜的系統裏，需要較強的可擴展性時，服務被頻繁替換時，爲避免服務中斷，動態的服務註冊和發現就很重要。
圖中，客戶端的一個接口，需要調用服務A-N。客戶端必須要知道所有服務的網絡位置的，以往的做法是配置是配置文件中，或者有些配置在數據庫中。這裏就帶出幾個問題：
需要配置N個服務的網絡位置，加大配置的複雜性
服務的網絡位置變化，都需要改變每個調用者的配置
集羣的情況下，難以做負載（反向代理的方式除外）
總結起來一句話：服務多了，配置很麻煩，問題多多
既然有這些問題，那麼服務發現就是解決這些問題的。話說，怎麼解決呢？我們再看一張圖
與之前一張不同的是，加了個服務發現模塊。圖比較簡單，這邊文字描述下。服務A-N把當前自己的網絡位置註冊到服務發現模塊（這裏註冊的意思就是告訴），服務發現就以K-V的方式記錄下，K一般是服務名，V就是IP:PORT。服務發現模塊定時的輪詢查看這些服務能不能訪問的了（這就是健康檢查）。客戶端在調用服務A-N的時候，就跑去服務發現模塊問下它們的網絡位置，然後再調用它們的服務。這樣的方式是不是就可以解決上面的問題了呢？客戶端完全不需要記錄這些服務網絡位置，客戶端和服務端完全解耦！
這個過程大體是這樣，當然服務發現模塊沒這麼簡單。裏面包含的東西還很多。這樣表述只是方便理解。
圖中的服務發現模塊基本上就是微服務架構中服務發現的作用了。
consul 簡介
做服務發現的框架常用的有
zookeeper
eureka
etcd
consul
這裏就不比較哪個好哪個差了，需要的童鞋自己谷歌百度。
那麼consul是啥？consul就是提供服務發現的工具。然後下面是簡單的介紹：
consul是分佈式的、高可用、橫向擴展的。consul提供的一些關鍵特性：
service discovery：consul通過DNS或者HTTP接口使服務註冊和服務發現變的很容易，一些外部服務，例如saas提供的也可以一樣註冊。
health checking：健康檢測使consul可以快速的告警在集羣中的操作。和服務發現的集成，可以防止服務轉發到故障的服務上面。
key/value storage：一個用來存儲動態配置的系統。提供簡單的HTTP接口，可以在任何地方操作。
multi-datacenter：無需複雜的配置，即可支持任意數量的區域。
我們這裏會介紹服務發現，健康檢查，還有一些基本KV存儲。多數據中心有機會另一篇文章再說。
總結：只要知道它是解決我上一部分提出的問題就行，其它的東西慢慢理解
consul的幾個概念
上圖是我從consul官方文檔摳出來的。
我們只看數據中心1，可以看出consul的集羣是由N個SERVER，加上M個CLIENT組成的。而不管是SERVER還是CLIENT，都是consul的一個節點，所有的服務都可以註冊到這些節點上，正是通過這些節點實現服務註冊信息的共享。除了這兩個，還有一些小細節，一一簡單介紹。
CLIENT
CLIENT表示consul的client模式，就是客戶端模式。是consul節點的一種模式，這種模式下，所有註冊到當前節點的服務會被轉發到SERVER，本身是不持久化這些信息。
SERVER
SERVER表示consul的server模式，表明這個consul是個server，這種模式下，功能和CLIENT都一樣，唯一不同的是，它會把所有的信息持久化的本地，這樣遇到故障，信息是可以被保留的。
SERVER-LEADER
中間那個SERVER下面有LEADER的字眼，表明這個SERVER是它們的老大，它和其它SERVER不一樣的一點是，它需要負責同步註冊的信息給其它的SERVER，同時也要負責各個節點的健康監測。
其它信息
其它信息包括它們之間的通信方式，還有一些協議信息，算法。它們是用於保證節點之間的數據同步，實時性要求等等一系列集羣問題的解決。這些有興趣的自己看看官方文檔。
相關開源項目：Zookeeper，Doozer，Etcd，強一致性的項目，這些項目主要用於服務間的協調，同時又可用於服務的註冊。
什麼是強一致性協議？
按照某一順序串行執行存儲對象讀寫操作， 更新存儲對象之後， 後續訪問總是讀到最新值。 假如進程A先更新了存儲對象，存儲系統保證後續A,B,C進程的讀取操作都將返回最新值。強一致性模型有幾種常見實現方法， 主從同步複製， 以及quorum複製等。
http://blog.csdn.net/shlazww/article/details/38736511
2. consul的具體應用場景
1. docker、coreos 實例的註冊與配置共享
2. vitess集羣
3. SaaS應用的配置共享
4.與confd服務集成，動態生成nignx與haproxy配置文件
3. 優勢
1. 使用 Raft 算法來保證一致性，比poxes算法更直接。zookeeper採用的時poxes算法。
Raft大概將整個過程分爲三個階段，leader election，log replication和commit(safety)。
每個server處於三個狀態：leader，follower，candidate。正常情況下，所有server中只有一個是leader，其它的都是follower。server之間通過RPC消息通信。follower不會主動發起RPC消息。leader和candidate(選主的時候)會主動發起RPC消息。
首先選擇一個leader全權負責管理日誌複製，leader從客戶端接收log entries，將它們複製給集羣中的其它機器，然後負責告訴其它機器什麼時候將日誌應用於它們的狀態機。舉個例子，leader可以在無需詢問其它server的情況下決定把新entries放在哪個位置，數據永遠是從leader流向其它機器。一個leader可以fail或者與其他機器失去連接，這種情形下會有新的leader被選舉出來。
http://www.jdon.com/artichect/raft.html
http://blog.csdn.net/cszhouwei/article/details/38374603
2. 支持多數據中心，內外網的服務採用不同的端口進行監聽。這樣可以避免單點故障。
zookeeper等不支持多數據中心功能的支持
3. 支持健康檢查
4. 提供web界面
5. 支持http協議與dns協議接口
使用 Raft 算法來保證一致性, 比複雜的 Paxos 算法更直接. 相比較而言, zookeeper 採用的是 Paxos, 而 etcd 使用的則是 Raft.
支持多數據中心，內外網的服務採用不同的端口進行監聽。 多數據中心集羣可以避免單數據中心的單點故障,而其部署則需要考慮網絡延遲, 分片等情況等. zookeeper 和 etcd 均不提供多數據中心功能的支持.
支持健康檢查. etcd 不提供此功能.
支持 http 和 dns 協議接口. zookeeper 的集成較爲複雜, etcd 只支持 http 協議.
官方提供web管理界面, etcd 無此功能.
綜合比較, Consul 作爲服務註冊和配置管理的新星, 比較值得關注和研究.
4. 架構圖
圖中有兩個數據中心，分別爲Datacenter1和Datacenter2。Consul一層支持多個數據中心，每個數據中心內，有客戶端和服務器端，服務區端一般爲3~5個，這樣可以在穩定和性能上達到平衡，因爲更多的機器會使數據同步很慢。不過客戶端是沒有限制的，可以有成千上萬個。
數據中心到所有節點都使用的時候Gossip協議。這就意味着有一個Gossip池，其中包含給定數據中心所有的節點。客戶端不需要去配置服務器地址信息，發現服務會自動完成；檢測故障節點的工作不是放在服務器端，而是分佈式的；數據中心被用作消息層，以便在選擇leader這種重要的事情發生的時候做通知。
每個數據中心都是都是單個Raft對等設備的一部分。這意味着他們一起工作，選擇一個單一的領導者——一個具有額外職責的選定的服務器。leader負責處理所有查詢和事物。事物也必須作爲同步協議的一部分複製到所有對等體。由於這個要求，當非領導服務器端接收到RPC請求時，就會將請求其轉發給集羣leader。
服務器端節點作爲WANGossip池的一部分運行，WAN池和LAN池不同的是，針對網絡高延遲做了優化，而且只包含其他Consul服務器的節點。這個池的目的是允許數據中心以最少的消耗方式發現對方。在線啓動新的數據中心與加入現有的WAN Gossip一樣簡單。因爲這些服務器都在這個池中運行，它還支持跨數據中心請求。當服務器收到對不同數據中心的請求時，它會將其轉發到正確數據中心中的隨機服務器。那個服務器可能會轉發給本地的leader。
這樣會使數據中心的耦合非常低，由於故障檢測，連接緩存和複用，跨數據中心請求相對快速可靠。
Gossip協議（流言傳播協議）
Consul使用Gossip協議來管理成員和集羣廣播消息，這些都是通過使用Serf庫的。Serf所使用的Gossip協議基於SWIM:可伸縮的弱一致的感染模式的過程組成員協議”，並做了一些細微的修改。
Consul中的Gossip
Consul使用了兩個不同的Gossip池，稱爲LAN池和WAN池。每個數據中心都有一個LAN池，其中包含數據中心的所有成員，包括服務器端和客戶端。LAN的成員客戶端可以自動發現服務器，減少所需配置的數量。分佈式故障檢測可以讓故障檢測的工具被整個集羣共享，Gossip池可以快速可靠的將事件廣播，比如選擇leader。
WAN池是全局唯一的，所有的服務器都應該在WAN池中，而不關係數據中心在哪裏。WAN池提供的成員信息允許服務器執行跨數據中心請求。集成的故障檢測功能使Consul能夠優雅地處理整個數據中心或者遠程數據中心的一個服務器失連。
Lifeguard Enhancements
在分組軟實時處理可能的情況下，SWIN假設本地節點是健康的。但在本地節點遇到CPU或者網絡節點資源匱乏的時候，可能不會認爲節點不健康。結果是安全檢測狀態可能會偶爾癱瘓，導致虛假報警。Lifeguard解決了這個問題。
Consensus 協議
Consul通過Consensus協議來提供一致性(由CAP定義)。Consensus協議是基於Raft——查找可理解的一致性算法。
Raft協議概述
Raft是一種基於Paxos的一致性算法。與Paxos相比，Raft被設計成更少的狀態和更簡單、更易於理解的算法。
Raft節點有三種狀態：follower,candidate,leader.所有的節點初始被置於follower，在這個狀態下的節點都可以收到來自leader的Log並反饋。如果在一段時間沒有收到任何信息，那麼他就會變成candidate狀態。在candidate狀態下，一個節點向其他節點發送請求，這個節點就成爲了leader。Leader必須接收新Log並複製其到其他follower那裏。PS：只有leader才能進行讀取Log。
一旦一個集羣有一個leader，他就可以接受新的Log條目。一個客戶端可以請求leader附加新的Log條目。這個leader隨後將Log條目寫入持久存儲，並複製到follower。一旦Log條目被認爲已經提交，它就會被用於有限狀態機。有限狀態機是相對於特定應用的，對於Consul而言，我們使用MenDB來維護集羣狀態。
顯然，我們不需要無限制的複製日誌。Raft提供了一種機制，通過這種機制，讓狀態被記錄時這個Log就會被壓縮。
網絡座標
Consul使用網絡斷層成像系統計算集羣中的節點的網絡座標。這些座標可以計算在任何兩個節點之間估計網絡往返時間。這有很多有用的應用，例如找到最靠近請求節點的服務節點，或者找到在下一個失效的最接近的數據中心中的服務器。
Consul的網絡座標
在Consul裏，網絡座標有幾種形式：
consul rtt命令可以查詢任意兩個節點的網絡往返之間。
顯示端點和端點運行狀況端點可以使用“?near =”參數根據給定節點的網絡往返時間對查詢的結果進行排序。
查詢可以根據網絡往返時間將請求從故障的數據中心服務器中轉移。
座標終點顯示用於其他應用程序的原始網絡座標。
Session
Consul提供了Session機制用於構建分佈式鎖，Session作爲節點之間的綁定，運行狀況檢查和鍵值對數據。
Session設計
Consul的session代表了具體語義一個Session中包含了節點名稱，列表的健康性，行爲，TTL和lock-delay。新建的Session中提供了一個可以用來識別它的ID。這個ID可與存儲的鍵值對一起使用以獲取鎖定：相互排斥的諮詢機制。
下圖是組件之間的關係圖：
Consul定製的標準在下列情況下，被定義爲無效：
節點被註銷
所有的健康檢查都被註銷
所有健康檢查都在危險狀態
Session被明確銷燬了
TTL過期
Session無效的時候，將會被銷燬，關聯鎖是創建的指定行爲，Consul支持發佈和刪除。Consul支持釋放和刪除行爲，如果沒有特別指定，默認的行爲爲釋放。
如果正在執行釋放操作，與Session相關的所有的鎖都會被釋放掉，並且鍵的索引無法遞增。在刪除行爲執行的時候，則鎖和鍵都會被刪除。這可以用於Consul自動刪除條目。
這種設計常用於流言傳播的故障檢測器的健康監測。在默認情況下，使用基於留言傳播的故障檢測器作爲故障檢測器用來進行相關的健康檢查。該故障檢測器允許Consul檢測持有鎖的節點在發生故障時自動釋放鎖。這種機制讓consul發生故障或者其他失敗的情況下，可以繼續運行下去。但是，由於，沒有完美的故障檢測器，有的時候，檢測到的故障並不存在，也會導致鎖的釋放。這就意味着他並不是絕對安全的。
相反的，可以創建一個無關聯的健康檢測的session。這就提供了對安全性要求的虛假的不健康檢測的消除提供了可能。即使現有的鎖的持有者執行出現故障，你也可以自己確定是否釋放Consul的鎖。由於Consul的API可以強制銷燬session，所以我們可以在發生故障的時候進行人爲干預，防止split-brain。
第三個健康檢測機制是session的TTL。當創建一個session的時候，一個TTL也被指定。如果這個TTL的間隔時間到而沒有更新，則session過期，並且無法早觸發。這種類型的故障檢測器叫做心跳檢測器。他想必基於流言傳播的故障檢測器的可擴展性低，因爲他會對服務器造成更大的負擔，但是在一些情況下很有用。TTL是session過期的時間，在到達TTL之前，consul不會讓session過去，但是consul允許延遲過期。在session創建初期，session更新和leader故障轉移的時候，TTL會更新。當一個TTL被使用的時候，客戶端應當注意時間的偏差——時間不可能會像consul Server上那樣在客戶端上以相同的速率進展。我們最好設置保守的TTL值，TTL更新之前考慮時間的偏差。
最後的細微差別爲session會提供鎖定延遲。這個延遲會持續0-60秒。當有無效的session時，consul會防止ssession在鎖定延時的時間內重新獲取之前的保存的所有鎖。這種延遲的目錄是允許潛在的leader檢測到無效後，停止並導致狀態不一致的請求。雖然不是一個徹底的方式，但是可以減少很多問題。延遲默認爲15秒，客戶端可以將延遲設置爲0來取消這個機制。
安全模型
Consul使用了流言傳播協議和RPC來提供各種功能。這兩個系統在設計上採用了不同的安全機制，但是，Consul的安全機制完成的共同目標爲：提供機密性，完整性和認證。流言傳播協議由serf提供支持，serf使用對稱祕鑰或者共享密碼系統。RPC支持使用可選客戶端認證的端到端的TLS。
這就意味着Consul有完善的安全機制可以使其在不可信的網絡上運行。
威脅模型
以下是威脅模型：
非成員可以訪問數據
由於惡意郵件導致集羣被操控
惡意郵件造成的虛假數據
對接點拒接服務
命令行
Consul命令行
Consul使用命令行非常容易操作，我們可以通過命令consul進行命令行申請。然後接着使用agent或者member之類的子命令。只要運行不帶參數的consul命令就可以查看命令列表。
$ consul usage: consul [--version] [--help] <command> [<args>]Available commands are: agent Runs a Consul agent configtest Validate config file event Fire a new event exec Executes a command on Consul nodes force-leave Forces a member of the cluster to enter the "left" state info Provides debugging information for operators join Tell Consul agent to join cluster keygen Generates a new encryption key keyring Manages gossip layer encryption keys kv Interact with the KV store leave Gracefully leaves the Consul cluster and shuts down lock Execute a command holding a lock maint Controls node or service maintenance mode members Lists the members of a Consul cluster monitor Stream logs from a Consul agent operator Provides cluster-level tools for Consul operators reload Triggers the agent to reload configuration files rtt Estimates network round trip time between nodes version Prints the Consul version watch Watch for changes in Consul
想要獲得的頂的命令的幫助，可以使用-h獲取幫助，如下：
$ consul join -h
Agent
Agent是Consul的核心，用來運行代理者，維護成員的信息，運行檢測，處理查詢信息等。
catalog
consul catalog
該命令用來接Consul目錄進行交互。
列出數據中心
consul catalog datacenters
列出節點
consul catalog nodes
列出所有提供服務的節點
consul catalog nodes -service=redis
列出所有的服務器
consul catalog services
Event
consul event
event提供了一種將自定義用戶事件觸發到整個數據中心的機制,這些事件對Consul是不透明的，但它們可用於構建腳本基礎架構，以進行自動部署，重新啓動服務或執行任何其他編排操作。Event可以通過使用watch來處理。event的傳播是通過流言傳播協議的。
Exec
consul exec
exec命令提供了遠程執行的機制。下表顯示了執行此命令索要的ACL。
| ACL Required | 範圍 |
|---|---|
| agent:read | 本地agent |
| session：write | 本地agent |
| key:write | "_rexec"字首 |
| event:write | "_rexec"字首 |
info
consul info
info命令提供了對運算符有用的各種調試信息。根據代理是客戶端還是服務器，將返回不同的子系統信息。目前有幾個頂級的鍵：
agent：提供有關agent的信息
consul：有關consul的信息——客戶端或者服務器端
raft：提供有關Raft公共信息
serf_lan:提供有關LAN流言池的信息
serf_wandf：提供有關WAN流言池的信息
join
consul join
join命令讓Consul代理加入一個現有集羣，新的Consul代理必須與集羣的至少一個現有成員共同參與現有的集羣。加入該成員後，流言層接管，跨集羣傳播更新成員的資格狀態。如果沒有加入現有的集羣，則代理是自己的孤立集羣的一部分，其他節點可以加入。
代理可以加入其它的代理。如果已經是集羣的一部分的節點加入了另一個節點，則兩個節點的集羣將加入成爲一個集羣。
Keygen
consul keygen
keygen命令生成可用於Consul代理流量加密的加密祕鑰。
Keyring
consul keyring
keyring命令用於檢查和修改Consul的流言池中使用的加密密鑰。
Lock
lock命令提供了簡單分佈式鎖定的機制。在KV存儲中的給定前綴創建鎖（或信號量），只有當被保持時，纔會調用子進程。如果鎖丟失或通信中斷，則子進程終止。鎖定器的數量可以使用-n標誌進行配置。默認情況下，允許單個持有人，並且使用鎖來進行互斥。這使用leader選舉算法。
member
menber命令輸出Consul代理人知道的當前成員名單及其狀態。節點的狀態只能是“alive”，“left”或“failed”。
Monitor
monitor命令用於連接和跟蹤正在運行的Consul代理的日誌。Monitor將顯示最近的日誌，然後繼續遵循日誌，不會退出直到中斷或直到遠程代理退出。
reload
reload命令觸發代理程序重新加載配置文件。
Snapshot
snapshot命令具有用於保存，恢復和檢查Consul服務器的狀態用於容災恢復的子命令。這些是原子的時間點快照，其中包括鍵值條目，服務目錄，準備好的查詢，會話和ACL。 Consul 0.7.1及更高版本中提供此命令。
Agent
Consul的Agent是Consul的核心。Agent維護成員的信息，註冊服務，運行檢測，響應查詢。Agent必須作爲Consul集羣的一部分的每個節點上運行。任何代理可以以兩種模式之一運行：客戶端或者服務器。服務器節點承擔了協商一致性的功能。這些節點參與了Raft，並在故障下提供了強大的一致性和可用性。服務器節點負擔越來越大意味着需要在專用的實例上運行——他們比客戶端節點更爲資源密集。客戶端節點構成了大多數的集羣，並且它們很輕量，因爲它們大多數操作的是服務器節點接口，維護自己狀態的時間很少。
參考地址：http://www.cnblogs.com/Summer7C/p/7327109.html