由于文章太長，簡書放不下，完整文檔見Consul文檔。

一、安裝 Consul

Consul 的安裝很簡單，安裝 Consul 有以下兩種方式：

• 使用預編譯的二進制文件
• 使用源代碼安裝
  　　下載一個預編譯的二進制文件是最簡單的，我們通過TLS和SHA256總和提供下載來驗證二進制文件。 我們還分發(fā)了可以驗證的SHA256總和的PGP簽名。

1.1 預編譯的二進制文件

要安裝預編譯的二進制文件，請為您的系統(tǒng)下載相應的軟件包。 Consul目前打包成一個zip文件。 我們近期沒有提供系統(tǒng)軟件包的計劃。
　　一旦zip被下載，解壓縮到任何目錄。 內(nèi)部的Consul二進制文件是運行Consul（或者consul.exe for Windows）所必需的。 如果有任何額外的文件，請不需要運行Consul。
　　將二進制文件復制到系統(tǒng)中的任何位置。 如果您打算從命令行訪問它，請設置PATH環(huán)境變量。

1.2 從源代碼編譯

要從源代碼編譯，您需要安裝并正確配置Go（包括GOPATH環(huán)境變量集）以及PATH中的git副本。

1.2.1 從GitHub克隆Consul資源庫到你的GOPATH中：

$ mkdir -p $GOPATH/src/github.com/hashicorp && cd $!
$ git clone https://github.com/hashicorp/consul.git
$ cd consul

1.2.2 引導項目。 這將下載和編譯Consul所需的庫和工具：

$ make bootstrap

1.2.3 為你當前系統(tǒng)編譯Consul，并把二進制文件放入./bin/（相對于git checkout）。 make dev目標僅僅是一個快捷方式，只為您的本地構建環(huán)境（沒有交叉編譯的目標）構建Consul。

$ make dev

1.3 安裝驗證

要確認Consul已正確安裝，請在您的系統(tǒng)上運行consul -v。 你應該看到幫助輸出。 如果您正在從命令行執(zhí)行它，請確保已設置好PATH環(huán)境變量，否則您可能會收到Consul找不到的錯誤。

[root@localhost ~]# consul -v
Consul v1.0.1
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

二、Consul 升級

Consul是在任何參與Consul集群的節(jié)點上長期運行的代理。 這些節(jié)點一直相互通訊。 因此，在使用Consul時，協(xié)議級別的兼容性和易于升級是一個重要的事項。
　　下面介紹如何在新版本發(fā)布時升級Consul。

2.1 標準升級

為了升級，我們努力確保向后兼容性。 為了支持這個，建立了節(jié)點之間通訊協(xié)議的版本。 這使得客戶端和服務器能夠在可用時智能地啟用新功能，否則將優(yōu)雅地退回到向后兼容的操作模式。
　　對于大多數(shù)升級，過程很簡單。 假設Consul的當前版本是A，發(fā)布了版本B。

• 1、在每臺服務器上安裝Consul版本B。
• 2、關閉版本A，重新啟動版本B。
• 3、一旦所有服務器都升級完畢，就開始按照相同的流程升級客戶端。
• 4、完成！ 你現(xiàn)在正在運行最新的Consul代理。 您可以通過運行consul members來驗證這一點，以確保所有成員擁有最新版本和最高協(xié)議版本。

2.2 向后不兼容的升級

在某些情況下，可能會發(fā)布向后不兼容的更新。 這尚未成為問題，但為了支持升級，我們支持設置顯式協(xié)議版本。 這會禁用不兼容的功能并啟用兩階段升級。
　　對于下面的步驟，假設你正在運行Consul版本A，然后發(fā)布了版本B。

• 1、在每個節(jié)點上安裝Consul的B版本。
• 2、關閉版本A，并使用-protocol = PREVIOUS選項啟動版本B，其中“PREVIOUS”是版本A的協(xié)議版本（可通過運行consul -v或consul members來獲取）。
• 3、一旦所有節(jié)點都運行版本B，請遍歷每個節(jié)點并重新啟動沒有-protocol選項的版本B代理。
• 4、完成！ 你現(xiàn)在正在運行最新的Consul代理，并使用最新的協(xié)議。 您可以通過運行consul members來確認所有成員都使用同一個最新的協(xié)議版本。
  　　做這項工作的關鍵是Consul的協(xié)議兼容性。 協(xié)議版本系統(tǒng)在下面討論。

2.3 協(xié)議版本

默認情況下，Consul代理會說明最新的協(xié)議。 然而，如果有協(xié)議的變化，每一個新版本的Consul也 會說明之前的協(xié)議。
　　你可以通過運行consul -v來查看你的Consul版本所能接受的協(xié)議版本。你會看到類似于下面的輸出：

[root@localhost ~]# consul -v
Consul v1.0.1
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

這顯示的是Consul的版本，以及這個代理使用和可以接受的協(xié)議版本。
　　有時Consul會默認使用一個比它接受的更低的協(xié)議版本，以便與舊的代理兼容。 例如，接受版本3的Consul代理聲稱版本2，并且僅向接受版本3的代理發(fā)送版本3消息。這允許功能在代理升級時自動升級，并且是可能時使用的策略。 如果這是不可能的，那么您將需要使用上述說明進行不兼容的升級，并且在給定版本的說明中將清楚地列出這樣的要求。
　　通過在consul代理上指定-protocol選項，你可以告訴Consul代理使用任何可以理解的協(xié)議版本。 這只是指定協(xié)議版本。 每一個Consul代理都可以隨時了解它在consul -v上聲稱的所有協(xié)議版本。
　　通過運行以前的協(xié)議版本，Consul的某些功能，特別是較新的功能，可能無法使用。 如果是這樣的話，Consul通常會提醒你。 通常，您應該始終升級集群，以便運行最新的協(xié)議版本。

三、協(xié)議兼容性承諾

