Consul 基本概念，同類比較和內部原理

這個文章咱們主要來講一下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。客戶端節點參與基於八卦的健康檢查，該檢查分發健康檢查的工做，而不像集中式心跳，這成爲可擴展性挑戰。發現請求被路由到當選的領事領導者，這容許他們默認狀況下是強烈一致的。容許過期讀取的客戶端容許任何服務器處理其請求，從而容許像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

文章以後會第一時間發於微信， 歡迎關注個人微信公衆號，你們一塊兒交流學習