這個文章我們主要來說一下Consul的基本概念，以及其實現(xiàn)的內(nèi)部原理，和Eureka的比較。

# 1.什么是Consul？
Consul是一種服務網(wǎng)格解決方案，提供具有服務發(fā)現(xiàn)，配置和分段功能的全功能控制平面。 這些功能中的每一個都可以根據(jù)需要單獨使用，也可以一起使用以構建全服務網(wǎng)格。 Consul需要數(shù)據(jù)平面并支持代理和本機集成模型。 Consul附帶一個簡單的內(nèi)置代理，因此一切都可以開箱即用，但也支持第三方代理集成，如Envoy。
Consul 提供的關鍵功能：

- 服務發(fā)現(xiàn)：Consul的客戶端可以注冊服務，例如api或mysql，其他客戶端可以使用Consul來發(fā)現(xiàn)給定服務的提供者。使用DNS或HTTP，應用程序可以輕松找到它們所依賴的服務。
- 運行狀況檢查：Consul客戶端可以提供任意數(shù)量的運行狀況檢查，這些檢查與給定服務（“是Web服務器返回200 OK”）或本地節(jié)點（“內(nèi)存利用率低于90％”）相關聯(lián)。運營人員可以使用此信息來監(jiān)控群集運行狀況，服務發(fā)現(xiàn)組件使用此信息將流量路由到遠離不健康主機的地方。
- KV 存儲：應用程序可以將Consul的層級鍵/值存儲用于任何目的，包括動態(tài)配置，功能標記，協(xié)調(diào)，領導者選舉等。簡單的HTTP API使其易于使用。
- 安全服務通信：Consul可以為服務生成和分發(fā)TLS證書，以建立相互的TLS連接。[Intentions](https://www.consul.io/docs/connect/intentions.html)(意圖）可用于定義允許哪些服務進行通信。可以使用可以實時更改的意圖輕松管理服務分段，而不是使用復雜的網(wǎng)絡拓撲和靜態(tài)防火墻規(guī)則。
- 多數(shù)據(jù)中心：Consul支持多個數(shù)據(jù)中心。這意味著Consul的用戶不必擔心構建額外的抽象層以擴展到多個區(qū)域。

#2. Consul 的架構
## 2.1 Consul 中的術語
在描述架構之前，我們提供術語表以幫助澄清正在討論的內(nèi)容：
- 代理（agent） - 代理是Consul集群的每個成員上長時間運行的守護程序。它是通過運行consul agent 命令來啟動的。代理能夠以客戶端或服務器模式運行。由于所有節(jié)點都必須運行代理，因此將節(jié)點稱為客戶端或服務器更簡單，但代理還有其他實例。所有代理都可以運行DNS或HTTP接口，并負責運行檢查并保持服務同步。

- 客戶端模式（client agent） - 客戶端是將所有RPC調(diào)用轉發(fā)到服務器的代理。客戶端是相對無狀態(tài)的。客戶端執(zhí)行的唯一后臺活動是參與LAN gossip pool（局域網(wǎng) Gossip池）。這會花費非常非常小的資源并且僅消耗少量的網(wǎng)絡帶寬。
- 服務器模式(server agent) - 服務器是具有擴展責任的代理，包括參與Raft仲裁，維護群集狀態(tài)，響應RPC查詢，與其他數(shù)據(jù)中心交換WAN Gossip（廣域網(wǎng)Gossip）以及將查詢轉發(fā)給領導者或遠程數(shù)據(jù)中心。

- 數(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ū)域將被視為單個數(shù)據(jù)中心的一部分。

- 共識 （consensus）- 在我們的文檔中使用時，我們使用共識來表示對當選領導者的協(xié)議以及對交易順序的協(xié)議。由于這些事務應用于[有限狀態(tài)機](https://en.wikipedia.org/wiki/Finite-state_machine)，因此我們對共識的定義意味著復制狀態(tài)機的一致性。[維基百科](https://en.wikipedia.org/wiki/Consensus_%28computer_science%29)上更詳細地描述了共識，[此處](https://www.consul.io/docs/internals/consensus.html)描述了我們的實現(xiàn)。

- Gossip - Consul建立在[Serf](https://www.serf.io/)之上，它提供了一個完整的[gossip 協(xié)議](https://en.wikipedia.org/wiki/Gossip_protocol)（八卦協(xié)議Gossip協(xié)議），用于多種用途。 Serf提供成員維護，故障檢測和事件廣播。我們對這些的使用在八卦文檔中有更多描述。Gossip參與隨機的節(jié)點到節(jié)點的通信，主要是通過UDP。

- LAN Gossip - 指局域網(wǎng)八卦池，其中包含位于同一局域網(wǎng)或數(shù)據(jù)中心的節(jié)點。

- WAN Gossip - 指僅包含服務器（servers）的WAN八卦池。這些服務器主要位于不同的數(shù)據(jù)中心，通常通過互聯(lián)網(wǎng)或廣域網(wǎng)進行通信。

- RPC - 遠程過程調(diào)用。這是一種允許客戶端發(fā)出服務器請求的請求/響應機制。

## 2.2 一萬英尺看Consul
讓我們分解這個圖像并描述每一塊。首先，我們可以看到有兩個數(shù)據(jù)中心，標記為“one”和“two”。 Consul為多個數(shù)據(jù)中心提供一流的支持，并期望這是常見的情況。

在每個數(shù)據(jù)中心內(nèi)，我們都有客戶端和服務端的混合體。**預計有三到五臺服務端。這在失敗和性能的可用性之間取得平衡，因為隨著更多機器的添加，共識逐漸變慢**。但是，客戶端數(shù)量沒有限制，可以輕松擴展到數(shù)千或數(shù)萬。

**數(shù)據(jù)中心中的所有節(jié)點都參與八卦協(xié)議。**這意味著有一個八卦池，其中包含給定數(shù)據(jù)中心的所有節(jié)點。這有幾個目的：首先，不需要為客戶端配置服務器的地址;發(fā)現(xiàn)是自動完成的。其次，檢測節(jié)點故障的工作不是放在服務器上，而是分布式的。這使得故障檢測比天真的心跳方案更具可擴展性。第三，它被用作消息傳遞層，用于在諸如領導者選舉等重要事件發(fā)生時進行通知。

每個數(shù)據(jù)中心中的服務器都是單個Raft對等集的一部分。這意味著他們共同選舉一個leader，一個具有額外職責的選定服務器。**領導者負責處理所有查詢和交易。作為共識協(xié)議的一部分，還必須將事務復制到所有對等體。由于此要求，當非領導者服務器收到RPC請求時，它會將其轉發(fā)給群集leader。**

**服務器節(jié)點作為WAN八卦池的一部分運行**。此池與LAN池不同，因為它針對較高的Internet延遲進行了優(yōu)化，并且預計僅包含其他Consul服務器節(jié)點。此池的目的是允許數(shù)據(jù)中心以低觸摸方式（low-touch manner)發(fā)現(xiàn)彼此。在線創(chuàng)建新的數(shù)據(jù)中心就像加入現(xiàn)有的WAN八卦池一樣簡單。由于服務器都在此池中運行，因此它還支持跨數(shù)據(jù)中心請求。**當服務器收到對不同數(shù)據(jù)中心的請求時，它會將其轉發(fā)到正確數(shù)據(jù)中心的隨機服務器。然后該服務器可以轉發(fā)給本地領導者**。

這導致數(shù)據(jù)中心之間的耦合非常低，但由于故障檢測，連接緩存和多路復用，跨數(shù)據(jù)中心請求相對快速且可靠。

通常，不會在不同的Consul數(shù)據(jù)中心之間復制數(shù)據(jù)。當對另一個數(shù)據(jù)中心中的資源發(fā)出請求時，本地Consul服務器會將RPC請求轉發(fā)給該資源的遠程Consul服務器并返回結果。如果遠程數(shù)據(jù)中心不可用，那么這些資源也將不可用，但這不會影響本地數(shù)據(jù)中心。在某些特殊情況下，可以復制有限的數(shù)據(jù)子集，例如使用[Consul的內(nèi)置ACL](https://learn.hashicorp.com/consul/day-2-operations/acl-replication)復制功能，或者像[consul-replicate](https://github.com/hashicorp/consul-replicate)這樣的外部工具。

在某些地方，客戶端代理可以緩存來自服務器的數(shù)據(jù)，以使其在本地可用，以提高性能和可靠性。示例包括連接證書Connect certificates和意圖intentions ，允許客戶端代理在沒有往返服務器的情況下做出有關入站連接請求的本地決策。某些API端點還支持可選的結果緩存。這有助于提高可靠性，因為本地代理可以繼續(xù)響應某些查詢，例如服務發(fā)現(xiàn)或從緩存連接授權，即使與服務器的連接中斷或服務器暫時不可用。

# 3. Gossip協(xié)議和Raft協(xié)議
要想理解Consul的原理，你是繞不過Gossip協(xié)議和Raft協(xié)議的。

## 3.1 八卦協(xié)議Gossip Protocol
### 3.1.1 什么是Gossip 協(xié)議
Gossip算法如其名，靈感來自辦公室八卦，只要一個人八卦一下，在有限的時間內(nèi)所有的人都會知道該八卦的信息，這種方式也與病毒傳播類似，因此Gossip有眾多的別名“閑話算法”、“疫情傳播算法”、“病毒感染算法”、“謠言傳播算法”。更多，可參見[這篇博文](https://www.cnblogs.com/xingzc/p/6165084.html)
### 3.1.2 Consul中的八卦協(xié)議
Consul使用兩個不同的八卦池。我們將每個池分別稱為LAN或WAN池。

每個數(shù)據(jù)中心Consul都有一個LAN八卦池，包含數(shù)據(jù)中心的所有成員，包括客戶端和服務器。 LAN池用于一些目的。成員資格信息允許客戶端自動發(fā)現(xiàn)服務器，減少所需的配置量。分布式故障檢測允許整個集群共享故障檢測工作，而不是集中在少數(shù)服務器上。最后，八卦池允許為領導者選舉等事件提供可靠和快速的事件廣播。

WAN池是全局唯一的，因為無論數(shù)據(jù)中心如何，所有服務器都應該參與WAN池。 WAN池提供的成員資格信息允許服務器執(zhí)行跨數(shù)據(jù)中心請求。集成故障檢測允許Consul優(yōu)雅地處理丟失連接的整個數(shù)據(jù)中心，或者只處理遠程數(shù)據(jù)中心中的單個服務器。

所有這些功能都是通過利用[Serf](https://www.serf.io/)提供的。它用作嵌入式庫以提供這些功能。從用戶的角度來看，這并不重要，因為抽象應該由Consul掩蓋。但是，作為開發(fā)人員，了解如何利用此庫非常有用。

## 3.2 Raft協(xié)議
Raft 協(xié)議，主要負責leader選舉和日志同步。
推薦你看一下[這篇博客](https://www.cnblogs.com/xybaby/p/10124083.html)，
你也可以到[這個網(wǎng)站](http://thesecretlivesofdata.com/raft/)通過動畫的方式，像玩游戲一樣在線體驗raft協(xié)議的原理。

# 4.和Eureka的比較
Eureka因為是Netflix OSS套件的一部分，2.x停止維護，不過1.x仍然是活躍的。
這里重點說下consul與Eureka的區(qū)別。和其他系統(tǒng)的比較，可[點擊此網(wǎng)址自行查看。](https://www.consul.io/intro/vs/index.html)

Eureka是一種服務發(fā)現(xiàn)工具。該體系結構主要是客戶端/服務器，每個數(shù)據(jù)中心有一組Eureka服務器，通常每個可用區(qū)域一個。通常，Eureka的客戶使用嵌入式SDK來注冊和發(fā)現(xiàn)服務。對于非本地集成的客戶端，使用Ribbon等邊車通過Eureka透明地發(fā)現(xiàn)服務。

**Eureka使用盡力而為的復制提供弱一致的服務視圖。當客戶端向服務器注冊時，該服務器將嘗試復制到其他服務器但不提供保證**。服務注冊的生存時間（TTL)很短，要求客戶端對服務器進行心跳檢測。不健康的服務或節(jié)點停止心跳后，導致它們超時并從注冊表中刪除。發(fā)現(xiàn)請求可以路由到任何服務，由于盡力復制，這些服務可以提供過時或丟失的數(shù)據(jù)。這種簡化的模型可以實現(xiàn)輕松的集群管理和高可擴展性。

**Consul提供了一系列超級功能，包括更豐富的健康檢查，鍵/值存儲和多數(shù)據(jù)中心感知**。 Consul需要每個數(shù)據(jù)中心中的一組服務器，以及每個客戶端上的代理，類似于使用像Ribbon這樣的邊車。 Consul代理允許大多數(shù)應用程序不知道Consul，通過配置文件執(zhí)行服務注冊以及通過DNS或負載平衡器sidecars進行發(fā)現(xiàn)。

**Consul提供強一致性保證，因為服務器使用Raft協(xié)議復制狀態(tài)**。 Consul支持豐富的運行狀況檢查，包括TCP，HTTP，Nagios / Sensu兼容腳本或基于Ture的Eureka。客戶端節(jié)點參與基于八卦的健康檢查，該檢查分發(fā)健康檢查的工作，而不像集中式心跳，這成為可擴展性挑戰(zhàn)。發(fā)現(xiàn)請求被路由到當選的領事領導者，這允許他們默認情況下是強烈一致的。允許過時讀取的客戶端允許任何服務器處理其請求，從而允許像Eureka一樣的線性可伸縮性。

**Consul的強一致性意味著它可以用作領導者選舉和集群協(xié)調(diào)的鎖服務。 Eureka不提供類似的保證，并且通常需要為需要執(zhí)行協(xié)調(diào)或具有更強一致性需求的服務運行ZooKeeper。**

Consul提供了支持面向服務的體系結構所需的功能工具包。這包括服務發(fā)現(xiàn)，還包括豐富的運行狀況檢查，鎖定，鍵/值，多數(shù)據(jù)中心聯(lián)合，事件系統(tǒng)和ACL。 Consul和consul-template和envconsul等生態(tài)系統(tǒng)工具都試圖最大限度地減少集成所需的應用程序更改，以避免需要通過SDK進行本機集成。 Eureka是更大的Netflix OSS套件的一部分，該套件期望應用程序相對同質(zhì)且緊密集成。因此，Eureka只解決了有限的一部分問題，期望其他工具如ZooKeeper可以同時使用。

總結一下上面的幾段話：
- Consul 通過Raft協(xié)議提供強一致性，而Eureka提供的弱一致性。
- Consul 通過Gossip協(xié)議更好分發(fā)健康檢查的工作，而不是Eureka集中式心跳（要客戶端不停地請求服務端）
- 由于Raft提供的強一致性，Consul可以用來做領導選擇，集群協(xié)議的鎖服務，而Eureka只能借助于Zookeeper。

另外，Spring Cloud官方提供對Consul的支持，網(wǎng)址是https://spring.io/projects/spring-cloud-consul，后面我會寫文章具體的使用。

# 5.參考：
https://www.consul.io/intro/index.html
https://www.consul.io/intro/vs/eureka.html
https://www.consul.io/docs/internals/architecture.html
https://www.consul.io/docs/internals/consensus.html
https://www.consul.io/docs/internals/gossip.html
https://www.cnblogs.com/xingzc/p/6165084.html
https://www.cnblogs.com/xybaby/p/10124083.html

文章之后會第一時間發(fā)于微信， 歡迎關注我的微信公眾號，大家一起交流學習

?

轉載于:https://www.cnblogs.com/YellowStar5/p/11022472.html

總結

以上是生活随笔為你收集整理的Consul 基本概念，同类比较和内部原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。