我們希望Consul能夠運行在大批長期運營的代理身上。 因為在這種環(huán)境下安全升級代理在很大程度上依賴于向后兼容性，所以我們強烈承諾保持不同Consul版本之間的協(xié)議兼容性。
　　我們承諾，Consul的每一個后續(xù)版本將保持向后兼容至少一個以前的版本。 具體地說：版本0.5可以說是0.4（反之亦然），但可能不能說0.1。
　　除非另有說明，向后兼容性是自動的。Consul代理默認會使用最新的協(xié)議，但可以理解更早的協(xié)議。
　　注意：如果使用較早的協(xié)議，新功能可能無法使用。
　　Consul 使用較早的協(xié)議的能力是確保任何代理程序都可以升級而不會造成集群中斷。 Consul代理可以一次更新一個，一次一個版本。

協(xié)議兼容性表

注意：Raft協(xié)議是單獨版本，但與至少一個以前的版本保持兼容。

四、升級特定的版本

升級部分涵蓋了進行標準升級的細節(jié)。 但是，由于新功能或行為改變，Consul的特定版本可能會提供更多的升級細節(jié)。 此處用于將這些詳細信息與標準升級流程分開記錄。

4.1 Consul 1.0.1

在升級過程中仔細檢查并刪除老的服務器。
　　在使用Raft協(xié)議3運行時，Consul 1.0（和Consul的早期版本）有一個問題，即執(zhí)行Consul服務器的滾動更新可能會導致集群中剩余的舊服務器中斷，自動控制系統(tǒng)通常會在新服務器聯(lián)機時刪除舊服務器，但還等著將服務器推向成對的投票人，以維持一個奇數(shù)的法定人數(shù)，這個成對的推廣功能被取消，服務器一旦穩(wěn)定就成為選民，使得自動控制系統(tǒng)以更安全的方式移除舊服務器。
　　從Consul 1.0升級時，您可能需要手動force-leave
將舊服務器作為Consul 1.0.1滾動更新的一部分。

4.2 Consul 1.0

Consul 1.0這里記錄了幾個重要的重大改變。升級前請務必閱讀所有的細節(jié)。

Raft協(xié)議現(xiàn)在默認為3

-raft-protocol
默認值已從2更改為3，默認啟用所有自動控制功能。
　　Raft協(xié)議版本3要求Consul在所有服務器上運行0.8.0或更高版本才能工作，所以如果您正在使用集群中較舊的服務器進行升級，則需要將其設置為2來升級。 有關更多詳細信息，請參閱Raft協(xié)議版本兼容 。用最新的Raft協(xié)議運行時，用于停機恢復的peers.json的格式也是不同的。 請參閱手動恢復使用peers.json獲取所需格式的說明。
　　請注意，Raft協(xié)議與協(xié)議兼容性承諾頁面上介紹的Consul內(nèi)部協(xié)議不同，正如在consul members和consul version中所示。要查看每臺服務器上使用的Raft協(xié)議的版本，請使用consul operator raft list-peers命令。
　　升級服務器最簡單的方法是讓每臺服務器離開集群，升級其Consul版本，然后將其添加回來。 確保新服務器成功加入，并且在將升級前滾到下一個服務器之前，集群已經(jīng)穩(wěn)定。 也可以啟動一套新的服務器，然后以相似的方式慢慢地恢復每個舊的服務器上。
　　當使用Raft協(xié)議版本3時，當Consul對其內(nèi)部Raft仲裁配置進行更改時，服務器由-node-id標識，而不是其IP地址。 這意味著，一旦集群升級了所有運行Raft協(xié)議版本3的服務器，它將不再允許運行任何舊的Raft協(xié)議版本的服務器被添加。 如果運行一個單獨的Consul服務器，重新啟動它將導致該服務器無法將自己選為領導者。 為避免這種情況，可以將Raft協(xié)議設置回2，或者使用手動恢復使用peers.json將服務器映射到Raft仲裁配置中的節(jié)點ID。

配置文件需要擴展名

作為支持Consul配置文件的HCL格式的一部分，Consul加載的所有配置文件都需要.hcl或.json擴展名，即使使用-config-file參數(shù)直接指定文件也是如此。

已棄用的選項已被刪除

Consul先前不推薦使用的命令行標志和配置選項已被刪除，因此在升級之前需要將這些選項映射到它們的等價選項。 以下是已刪除選項及其等價選項的完整列表：

statsite_prefix 重命名為 metrics_prefix

由于應用于所有統(tǒng)計提供者的statsite_prefix配置選項，statsite_prefix已重命名為metrics_prefix。 升級到此版本的Consul時需要更新配置文件。

advertise_addrs已被刪除

此配置選項已被刪除，因為它與advertise_addr和advertise_addr_wan結合使用端口冗余，并錯誤地指出您可以配置主機和端口。

下線行為改變?yōu)間o-discover Configs

使用go-discover云自動加入的-retry-join和-retry-join-wan值的格式已更改。 key = val序列中的值不能再進行URL編碼，只要它們不包含空格，反斜杠或雙引號就可以作為文字提供。如果值包含這些字符，那么在"some key"= "some value"雙引號字符串中的特殊字符可以用反斜杠\轉(zhuǎn)義。

HTTP請求類型在許多HTTP API中被強制執(zhí)行

以前使用任何HTTP請求類型的HTTP API中的許多端點現(xiàn)在檢查特定的HTTP請求類型并強制執(zhí)行它們。 這可能會破壞客戶依靠舊的行為。 以下是更新的端點和所需的HTTP請求類型的完整列表：

未經(jīng)授權的KV請求返回403

啟用ACL時，使用未經(jīng)授權的令牌讀取密鑰將返回403.之前返回了404響應。

Agent自身端點的配置部分已更改

/v1/agent/self端點的Config部分經(jīng)常被直接返回Consul的內(nèi)部數(shù)據(jù)結構之一。 這個配置結構已經(jīng)在DebugConfig下移動了，并且是為了調(diào)試使用而隨時更改的文檔，一小部分Config元素已經(jīng)被維護和記錄。 有關詳細信息，請參閱配置端點文檔。

已棄用的configtest命令已刪除

configtest命令已被棄用，并已由validate命令取代。

驗證命令中的未記錄標志已刪除

validate命令支持-config-file和-config-dir命令行標志，但沒有記錄它們。 由于不需要標志，所以這個支持已被刪除。

Metric名稱已更新

