consul（一）什麼是consul

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，並在故障下提供了強大的一致性和可用性。服務器節點負擔愈來愈大意味着須要在專用的實例上運行——他們比客戶端節點更爲資源密集。客戶端節點構成了大多數的集羣，而且它們很輕量，由於它們大多數操做的是服務器節點接口，維護本身狀態的時間不多。