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

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

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

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

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

- LAN Gossip - 指局域網八卦池，其中包含位于同一局域網或數據中心的節點。

- WAN Gossip - 指僅包含服務器（servers）的WAN八卦池。這些服務器主要位于不同的數據中心，通常通過互聯網或廣域網進行通信。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**Consul提供強一致性保證，因為服務器使用Raft協議復制狀態**。 Consul支持豐富的運行狀況檢查，包括TCP，HTTP，Nagios / Sensu兼容腳本或基于Ture的Eureka?？蛻舳斯濣c參與基于八卦的健康檢查，該檢查分發健康檢查的工作，而不像集中式心跳，這成為可擴展性挑戰。發現請求被路由到當選的領事領導者，這允許他們默認情況下是強烈一致的。允許過時讀取的客戶端允許任何服務器處理其請求，從而允許像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。

另外，Spring Cloud官方提供對Consul的支持，網址是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

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

?

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。