Metric名稱不再以consul.consul開頭。 為了幫助轉(zhuǎn)換儀表板和其他Metric消費者，enable_deprecated_names字段已經(jīng)添加到配置的遙測部分，這將使舊命名方案的Metric與新的一起發(fā)送。 以下前綴受到影響：

代理程序啟動時檢查已驗證

Consul代理現(xiàn)在驗證其配置中的運行狀況檢查定義，如果任何檢查無效，將在啟動時失敗。 在之前的Consul版本中，無效健康檢查會被跳過。

五、Consul 內(nèi)部實現(xiàn)

這部分內(nèi)容涵蓋Consul內(nèi)部的一些內(nèi)容，如架構，一致性和 gossip協(xié)議，以及安全模式。
注意：了解Consul的內(nèi)部是沒有必要成功地使用它。 我們在這里記錄，對于Consul如何工作是完全透明的。

5.1 Consul 架構

Consul是一個復雜的系統(tǒng)，有許多不同的靈活部件。 為了幫助Consul的用戶和開發(fā)人員了解 Consul 是如何運行的，該頁面記錄了系統(tǒng)架構。
　　高級話題！ 這個頁面涵蓋了Consul內(nèi)部的技術細節(jié)。 有效地運作和使用Consul不需要知道這些細節(jié)。 這些細節(jié)記錄在這里為那些誰想要了解他們，而不需要通過源代碼進行探討。

一些專用術語

在描述架構之前，我們提供術語表來幫助澄清正在討論的內(nèi)容：

• Agent——Agent是Consul集群中每個成員長時間運行的守護進程。它是通過運行consul agent啟動的。Agent 可以運行在client或server模式。由于所有節(jié)點都必須運行一個agent，因此將節(jié)點稱為客戶端或服務器更簡單，但agent還有其他實例。所有agent都可以運行DNS或HTTP接口，并負責運行檢查和保持服務同步。
• Client——Client是將所有RPC轉(zhuǎn)發(fā)給服務器的agent。client是相對無狀態(tài)的。client執(zhí)行的唯一后臺活動是參與局域網(wǎng)gossip池。 這具有最小的資源開銷并且僅消耗少量的網(wǎng)絡帶寬。
• Server——Server是具有擴展職責的 agent，包括參與Raft仲裁，維護集群狀態(tài)，響應RPC查詢，通過廣域網(wǎng)的 gossip與其他數(shù)據(jù)中心通訊，以及將查詢轉(zhuǎn)發(fā)給leader或遠程數(shù)據(jù)中心。
• Datacenter——雖然數(shù)據(jù)中心的定義似乎是顯而易見的，但必須考慮一些細微的細節(jié)。例如，在EC2中，多個可用區(qū)域被認為是由一個數(shù)據(jù)中心組成的？ 我們將數(shù)據(jù)中心定義為私有、低延遲和高帶寬的網(wǎng)絡環(huán)境。 這不包括通過公共互聯(lián)網(wǎng)的通信，但為了我們的目的，單個EC2區(qū)域內(nèi)的多個可用區(qū)域?qū)⒈灰暈閱蝹€數(shù)據(jù)中心的一部分。
• Consensus——在我們的文檔中使用Consensus來表示對當選領導人的同意以及對交易順序的協(xié)議。由于這些事務被應用于有限狀態(tài)機，我們對Consensus的定義意味著復制狀態(tài)機的一致性。 Consensus在Wikipedia上有更詳細的描述，我們的實現(xiàn)在這里描述。
• Gossip——Consul建立在Serf之上，它提供了一個完整的gossip協(xié)議用于多種目的。 Serf提供會員資格、失敗檢測和事件廣播。 在Gossip文檔中更多地描述了這些用法。 只要知道gossip涉及隨機的節(jié)點到節(jié)點的通信就足夠了，主要是通過UDP。
• LAN Gossip——指包含全部位于同一局域網(wǎng)或數(shù)據(jù)中心的節(jié)點的局域網(wǎng)gossip池。
• WAN Gossip——指僅包含服務器的WAN gossip池。 這些服務器主要位于不同的數(shù)據(jù)中心，通常通過互聯(lián)網(wǎng)或廣域網(wǎng)進行通信。
• RPC——遠程過程調(diào)用。 這是一個請求/響應機制，允許客戶端發(fā)出服務器請求。

內(nèi)部架構

從一萬英尺的高度來看，Consul的架構是這樣的：

Consul 架構

我們來分解這個圖像并且描述每一個部分。 首先，我們可以看到有兩個數(shù)據(jù)中心，分別是“一”和“二”。 Consul對多個數(shù)據(jù)中心有一流的支持，并期望這是常見的情況。
　　在每個數(shù)據(jù)中心內(nèi)，我們都有客戶端和服務器的混合。 預計有三到五臺服務器。 這在故障情況下的可用性和性能之間取得平衡，因為隨著更多機器的添加，一致性逐漸變慢。 但是，客戶數(shù)量沒有限制，可以輕松擴展到數(shù)千或數(shù)萬。
　　數(shù)據(jù)中心內(nèi)的所有節(jié)點都參與到gossip協(xié)議中。 這意味著有一個gossip池包含給定數(shù)據(jù)中心的所有節(jié)點。 這有幾個目的：首先，不需要為客戶端配置服務器的地址; 發(fā)現(xiàn)是自動完成的。 其次，檢測節(jié)點故障的工作不是放在服務器上，而是分布式的。 這使得失敗檢測比原來的心跳計劃更具可擴展性。 第三，它被用作消息層來通知重要事件，例如發(fā)生 leader選舉。
　　每個數(shù)據(jù)中心中的服務器都是單個Raft對等設備的一部分。 這意味著他們一起工作，選出一個單獨的leader。 leader負責處理所有查詢和交易。 交易也必須復制到所有同行作為一致性協(xié)議的一部分。 由于這個要求，當一個非leader服務器接收到一個RPC請求時，它將其轉(zhuǎn)發(fā)給集群leader。
　　服務器節(jié)點也作為WAN gossip池的一部分運行。 此池與局域網(wǎng)池不同，因為它針對較高的互聯(lián)網(wǎng)延遲進行了優(yōu)化，預計只包含其他Consul服務器節(jié)點。 這個池的目的是讓數(shù)據(jù)中心以低調(diào)的方式發(fā)現(xiàn)彼此。 在線新建一個數(shù)據(jù)中心就像加入現(xiàn)有的廣域網(wǎng)gossip一樣簡單。 因為服務器都在這個池中運行，所以它也支持跨數(shù)據(jù)中心的請求。 當服務器接收到對其他數(shù)據(jù)中心的請求時，會將其轉(zhuǎn)發(fā)到正確的數(shù)據(jù)中心中的隨機服務器。 該服務器可能會轉(zhuǎn)發(fā)給自己的 leader。
　　這導致數(shù)據(jù)中心之間的耦合度非常低，但由于故障檢測，連接緩存和多路復用，跨數(shù)據(jù)中心的請求相對較快且可靠。
　　一般來說，數(shù)據(jù)不會在不同的Consul數(shù)據(jù)中心之間復制。 當請求另一個數(shù)據(jù)中心中的資源時，本地Consul服務器將RPC請求轉(zhuǎn)發(fā)給該資源的遠程Consul服務器，并返回結果。 如果遠程數(shù)據(jù)中心不可用，那么這些資源也將不可用，但這不會影響本地數(shù)據(jù)中心。 有一些特殊情況，可以復制有限的數(shù)據(jù)子集，例如Consul的內(nèi)置ACL復制功能，或者外聯(lián)工具（如consul-replicate）。

