Consul 架構（譯）

Consul 架構

此篇文章主要對consul的相關內部技術細節進行簡要概述。

»術語

• 代理 - 代理是指consul集羣中運行的consul實例，經過執行 consul agent 命令來啓動. 代理能夠運行於客戶端或者服務端。經過執行DNS或者HTTP接口來執行健康檢查和服務同步。

• 客戶節點 - 客戶節點負責將向服務節點發送RPC請求，相對來講是無狀態的.。客戶節點惟一要執行的後臺活動是參與LAN gossip pool。固然這隻會消耗不多的資源和網絡帶寬。

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

• 數據中心 – …

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

• Gossip - Consul是創建在Serf之上的，支持所有的gossip protocol（節點間隨機通訊，主要經過UDP）。Serf 提供關係管理, 失敗檢測及事件分發功能. Consul gossip應用詳情能夠訪問鏈接gossip documentation。

• LAN Gossip - 本地局域網或數據中心節點間Gossip應用.

• WAN Gossip – WAN 範圍（不一樣數據中心，主要經過internet或者wan通訊）內服務器節點間Gossip應用。

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

»基本架構

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

數據中心中包含客戶節點和服務節點，一般建議三到五個服務節點。由於隨着節點的增長，服務同步會變得相對更慢，同時考慮到服務失敗和性能要求等方面因素。可是對於客戶節點數量，則沒有限制。

數據中心中的全部節點都會參數gossip protocol. 也就是說包括數據中心中全部的節點。這樣作有幾個目的，首先, 無需給客戶節點配置服務節點地址，就能夠自動發現。其次，失效節點檢測是分佈式的，相對於心跳檢測模式更具伸縮性。最後，事件分發是以消息模式分發處理的。

節點之間利用Raft協議選舉領導者，領導者負責處理全部的查詢和事務請求。同時根據Gossip協議，事務請求須要分發到全部的協議節點。全部當一個非領導者服務節點收到一個Rpc請求時，它會將其轉發至集羣領導者進行後續處理。

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

由此，大大的下降了數據中心的耦合度。可是，由於有相應的失敗檢測，鏈接緩存和複用，數據中心之間的交互也相對快捷可靠。

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

 

一致性模型：

 

默認（特定的舊leader的時間窗口內，舊leader處理讀請求）：Raft使用leader leasing，提供一個時間窗口，這個時間內，leader假定他的leader角色是穩定的。然而，若是這個leader和餘下的節點分隔開。在舊leader持有時間窗口的同時，集羣就會選出一個新的leader。這就意味着，集羣有兩個leader節點。發生裂鬧現象並無風險，由於舊leader不能提交新的條目。然而，對於只讀請求，舊leader很大可能性上會返回過時數據。默認的一致性模型依賴於leader leasing，客戶端有可能會獲取到過時的數據的風險。咱們之因此作這種妥協是由於，只讀請求一般很快，而且是強一致性的。只會在hard-to-trigger狀況下會返回過時數據。會返回過時數據的時間窗口長度也是有限的，由於舊的leader會由於分裂的發生降級。

 

一致性（consistent）：強一致性模型，這個模型須要leader處理讀請求錢，經過詢問quorum檢查本身的leader合法性，所以增長了一輪RPCs，好處是，讀請求的一致性，可是卻增長了延遲。

 

過時（stale）：這種模型，容許全部的節點處理客戶端的讀請求。不管是不是leader節點。這就意味着讀取過時數據更加廣泛，可是也僅僅是在leader的最小超時時間50ms內。好處是，處理只讀請求塊，適用於大規模請求，可是伴隨着廣泛的過時數據。模型在沒有leader的狀況下依然能夠處理來此客戶端的讀請求。

 

Consul Agent：

 

consul agent是consul的核心，負責維護成員關係信息，註冊服務，運行健康檢查，提供查詢等。每一個集羣的節點都須要部署consul agent。

兩種模式：client，server。相較於client，serer模式agent，參與Raft一致性算法。負責提供，保持集羣的強一致性及可用性。server agent和數據及系統資源有更多的交互，所以須要運行在專用的節點上。client agent則比較輕量，大多數操做只須要請求server agent去完成，只須要維護相對不多的狀態。

 

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'  //節點惟一ID

         Node name: 'server0'  //節點名稱，默認爲機器的主機名，能夠經過 -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 當即中止實例，集羣經過失敗檢測發現

 

生命週期：

節點啓動

=》join命令，或者經過配置，加入集羣

=》成員變動信息經過gossip協議傳播到集羣其它成員，最終全部其它成員都將獲悉節點的加入

=》若是是server 節點，則其它服務幾點將進行日誌複製

=》若是發生網絡問題，節點信息沒法獲悉（不管是由於網絡問題沒法通信仍是節點宕機）。則失聯節點標記爲失效，其它節點更新集羣成員信息

=》節點離開，則集羣標記節點狀態爲「已離開」，區別於節點失敗（全部節點上註冊的服務會當即被註銷），若是是server節點，則複製過程中止

=》爲了防止死節點信息的堆積，consul會自動將這些信息從成員信息列表中移除，稱之爲收割。目前配置的時間隔72小時執行一次，當此時，相似於節點失敗，移除的節點信息上註冊的服務會被註銷。