Consul - 架構

Consul在一個數據中心工作的架構圖如下所示：

我們可以看到，有三個不同的伺服器由Consul管理。其工作架構透過使用Raft演算法來實現，該演算法幫助我們從三個不同的伺服器中選舉出一個領導者。然後根據標籤（例如**跟隨者**和**領導者**）對這些伺服器進行標記。顧名思義，跟隨者負責遵循領導者的決策。所有這三個伺服器都相互連線以進行任何通訊。

每個伺服器都使用RPC的概念與其自己的客戶端進行互動。客戶端之間的通訊是由於下面提到的**Gossip協議**。可以使用TCP或Gossip通訊方法實現與網際網路的連線。此通訊直接與三個伺服器中的任何一個聯絡。

Raft演算法

Raft是一種用於管理複製日誌的共識演算法。它依賴於**CAP定理**的原理，該定理指出，在網路分割槽存在的情況下，必須在一致性和可用性之間進行選擇。在任何給定時間點都不能實現CAP定理的所有三個基本要素。必須最好地權衡其中的兩個。

一個**Raft叢集**包含多個伺服器，通常數量為奇數。例如，如果我們有五個伺服器，它將允許系統容忍兩次故障。在任何給定時間，每個伺服器都處於三種狀態之一：**領導者、跟隨者**或**候選者**。在正常執行中，只有一個領導者，所有其他伺服器都是跟隨者。這些跟隨者處於被動狀態，即它們不會自行發出請求，而只是響應領導者和候選者的請求。

下圖描述了Raft演算法的工作流程模型：

鍵值資料

從Consul的0.7.1版本開始，引入了單獨的鍵值資料。KV命令用於透過命令列與Consul的鍵值儲存進行互動。它公開了用於從儲存中**插入、更新、讀取**和**刪除**的頂級命令。要獲取鍵/值物件儲存，我們呼叫consul客戶端可用的KV方法：

kv := consul.KV()

**KVPair結構**用於表示單個鍵/值條目。我們可以在以下程式中檢視Consul KV對的結構。

type KVPair struct {
   Key string
   CreateIndex uint64
   ModifyIndex uint64
   LockIndex uint64
   Flags uint64
   Value []byte
   Session string
}

此處，上述程式碼中提到的各種結構定義如下：

**鍵** - 它是一個斜槓URL名稱。例如 - sites/1/domain。
**CreateIndex** - 首次建立鍵時分配的索引號。
**ModifyIndex** - 上次更新鍵時分配的索引號。
**LockIndex** - 在鍵/值條目上獲取新鎖時建立的索引號
**Flags** - 應用可以使用它來設定自定義值。
**Value** - 它是一個最大為512kb的位元組陣列。
**Session** - 建立會話物件後可以設定。

協議型別

Consul中有兩種型別的協議，它們被稱為：

共識協議和
Gossip協議

現在讓我們詳細瞭解它們。

共識協議

Consul使用共識協議來提供CAP定理中描述的一致性。此協議基於Raft演算法。在實現共識協議時，使用Raft演算法，其中Raft節點始終處於三種狀態之一：跟隨者、候選者或領導者。

Gossip協議

Gossip協議可用於管理成員身份，在叢集之間傳送和接收訊息。在Consul中，Gossip協議的使用有兩種方式，**WAN**（無線區域網）和**LAN**（區域網）。有三個已知的庫可以實現Gossip演算法來發現對等網路中的節點：

**teknek-gossip** - 它與UDP一起工作，並用Java編寫。
**gossip-python** - 它利用TCP堆疊，也可以透過構建的網路共享資料。
**Smudge** - 它用Go編寫，並使用UDP交換狀態資訊。

Gossip協議也用於實現和維護分散式資料庫一致性或其他型別的一致狀態資料，計算未知大小網路中的節點數量，穩健地傳播新聞，組織節點等。

遠端過程呼叫

RPC可以表示為遠端過程呼叫的縮寫。它是一種程式用來請求另一程式服務的協議。此協議可以位於網路上的另一臺計算機上，而無需確認網路細節。

在Consul中使用RPC的真正好處是，它幫助我們避免了大多數發現服務工具在一段時間前所遇到的延遲問題。在RPC之前，Consul僅使用基於**TCP**和**UDP**的連線，這對於大多數系統來說都很好，但在分散式系統的情況下則不然。RPC透過減少從一個地方到另一個地方的資料包資訊傳輸時間來解決此類問題。在這個領域，谷歌的GRPC是一個很好的工具，如果希望觀察基準並比較效能，可以參考它。

列印頁面