深入研究

在這一點上，我們已經(jīng)介紹了Consul的高層架構，但是每個子系統(tǒng)都有更多的細節(jié)。 與gossip協(xié)議一樣， 一致性協(xié)議也有詳細文檔。 所使用的安全模型和協(xié)議的文檔也是可用的。
　　有關其他詳細信息，請查閱代碼，在IRC中詢問，或者聯(lián)系郵件列表。

5.2 一致性協(xié)議

Consul使用一致性協(xié)議來提供一致性（由CAP定義）。一致性協(xié)議是基于“Raft：尋找一個可理解的一致性算法”。 有關Raft的視覺解釋，請參閱數(shù)據(jù)的秘密生活。

Raft 協(xié)議概述

Raft是基于Paxos的一致性算法。與Paxos相比，Raft被設計為具有更少的狀態(tài)和更簡單，更易于理解的算法。
　　在討論Raft時有幾個關鍵的術語：

• Log——Raft系統(tǒng)的主要工作單位是日志條目。 一致性問題可以分解為復制日志。 日志是條目的有序序列。 如果所有成員對條目和順序達成一致，我們認為日志是一致的。
• FSM——有限狀態(tài)機。 有限狀態(tài)機是有限狀態(tài)的集合，它們之間有轉(zhuǎn)換。 隨著新的日志被應用，F(xiàn)SM被允許在狀態(tài)之間轉(zhuǎn)換。 應用相同的日志序列必須導致相同的狀態(tài)，這意味著行為必須是確定性的。
• Peer set——對等集是參與日志復制的所有成員的集合。 為了Consul的目的，所有服務器節(jié)點都在本地數(shù)據(jù)中心的對等集中。
• Quorum——法定人數(shù)是同行中的大多數(shù)成員：對于一組規(guī)模n，法定人數(shù)至少需要(n/2)+1個成員。 例如，如果對等集中有5個成員，則需要3個節(jié)點來形成法定人數(shù)。 如果由于某種原因?qū)е路ǘ〝?shù)量的節(jié)點不可用，則集群變得不可用，并且不能提交新的日志。
• Committed Entry——當一個條目持久地存儲在一個法定的節(jié)點上時，這個條目被認為是提交的。 一旦條目被提交，就可以應用。
• Leader——在任何給定的時間，對等組選擇單個節(jié)點作為領導者。 領導者負責接收新的日志條目，復制到關注者，以及管理條目何時被提交。
  　　Raft是一個復雜的協(xié)議，在這里不會詳細介紹（對于那些希望得到更全面了解的人，這篇文章有更詳細介紹）。但是，我們會試圖提供一個高層次的描述，這對于建立一個總體的認識可能是有用的。
  　　Raft 節(jié)點處于三種狀態(tài)之一：follower, candidate, leader。所有節(jié)點最初都是作為follower開始的。在這個狀態(tài)下，節(jié)點可以接受 leader 的日志條目和投票。如果一段時間內(nèi)沒有收到條目，則節(jié)點自我提升到candidate狀態(tài)。在candidate狀態(tài)，節(jié)點向同伴請求投票。如果candidate獲得法定人數(shù)，則提升為 leader。leader 必須接受新的日志條目并且復制到其它的 follower 上。另外，如果陳舊的數(shù)據(jù)不可接受，則所有的查詢也必須在 leader 上進行。
  　　一旦一個集群有一個 leader，它就能接受新的日志條目。客戶端可以請求 leader 增加一個新的日志條目（從 Raft 角度來看，日志條目是一個不透明的二進制 blob）。然后，leader將條目寫入持久存儲，并嘗試復制到其它的 follower 上面。一旦日志條目被認為是提交的，它可以應用到有限狀態(tài)機。有限狀態(tài)機是應用程序特定的；在 Consul 里，我們使用MemDB去維護集群的狀態(tài)。Consul 在 committed 和 applied 時會進行寫阻塞。在與查詢的一致模式一起使用時，這實現(xiàn)了在寫入語義之后的讀取。
  　　顯然，允許日志復制無限制的增長是不可取的。Raft 提供了一種機制，通過該機制，當前狀態(tài)被快照并且日志被壓縮。由于FSM抽象，恢復FSM的狀態(tài)必須導致與舊日志重播相同的狀態(tài)。這允許Raft在某個時間點捕獲FSM狀態(tài)，然后刪除所有用來達到該狀態(tài)的日志。這是在沒有用戶干預的情況下自動執(zhí)行的，并且可以防止無限制的磁盤使用，同時最大限度地減少重新使用日志的時間。使用BoltDB的好處之一是它允許Consul繼續(xù)接受新的事務，即使在舊狀態(tài)被快照時，也防止了任何可用性問題。
  　　一致性直到到達法定人數(shù)都是容錯的。如果法定人數(shù)的節(jié)點不可用，則是無法處理日志條目和同伴成員的理由。例如：假設只有兩個對等體 A 和 B。則法定人數(shù)大小就是2，這意味著兩個節(jié)點必須同意提交日志條目。如果 A 或 B 失敗，現(xiàn)在不可能達到法定人數(shù)。這意味著集群無法添加或刪除節(jié)點或提交任何其他日志條目。這導致不可用。此時，需要手動干預來移除 A 或 B，并且在引導模式下重新啟動剩余的節(jié)點。
  　　3個節(jié)點的 Raft 集群可以容忍單個節(jié)點故障，而5個節(jié)點的集群可以容忍2個節(jié)點故障。推薦的配置是每個數(shù)據(jù)中心配置3或5個 Consul 服務器。這最大限度地提高可用性，而不會大大犧牲性能。下面的部署表總結了潛在的集群大小和每個集群的容錯。
  　　在性能方面，Raft 與Paxos相當。假設穩(wěn)定的領導，提交日志條目需要一次往返一半的群集。 因此，性能受到磁盤I / O和網(wǎng)絡延遲的限制。盡管Consul并不是一個高吞吐量的寫入系統(tǒng)，但它依賴于網(wǎng)絡和硬件配置，每秒處理數(shù)百到數(shù)千個事務。

