Consul 基礎入門

Consul 架構 此篇文章主要對consul的相關內部技術細節(jié)進行簡要概述。

?術語 代理 - 代理是指consul集群中運行的consul實例，通過執(zhí)行 consul agent 命令來啟動. 代理可以運行于客戶端或者服務端。通過執(zhí)行DNS或者HTTP接口來執(zhí)行健康檢查和服務同步。

客戶節(jié)點 - 客戶節(jié)點負責將向服務節(jié)點發(fā)送RPC請求，相對來說是無狀態(tài)的.。客戶節(jié)點唯一要執(zhí)行的后臺活動是參與LAN gossip pool。當然這只會消耗很少的資源和網絡帶寬。

服務節(jié)點 - 服務節(jié)點主要職責包括參與Raft算法，維護集群狀態(tài)，處理RPC查詢，和其它的數據中心交換WLAN gossip及向領導者或者遠程數據中心轉發(fā)查詢請求。

數據中心 – …

維護一致性- 包括領導者選舉及事務執(zhí)行順序方面的一致性。

Gossip - Consul是建立在Serf之上的，支持全部的gossip protocol（節(jié)點間隨機通信，主要通過UDP）。Serf 提供關系管理, 失敗檢測及事件分發(fā)功能. Consul gossip應用詳情可以訪問連接gossip documentation。

LAN Gossip - 本地局域網或數據中心節(jié)點間Gossip應用.

WAN Gossip – WAN 范圍（不同數據中心，主要通過internet或者wan通信）內服務器節(jié)點間Gossip應用。

RPC - 遠程過程調用，請求/回復機制。

?基本架構 consul-arch-420ce04a

如上圖所示，Consul先天支持多數據中心應用：multiple datacenters 。

數據中心中包含客戶節(jié)點和服務節(jié)點，通常建議三到五個服務節(jié)點。因為隨著節(jié)點的增加，服務同步會變得相對更慢，同時考慮到服務失敗和性能要求等方面因素。但是對于客戶節(jié)點數量，則沒有限制。

數據中心中的所有節(jié)點都會參數gossip protocol. 也就是說包括數據中心中所有的節(jié)點。這樣做有幾個目的，首先, 無需給客戶節(jié)點配置服務節(jié)點地址，就可以自動發(fā)現。其次，失效節(jié)點檢測是分布式的，相對于心跳檢測模式更具伸縮性。最后，事件分發(fā)是以消息模式分發(fā)處理的。

節(jié)點之間利用Raft協(xié)議選舉領導者，領導者負責處理所有的查詢和事務請求。同時根據Gossip協(xié)議，事務請求需要分發(fā)到所有的協(xié)議節(jié)點。所有當一個非領導者服務節(jié)點收到一個Rpc請求時，它會將其轉發(fā)至集群領導者進行后續(xù)處理。

服務節(jié)點同時也是WAN gossip pool的一部分。相對于LAN pool，WAN pool是專門為高延遲因特網而優(yōu)化使用的，它只包含服務節(jié)點，提供數據中心之間低接觸式發(fā)現機制。它支持跨數據中心請求，當一個數據中心接到請求其它數據中心數據的請求時，它會將其轉發(fā)至目標數據中心中隨機的一個服務節(jié)點。

由此，大大的降低了數據中心的耦合度。但是，因為有相應的失敗檢測，連接緩存和復用，數據中心之間的交互也相對快捷可靠。

通常來說，數據中心之間是不進行數據交換的，當一個數據中心接收到一個請求其它數據中心資源的請求時，它會將其進行轉發(fā)，由相應的數據中心進行處理。當目標數據中心不可用，也就意味著所請求的資源不可用。但也有一些特俗情況，會造成數據的分發(fā)，如，consul的內置ACL replication功能，及其它相關的外部工具。

一致性模型：

