Consul架構介紹
Consul是由HashiCorp基於Go語言開發的支援多資料中心分散式高可用的服務釋出和註冊服務軟體，採用Raft演算法保證服務的一致性，且支援健康檢查。
Consul架構
只有一個數據中心的Consul的架構圖如下：
Architecture
我們可以看到，有三個不同的伺服器由Consul管理。整個架構通過使用Raft演算法工作，這有助於我們從三個不同的伺服器中選出一個領導者。然後根據諸如Follower和Leader之類的標籤標記這些伺服器。顧名思義，Follower有責任遵循Leader的決定。這三個伺服器之間進一步相互連線以進行通訊。
每個伺服器使用RPC與其自己的客戶端進行互動。客戶端之間的通訊是使用Gossip協議。可以使用TCP或Gossip來提供與網際網路設施的通訊。
Raft演算法
Raft是提供一致性的演算法。它依賴於CAP定理的原理，該定理指出，在存在網路分割槽的情況下，必須在一致性和可用性之間進行選擇。並非CAP定理的所有三個基本原理：Consistency(一致性)、Availability(可用性)、Partition Tolerance(分割槽容錯性)，都可以在任何給定的時間點實現。人們必須在最好的情況下權衡其中任何兩個。
一個Raft叢集包含多個伺服器，通常是奇數的。例如，如果我們有五臺伺服器，它將允許系統容忍兩個故障。在任何給定時間，每個伺服器都處於以下三種狀態之一：Leader，Follower或Candidate。在正常操作中，只有一個領導者，所有其他伺服器都是Follower。這些Follower處於被動狀態，即他們自己不發出請求，而只是響應Leader和Candidate的請求。
下圖描述了使用Raft演算法工作的工作流模型
Raft演算法
協議型別
Consul中有兩種型別的協議，稱為
- Consensus協議
- Gossip協議
現在讓我們詳細瞭解它們。
Consensus Protocol
Consul使用Consensus protocol來提供CAP定理所描述的一致性。該協議基於Raft演算法，其中Raft節點始終處於三種狀態中的任何一種：Follower, Candidate or Leader。
- Leader，負責Client互動和log複製，同一時刻系統中最多存在1個
- Follower，被動響應請求RPC，從不主動發起請求RPC
- Candidate，由Follower向Leader轉換的中間狀態
初始時所有節點都是以Follower啟動。一個最小的 Raft 叢集需要三個參與者，這樣才可能投出多數票。當發起選舉時，如果每方都投給了自己，結果沒有任何一方獲得多數票。之後每個參與方隨機休息一陣（Election Timeout）重新發起投票直到一方獲得多數票。這裡的關鍵就是隨機 timeout，最先從timeout中恢復發起投票的一方向還在 timeout 中的另外兩方請求投票，這時它們就只能投給對方了，這樣很快就能達成一致。
Gossip Protocol
Gossip協議可用於管理成員資格，跨群集傳送和接收訊息。在Consul中，Gossip協議的使用以兩種方式發生，WAN（無線區域網路）和LAN（區域網）。有三個已知的庫，可以實現Gossip演算法來發現對等網路中的節點 ：
- teknek-gossip - 它與UDP一起使用，用Java編寫。
- gossip-python - 它利用TCP堆疊，也可以通過構建的網路共享資料。
- Smudge - 它是用Go編寫的，使用UDP來交換狀態資訊。
Gossip協議也被用於實現和維護分散式資料庫一致性或與一致狀態的其他型別資料，計算未知大小的網路中的節點數量，穩健地傳播訊息，組織節點等。
Remote Procedure Calls
RPC可以表示為遠端過程呼叫的簡寫形式。它是一個程式用於從另一個程式請求服務的協議。此協議可以位於網路上的另一臺計算機中，而無需確認網路詳細資訊。
在Consul中使用RPC的真正用處在於，它可以幫助我們避免大多數發現服務工具在一段時間之前所遇到的延遲問題。在RPC之前，Consul過去只使用基於TCP和UDP的連線，這對大多數系統都很好，但對於分散式系統則不行。RPC通過減少從一個地方到另一個地方的分組資訊傳輸的時間段來解決這些問題。