Consul 里的 Raft

只有Consul服務器節(jié)點參與Raft并且是對等集合的一部分。所有客戶端節(jié)點都向服務器轉(zhuǎn)發(fā)請求。這種設計的部分原因是，隨著更多的成員被添加到對等設置，法定數(shù)量的大小也增加。 這會引起性能問題，因為您可能正在等待數(shù)百臺機器同意進入而不是少數(shù)幾臺機器。
　　開始時，一個Consul服務器被置于“bootstrap”模式。這種模式可以讓自己當選領導者。 一旦領導者被選舉出來，其他服務器可以被添加到對等組中，以保持一致性和安全性。 最后，一旦添加了前幾個服務器，引導模式可以被禁用。更詳細的介紹參考這個文檔
。
　　由于所有服務器都作為對等設備的一部分參與，他們都知道當前的領導者。 當RPC請求到達非領導服務器時，請求被轉(zhuǎn)發(fā)給領導。 如果RPC是查詢類型，意味著它是只讀的，那么領導者將根據(jù)FSM的當前狀態(tài)生成結果。 如果RPC是一個事務類型，這意味著它修改了狀態(tài)，那么領導者會生成一個新的日志條目并使用Raft來應用它。 一旦日志條目被提交并應用到FSM，交易就完成了。
　　由于Raft復制的性質(zhì)，性能對網(wǎng)絡延遲很敏感。 出于這個原因，每個數(shù)據(jù)中心選擇一個獨立的領導者，并維護一個不相交的對等集。 數(shù)據(jù)由數(shù)據(jù)中心分區(qū)，因此每個領導者只負責數(shù)據(jù)中心的數(shù)據(jù)。 當收到遠程數(shù)據(jù)中心的請求時，請求被轉(zhuǎn)發(fā)給正確的領導。 這種設計允許更低的延遲交易和更高的可用性而不犧牲一致性。

一致性模式

盡管所有對復制日志的寫入都是通過Raft進行的，但讀取更靈活。 為了支持開發(fā)人員可能需要的各種權衡，Consul支持3種不同的讀取一致性模式。
　　三種讀取模式是：

• default。參考這篇文章為 Raft 引入 leader lease 機制解決集群腦裂時的 stale read 問題。
• consistent。這種模式是非常一致的，沒有告誡。 它要求一個領導者與一個同事的法定人數(shù)進行核實，它仍然是領導者。 這引入了所有服務器節(jié)點的額外往返。 折衷總是一致的讀取，但由于額外的往返導致延遲增加。
• stale。這種模式允許任何服務器為讀取服務，而不管它是否是領導者。 這意味著讀取可以任意陳舊，但通常在領導者的50毫秒內(nèi)。 權衡是非?？焖俸涂蓴U展的讀取，但陳舊的價值。 這種模式允許沒有領導者的讀取意味著不可用的集群仍然能夠響應。
  　　有關使用這些不同模式的更多文檔，參考HTTP API。

部署表

以下是顯示各種群集大小的法定大小和容錯的表格。 推薦的部署是3或5個服務器。 一個單一的服務器部署是非常不鼓勵的，因為在故障情況下數(shù)據(jù)丟失是不可避免的。

5.3 Gossip Protocol

Consul使用Gossip Protocol來管理成員資格并向集群廣播消息。所有這些都是通過使用Serf庫提供的。Serf使用的Gossip Protocol是基于"SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol"，并進行了一些小修改。Serf's protocol詳情請看這里。

Gossip in Consul

領事使用兩個不同的gossip池。 我們將每個池分別稱為LAN或WAN池。 每個Consul運行的數(shù)據(jù)中心都有一個包含數(shù)據(jù)中心所有成員（包括客戶端和服務器）的LAN gossip池。 LAN池用于幾個目的。 成員信息允許客戶端自動發(fā)現(xiàn)服務器，減少所需的配置量。 分布式故障檢測允許整個集群共享故障檢測工作，而不是集中在幾臺服務器上。 最后，gossip池允許可靠和快速的事件廣播，如領導人選舉事件。
　　WAN池是全球唯一的，因為無論數(shù)據(jù)中心如何，所有服務器都應該參與WAN池。 WAN池提供的成員資格信息允許服務器執(zhí)行跨數(shù)據(jù)中心請求。 集成的故障檢測功能使Consul可以正常處理丟失連接的整個數(shù)據(jù)中心，或者只處理遠程數(shù)據(jù)中心內(nèi)的單個服務器。
　　所有這些功能都是利用Serf提供的。 它被用作嵌入式庫來提供這些功能。 從用戶的角度來看，這并不重要，因為抽象應該被Consul所掩蓋。 作為一名開發(fā)人員，了解這個庫如何被利用是非常有用的。

Lifeguard Enhancements