默認（特定的舊leader的時間窗口內，舊leader處理讀請求）：Raft使用leader leasing，提供一個時間窗口，這個時間內，leader假定他的leader角色是穩(wěn)定的。然而，如果這個leader和余下的節(jié)點分隔開。在舊leader持有時間窗口的同時，集群就會選出一個新的leader。這就意味著，集群有兩個leader節(jié)點。發(fā)生裂鬧現象并沒有風險，因為舊leader不能提交新的條目。然而，對于只讀請求，舊leader很大可能性上會返回過期數據。默認的一致性模型依賴于leader leasing，客戶端有可能會獲取到過期的數據的風險。我們之所以做這種妥協(xié)是因為，只讀請求通常很快，并且是強一致性的。只會在hard-to-trigger情況下會返回過期數據。會返回過期數據的時間窗口長度也是有限的，因為舊的leader會因為分裂的發(fā)生降級。

一致性（consistent）：強一致性模型，這個模型需要leader處理讀請求錢，通過詢問quorum檢查自己的leader合法性，因此增加了一輪RPCs，好處是，讀請求的一致性，但是卻增加了延遲。

過期（stale）：這種模型，允許所有的節(jié)點處理客戶端的讀請求。無論是否是leader節(jié)點。這就意味著讀取過期數據更加普遍，但是也僅僅是在leader的最小超時時間50ms內。好處是，處理只讀請求塊，適用于大規(guī)模請求，但是伴隨著普遍的過期數據。模型在沒有l(wèi)eader的情況下依然可以處理來此客戶端的讀請求。

Consul Agent：

consul agent是consul的核心，負責維護成員關系信息，注冊服務，運行健康檢查，提供查詢等。每個集群的節(jié)點都需要部署consul agent。 兩種模式：client，server。相較于client，serer模式agent，參與Raft一致性算法。負責提供，保持集群的強一致性及可用性。server agent和數據及系統(tǒng)資源有更多的交互，因此需要運行在專用的節(jié)點上。client agent則比較輕量，大多數操作只需要請求server agent去完成，只需要維護相對很少的狀態(tài)。

D:\consul>consul agent -server -bootstrap-expect=1 -data-dir=data -node=server0 -bind=127.0.0.1 -client 0.0.0.0 -ui BootstrapExpect is set to 1; this is the same as Bootstrap mode. bootstrap = true: do not enable unless necessary ==> Starting Consul agent... ==> Consul agent running! Version: 'v1.0.2' Node ID: '1ad0d5d0-80df-29ed-e795-ce50bfd70f2f' //節(jié)點唯一ID Node name: 'server0' //節(jié)點名稱，默認為機器的主機名，可以通過 -node 進行設置 Datacenter: 'dc1' (Segment: '<all>') //所在數據中心，單數據中心默認為dc1，可以通過 -datacenter 設置。 Server: true (Bootstrap: true) //運行模式， Client Addr: [0.0.0.0] (HTTP: 8500, HTTPS: -1, DNS: 8600) // 客戶端地址，服務于HTTP DNS接口，默認綁定localhost Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302) // 和集群內成員通信的地址和端口，LAN WAN Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false

==> Log data will now stream in as it occurs:

停止： gracefully：ctrl-c 和 kill -INT。agent告知集群自己將要離開集群。建議 forcefully：kill -9 立即停止實例，集群通過失敗檢測發(fā)現

生命周期： 節(jié)點啟動 =》join命令，或者通過配置，加入集群 =》成員變更信息通過gossip協(xié)議傳播到集群其它成員，最終所有其它成員都將獲悉節(jié)點的加入 =》如果是server 節(jié)點，則其它服務幾點將進行日志復制 =》如果發(fā)生網絡問題，節(jié)點信息無法獲悉（無論是因為網絡問題無法通訊還是節(jié)點宕機）。則失聯節(jié)點標記為失效，其它節(jié)點更新集群成員信息 =》節(jié)點離開，則集群標記節(jié)點狀態(tài)為“已離開”，區(qū)別于節(jié)點失敗（所有節(jié)點上注冊的服務會立即被注銷），如果是server節(jié)點，則復制過程停止 =》為了防止死節(jié)點信息的堆積，consul會自動將這些信息從成員信息列表中移除，稱之為收割。目前配置的時間隔72小時執(zhí)行一次，當此時，類似于節(jié)點失敗，移除的節(jié)點信息上注冊的服務會被注銷。