SWIM假定本地節(jié)點是健康的，因為軟實時處理包是可能的。 但是，如果本地節(jié)點遇到CPU或網(wǎng)絡耗盡，則可能違反此假設。 其結果是，serfHealth檢查狀態(tài)可能會偶爾發(fā)生抖動，導致錯誤的監(jiān)視警報，增加了遙測的噪聲，并導致整個群集浪費CPU和網(wǎng)絡資源來診斷可能不存在的故障。
　　Lifeguard通過SWIM的新型增強完全解決這個問題。
　　有關Lifeguard的更多詳情，請閱讀Making Gossip More Robust with Lifeguard這篇博客文章，其中提供了HashiCorp研究論文的高級概述Lifeguard : SWIM-ing with Situational Awareness。Serf gossip protocol guide還提供了有關gossip protocol 和 Lifeguard的一些較低層次的細節(jié)。

5.4 Network Coordinates

Consul使用網(wǎng)絡層析成像系統(tǒng)來計算集群中節(jié)點的網(wǎng)絡坐標。 這些坐標允許使用非常簡單的計算在任何兩個節(jié)點之間估計網(wǎng)絡往返時間。 這允許許多有用的應用程序，例如查找離請求節(jié)點最近的服務節(jié)點，或者故障轉(zhuǎn)移到下一個最近的數(shù)據(jù)中心中的服務。
　　所有這些都是通過使用Serf庫提供的。 Serf的網(wǎng)絡層析成像基于"Vivaldi: A Decentralized Network Coordinate System"，并基于其他研究進行了一些改進。 這里有關于Serf的網(wǎng)絡坐標的更多細節(jié)。

Network Coordinates in Consul

Consul內(nèi)部的網(wǎng)絡坐標清單有幾種形式：

• consul rtt命令可用于查詢?nèi)我鈨蓚€節(jié)點之間的網(wǎng)絡往返時間。
• 目錄端點和運行狀況端點可以使用"?near="參數(shù)根據(jù)給定節(jié)點的網(wǎng)絡往返時間對查詢結果進行排序。
• 準備好的查詢可以根據(jù)網(wǎng)絡往返時間自動將服務故障轉(zhuǎn)移到其他Consul數(shù)據(jù)中心。 有關示例，請參閱地理故障轉(zhuǎn)移。
• 坐標端點顯示原始網(wǎng)絡坐標以用于其他應用程序。
  　　Consul使用Serf來管理兩個不同的gossip池，一個是給定數(shù)據(jù)中心成員的局域網(wǎng)，另一個是由所有數(shù)據(jù)中心的Consul服務器組成的WAN。 請注意，這兩個池之間的網(wǎng)絡坐標不兼容。 局域網(wǎng)坐標只有在與其他局域網(wǎng)坐標進行計算時才有意義，而廣域網(wǎng)坐標只對其他廣域網(wǎng)坐標有意義。

使用坐標

一旦有了它們的坐標，計算任何兩個節(jié)點之間估計的網(wǎng)絡往返時間就很簡單。 以下是從坐標端點返回的示例坐標。

    "Coord": {
        "Adjustment": 0.1,
        "Error": 1.5,
        "Height": 0.02,
        "Vec": [0.34,0.68,0.003,0.01,0.05,0.1,0.34,0.06]
    }

所有值都是以秒為單位的浮點數(shù)，除了不用于距離計算的誤差項。
　　Go中有一個完整的例子，展示了如何計算兩個坐標之間的距離：

import (
    "math"
    "time"

    "github.com/hashicorp/serf/coordinate"
)

func dist(a *coordinate.Coordinate, b *coordinate.Coordinate) time.Duration {
    // Coordinates will always have the same dimensionality, so this is
    // just a sanity check.
    if len(a.Vec) != len(b.Vec) {
        panic("dimensions aren't compatible")
    }

    // Calculate the Euclidean distance plus the heights.
    sumsq := 0.0
    for i := 0; i < len(a.Vec); i++ {
        diff := a.Vec[i] - b.Vec[i]
        sumsq += diff * diff
    }
    rtt := math.Sqrt(sumsq) + a.Height + b.Height

    // Apply the adjustment components, guarding against negatives.
    adjusted := rtt + a.Adjustment + b.Adjustment
    if adjusted > 0.0 {
        rtt = adjusted
    }

    // Go's times are natively nanoseconds, so we convert from seconds.
    const secondsToNanoseconds = 1.0e9
    return time.Duration(rtt * secondsToNanoseconds)
}

5.5 Sessions

Consul提供了一個可用于構建分布式鎖的會話機制。 會話充當節(jié)點之間的綁定層，運行狀況檢查和鍵/值數(shù)據(jù)。 它們旨在提供細粒度鎖定，并深受The Chubby Lock Service for Loosely-Coupled Distributed Systems的啟發(fā)。

Session Design

Consul中的一個會話代表一個具有非常特定語義的合約。 當構建會話時，可以提供節(jié)點名稱，健康檢查列表，行為，TTL和鎖定延遲。 新構建的會話提供了一個可用于標識的命名標識。 該ID可以與KV存儲一起使用以獲取鎖定：用于相互排斥的咨詢機制。
　　以下是顯示這些組件之間的關系的圖表：

image.png

Consul所提供的合約，在下列情況下， 會話將失效：

• 節(jié)點被注銷
• 任何健康檢查被取消注冊
• 任何健康檢查進入臨界狀態(tài)
• 會話被明確銷毀
• TTL到期，如果適用
  　　當會話失效時，會話被破壞，不能再使用。 關聯(lián)的鎖發(fā)生什么取決于在創(chuàng)建時指定的行為。 Consul支持發(fā)布和刪除行為。 如果沒有指定，則釋放行為是默認行為。
  　　如果正在使用釋放行為，則釋放與該會話關聯(lián)的任何鎖，并且該密鑰的ModifyIndex遞增。 或者，如果使用刪除行為，則簡單地刪除與任何保持鎖相對應的密鑰。 這可以用來創(chuàng)建Consul自動刪除的臨時條目。
  　　雖然這是一個簡單的設計，但卻可以實現(xiàn)多種使用模式。 默認情況下，基于gossip的故障檢測器被用作關聯(lián)的健康檢查。 這個失敗檢測器允許Consul檢測一個正在鎖定的節(jié)點何時失敗并自動釋放鎖定。 這種能力為Consul鎖提供活力。 即在失敗的情況下，系統(tǒng)可以繼續(xù)取得進展。 但是，由于沒有完美的故障檢測器，所以即使鎖擁有者仍然活著，也可能產(chǎn)生誤報（檢測到故障），從而導致鎖被釋放。 這意味著我們正在犧牲一些安全。
  　　相反，可以創(chuàng)建沒有關聯(lián)健康檢查的會話。 這消除了假陽性的可能性，并且為了安全而進行交易。 你絕對可以肯定，即使現(xiàn)有業(yè)主失敗，Consul也不會解鎖。 由于Consul API允許會話強制銷毀，因此可以構建系統(tǒng)，在發(fā)生故障的情況下需要操作員進行干預，同時排除了腦裂的可能性。
  　　第三種健康檢查機制是會話TTL。 創(chuàng)建會話時，可以指定TTL。 如果TTL時間間隔過期而沒有更新，則會話已經(jīng)過期并觸發(fā)失效。 這種類型的故障檢測器也被稱為心跳故障檢測器。 它比基于gossip的故障檢測器的可擴展性低，因為它增加了對服務器的負擔，但在某些情況下可能適用。 TTL的合同是代表失效的下限; 也就是說Consul在達到TTL之前不會過期會話，但是允許延遲超過TTL的期限。 TTL在會話創(chuàng)建，會話更新和領導者故障切換時被更新。 使用TTL時，客戶端應該了解時鐘偏移問題：即客戶端上的時間不能像Consul服務器上那樣以相同的速率進行。 最好設置保守的TTL值，并在TTL之前更新以解決網(wǎng)絡延遲和時間偏差。
  　　最后的細微差別是會話可能會提供鎖定延遲。 這是一個持續(xù)時間，介于0到60秒之間。 當會話失效發(fā)生時，Consul防止在鎖定延遲時間間隔內(nèi)重新獲得之前保存的任何鎖定; 這是Google的Chubby所鼓舞的保障。 這種延遲的目的是讓潛在的現(xiàn)場領導者檢測到失效并停止處理可能導致不一致狀態(tài)的請求。 雖然不是一個防彈的方法，但它確實避免了將睡眠狀態(tài)引入到應用程序邏輯中的需要，并且可以幫助減輕許多問題。 默認情況下是使用15秒的延遲，客戶端可以通過提供零延遲值來禁用此機制。

K/V集成

KV存儲和會話之間的整合是會話使用的主要場所。 會話必須在使用之前創(chuàng)建，然后通過其ID來引用。
　　KV API被擴展為支持獲取和發(fā)布操作。 獲取操作的行為類似于“檢查和設置”操作，只有在沒有現(xiàn)有鎖持有者（當前鎖持有者可以重新獲取，見下文）時才能成功。 成功時，會有一個正常的密鑰更新，但LockIndex也有一個增量，Session值會更新以反映持有該鎖的會話。
　　如果在獲取期間鎖已經(jīng)被給定的會話持有，那么LockIndex不會遞增，而是關鍵內(nèi)容被更新。 這使得當前鎖持有者可以更新關鍵內(nèi)容，而不必放棄鎖并重新獲取它。
　　一旦舉行，鎖可以釋放使用相應的釋放操作，提供相同的會話。 再次，這就像一個檢查和設置操作，因為如果給定一個無效的會話，請求將失敗。 一個重要的注意事項是鎖可以被釋放，而不是會話的創(chuàng)建者。 這是設計上的，因為它允許運營商進行干預，并在必要時強制終止會話。 如上所述，會話失效也會導致所有持有的鎖被釋放或刪除。 當一個鎖被釋放時，LockIndex不會改變; 但是，會話被清除并且ModifyIndex遞增。
　　這些語義（大量借用Chubby）允許（Key，LockIndex，Session）的元組作為唯一的“音序器”。 該順控程序可以被傳遞并用于驗證請求是否屬于當前鎖持有者。 因為每次獲取都會增加LockIndex，即使同一個會話重新獲取一個鎖，排序器也能夠檢測到一個陳舊的請求。 同樣，如果一個會話是無效的，與給定的LockIndex對應的Session將是空白的。
　　要清楚的是，這個鎖定系統(tǒng)是純粹的咨詢。 沒有強制執(zhí)行，客戶必須獲得一個鎖來執(zhí)行任何操作。 任何客戶端都可以讀取，寫入和刪除一個密鑰，而不必擁有相應的鎖。 領事的目標不是保護不當客戶。

Leader Election

會話提供的原語和KV存儲的鎖定機制可用于構建客戶端領導者選舉算法。 這些在leader選舉指南中有更詳細的介紹。

Prepared Query Integration

準備好的查詢可以附加到會話中，以便在會話失效時自動刪除準備好的查詢。

5.6 Anti-Entropy

Consul使用維護服務和健康信息的先進方法。本頁詳細介紹了如何注冊服務和檢查，如何填充目錄以及在更改時更新健康狀態(tài)信息的方式。

組件

首先要了解服務和健康檢查中涉及的組件：Agent和catalog。這些在下面的概念描述，使Anti-Entropy更容易理解。

Agent

每個Consul Agent維護自己的一套服務和檢查注冊以及健康信息。Agent負責執(zhí)行自己的健康檢查并更新其本地狀態(tài)。
　　Agent上下文中的服務和檢查具有豐富的可用配置選項。 這是因為Agent負責通過使用健康檢查來生成關于其服務及其健康的信息。

Catalog

Consul的服務發(fā)現(xiàn)由服務目錄支持。該目錄是通過匯總Agent提交的信息而形成的。該目錄維護集群的高級視圖，包括哪些服務可用，哪些節(jié)點運行這些服務，健康信息等等。該目錄用于通過Consul提供的各種接口公開這些信息，包括DNS和HTTP。
　　與Agent相比，目錄上下文中的服務和檢查具有更為有限的一組字段。 這是因為該目錄僅負責記錄和返回有關服務，節(jié)點和運行狀況的信息。
　　該目錄僅由服務器節(jié)點維護。這是因為目錄是通過Raft日志復制的，以提供對集群的統(tǒng)一和一致的視圖。

Anti-Entropy

熵是系統(tǒng)日益混亂的趨勢。Consul的反熵機制旨在對付這種趨勢，甚至通過其組成部分的失敗來保持集群的狀態(tài)。
　　如上所述，Consul在全局目錄和Agent 本地之間有明確的分離。反熵機制調(diào)和了這兩種世界觀：反熵是本地Agent與目錄的同步。 例如，當用戶注冊新服務或與Agent核對時，Agent會依次通知目錄該新的支票存在。 同樣，從代理中刪除支票時，也會從目錄中刪除支票。
　　反熵也被用來更新可用性信息。 當代理商運行健康檢查時，他們的狀態(tài)可能會改變，在這種情況下，他們的新狀態(tài)將被同步到目錄中。 使用這些信息，目錄可以根據(jù)其可用性，智能地響應有關其節(jié)點和服務的查詢。
　　在此同步過程中，還會檢查目錄的正確性。 如果目錄中存在Agent不知道的任何服務或檢查，它們將被自動刪除，以使目錄反映該Agent的適當?shù)囊唤M服務和運行狀況信息。 Consul將Agent的狀態(tài)視為權威；如果Agent和目錄視圖之間有任何差異，則將始終使用Agent本地視圖。

定期同步

除了在對Consul進行更改時運行外，反熵也是一個長期運行的過程，它會定期喚醒以同步服務并檢查目錄中的狀態(tài)。 這可以確保目錄與Agent的真實狀態(tài)緊密匹配。 這也使Consul能夠重新填充服務目錄，即使在數(shù)據(jù)丟失的情況下也是如此。
　　為避免飽和，定期反熵運行之間的時間量將根據(jù)集群大小而變化。 下表定義了集群大小和同步間隔之間的關系：

上面的時間間隔是近似的。每個Consul代理將在間隔窗口內(nèi)選擇一個隨機錯開的開始時間，以避免雷鳴般的牛群。

盡力而為的同步

在一些情況下，反熵可能會失敗，包括代理程序或其運行環(huán)境配置錯誤，I / O問題（完整磁盤，文件系統(tǒng)權限等），網(wǎng)絡問題（代理程序無法與服務器通信）等等。 因此，代理嘗試以盡力而為的方式進行同步。
　　如果在反熵運行期間遇到錯誤，則會記錄錯誤，并且代理繼續(xù)運行。 定期運行反熵機制以自動從這些類型的瞬態(tài)故障中恢復。

EnableTagOverride

服務注冊的同步可以被部分修改以允許外部代理改變服務的標簽。 這在外部監(jiān)視服務需要成為標簽信息的真實來源的情況下非常有用。 例如，Redis數(shù)據(jù)庫及其監(jiān)控服務Redis Sentinel就有這種關系。 Redis實例負責其大部分配置，但Sentinel確定Redis實例是主要還是次要實例。 使用Consul服務配置項EnableTagOverride，您可以指示運行Redis數(shù)據(jù)庫的Consul代理在反熵同步期間不更新標簽。 有關更多信息，請參閱服務頁面。

5.7 安全模型

Consul依靠輕量級gossip機制和RPC系統(tǒng)來提供各種功能。這兩個系統(tǒng)都有不同的安全機制。然而，Consul的安全機制有一個共同的目標：提供機密性，完整性和認證。
　　gossip協(xié)議由Serf提供支持，Serf使用對稱密鑰或共享密鑰加密系統(tǒng)。 這里有更多關于Serf安全的細節(jié)。 有關如何在Consul中啟用Serf的gossip加密的詳細信息，請參閱此處的加密文檔。
　　RPC系統(tǒng)支持使用端對端的TLS和可選的客戶端認證。 TLS是廣泛部署的非對稱密碼系統(tǒng)，是網(wǎng)絡安全的基礎。
　　這意味著Consul溝通是防止竊聽，篡改和欺騙。 這使得Consul可以通過不受信任的網(wǎng)絡（如EC2和其他共享主機提供商）運行。

威脅模型

以下是我們的威脅模型的各個部分：

• 非會員可以訪問數(shù)據(jù)
• 由于惡意消息而導致集群狀態(tài)操作
• 由于惡意消息而產(chǎn)生假數(shù)據(jù)
• 篡改造成國家腐敗
• 針對節(jié)點的拒絕服務
  　　另外，我們認識到，可以長時間觀察網(wǎng)絡流量的攻擊者可以推斷集群成員。 Consul使用的gossip機制依賴于向隨機成員發(fā)送消息，因此攻擊者可以記錄所有目標并確定群集的所有成員。
  　　在將安全性設計為系統(tǒng)時，將其設計為適合威脅模型。 我們的目標不是保護絕密數(shù)據(jù)，而是提供一個“合理的”安全級別，要求攻擊者投入大量的資源來擊敗。

網(wǎng)絡端口

有關配置網(wǎng)絡規(guī)則以支持Consul，請參閱Consul使用的端口列表以及使用哪些功能的詳細信息。

5.8 Jepsen Testing

Jepsen是由Kyle Kingsbury編寫的一個工具，旨在測試分布式系統(tǒng)的分區(qū)容差。 它創(chuàng)建網(wǎng)絡分區(qū)，同時隨機操作模糊系統(tǒng)。 分析結果，看看系統(tǒng)是否違反了它聲稱擁有的任何一致性屬性。
　　作為我們Consul測試的一部分，我們運行了一個Jepsen測試來確定是否可以發(fā)現(xiàn)任何一致性問題。 在我們的測試中，Consul從分區(qū)中恢復正常，沒有引入任何一致性問題。

Running the tests

目前，使用Jepsen進行測試相當復雜，因為它需要設置多個虛擬機，SSH密鑰，DNS配置以及一個可用的Clojure環(huán)境。 我們希望盡快為我們的Consul測試代碼貢獻一份測試代碼，并為Jepsen測試提供一個Vagrant環(huán)境。

Output

以下是Jepsen的輸出。 我們多次跑Jepsen，每次都是通過的。 這個輸出僅代表一次運行。

六、Consul命令（CLI）

見Consul命令（CLI），太長簡書放不下。