Consul 服務註冊與發現一站式解決方案

 

consul簡介

 

• Consul 是一個支持多數據中心分佈式高可用的服務發現和配置共享的服務軟件,由 HashiCorp 公司用 Go 語言開發, 基於 Mozilla Public License 2.0 的協議進行開源. Consul 支持健康檢查,並容許 HTTP 和 DNS 協議調用 API 存儲鍵值對.
• 一致性協議採用 Raft 算法,用來保證服務的高可用. 使用 GOSSIP 協議管理成員和廣播消息, 而且支持 ACL 訪問控制.
• Consul 的方案更 "一站式"，內置了服務註冊與發現框架、分佈一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，再也不須要依賴其餘工具（好比 ZooKeeper 等）。使用起來也較爲簡單。Consul 用 Golang 實現，所以具備自然可移植性（支持 Linux、windows 和 Mac OS X）；安裝包僅包含一個可執行文件，方便部署，與 Docker 等輕量級容器可無縫配合

 

使用場景

 

• docker 實例的註冊與配置共享
• coreos 實例的註冊與配置共享
• vitess 集羣
• SaaS 應用的配置共享
• 與 confd 服務集成，動態生成 nginx 和 haproxy 配置文件

產品對比

 

同類工具備如下這些

etcd Distributed reliable key-value store for the most critical data of a distributed system

zookeeper Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.

 

相同點

• 架構相似，都有服務節點，而這些服務節點的操做都要求達到節點的仲裁數（一般，節點的仲裁數遵循的是簡單多數原則
• 強一致性，用於構建複雜的分佈式系統

不一樣點

• zooKeeper, etcd只提供一個原始的K/V值存儲，並要求開發人員構建他們本身的系統來提供服務發現功能，cosnul提供服務發現功能
• consul基於gossip的健康檢查機制脫穎而出。ZooKeeper健康檢查機制須要胖客戶端，增長了工做量。etcd無健康檢查功能
• consul使用Raft算法來保證一致性, 比複雜的Paxos算法更直接. 相比較而言, zookeeper採用的是 Paxos, 而 etcd 使用的則是 Raft.
• 支持多數據中心，內外網的服務採用不一樣的端口進行監聽。多數據中心集羣能夠避免單數據中心的單點故障, 而其部署則須要考慮網絡延遲, 分片等狀況等. zookeeper和etcd 均不提供多數據中心功能的支持.
• 支持 http 和 dns 協議接口. zookeeper的集成較爲複雜, etcd 只支持 http 協議.
• 官方提供web管理界面, etcd 無此功能

 

架構

 

術語解釋

Consul集羣間使用了GOSSIP協議通訊和raft一致性算法。

• Agent——agent是一直運行在Consul集羣中每一個成員上的守護進程。經過運行consul agent來啓動。agent能夠運行在client或者server模式。指定節點做爲client或者server是很是簡單的，除非有其餘agent實例。全部的agent都能運行DNS或者HTTP接口，並負責運行時檢查和保持服務同步。
• Client——一個Client是一個轉發全部RPC到server的代理。這個client是相對無狀態的。client惟一執行的後臺活動是加入LAN gossip池。這有一個最低的資源開銷而且僅消耗少許的網絡帶寬。
• Server——一個server是一個有一組擴展功能的代理，這些功能包括參與Raft選舉，維護集羣狀態，響應RPC查詢，與其餘數據中心交互WAN gossip和轉發查詢給leader或者遠程數據中心。
• DataCenter——咱們定義數據中心爲一個私有的，低延遲和高帶寬的一個網絡環境。
• Consensus——一致性，使用Consensus來代表就leader選舉和事務的順序達成一致。爲了以容錯方式達成一致，通常有超過半數一致則能夠認爲總體一致。Consul使用Raft實現一致性，進行leader選舉，在consul中的使用bootstrap時，能夠進行自選，其餘server加入進來後bootstrap就能夠取消。
• Gossip——Consul創建在Serf的基礎之上，它提供了一個用於多播目的的完整的gossip協議。Serf提供成員關係，故障檢測和事件廣播。Serf是去中心化的服務發現和編制的解決方案，節點失敗偵測與發現，具備容錯、輕量、高可用的特色。
• LAN Gossip——

Consul中的每一個數據中心有一個LAN池，它包含了這個數據中心的全部成員，包括clients和servers。LAN池用於如下幾個目的:

成員關係信息容許client自動發現server, 減小了所須要的配置量。

分佈式失敗檢測機制使得由整個集羣來作失敗檢測這件事， 而不是集中到幾臺機器上。

gossip池使得相似領導人選舉這樣的事件變得可靠並且迅速。

• WAN Gossip——

WAN池是全局惟一的，由於全部的server都應該加入到WAN池中，不管它位於哪一個數據中心。由WAN池提供的成員關係信息容許server作一些跨數據中心的請求。一體化的失敗檢測機制容許Consul優雅地去處理：整個數據中心失去鏈接， 或者僅僅是別的數據中心的某一臺失去了鏈接。

• RPC——遠程過程調用。這是一個容許client請求server的請求/響應機制。

 

架構分解

• 首先，咱們能夠看到有兩個數據中心，標籤爲"Datacenter 1"和"Datacenter 2"。consul對多數據中心提供最高等級的支持並預期這將成爲廣泛狀況。
• 在每一個數據中心內，混合有客戶端和服務器。預期由3到5個服務器。強調在失敗狀況下的可達到和性能之間的平衡，由於添加更多機器會致使一致性變得日益緩慢。不過，對於客戶端的數量沒有限制，並且能夠很容易的擴展到成千上萬。
• 在一個數據中心內的全部節點加入一個gossip 協議。這意味着對於一個給定的數據中心，有一個包含全部節點的gossip池。這服務於幾個目的：
• 首先，不須要用服務器地址來配置客戶端；發現是自動完成的。
• 其次，檢測節點失敗的工做不是放置在服務器上，而是分佈式的。這使得失敗檢測比心跳機制更加可擴展。
• 另外，當重要事件好比leader選舉發生時它被用來做爲消息層(messaging layer)來通知。

1. 每一個數據中心中的服務器是單個Raft 端集合(peer set)的全部組成部分。這意味着他們一塊兒工做來選舉leader，一個有額外職責的被選定的服務器。leader負責處理全部請求和事務。事務也必須複製到全部做爲一致協議一部分的端(peer)。由於這個要求，當一個非leader服務器收到RPC請求時，它轉發請求到集羣leader。

• 服務器節點也做爲廣域網 gossip 協議池的一部分運做。這個池和局域網池有所不一樣，由於它爲因特網的高延遲作了優化並預期只包含其餘consul服務器(注：特指在其餘數據中心中的consul服務器，見圖中的"Datacenter 2")節點。這個池的目的是允許數據中心們以低接觸(low-touch)風格相互發現。上線一個新的數據中心和加入現有的廣域網gossip同樣容易。由於服務器都在全體經營這個池，池能夠開啓跨數據中心請求。當服務器收到一個給不一樣數據中心的請求時，它轉發請求到正確的數據中心中的任意服務器。這個服務器可能隨即轉發給本地leader。
• 這使得數據中心之間的耦合的很是低。而由於失敗檢測，鏈接緩存和多路通信，跨數據中心請求相對比較快而可靠。

 

Gossip協議

 

• Gossip算法如其名，靈感來自辦公室八卦，只要一我的八卦一下，在有限的時間內全部的人都會知道該八卦的信息，這種方式也與病毒傳播相似，所以Gossip有衆多的別名「閒話算法」、「疫情傳播算法」、「病毒感染算法」、「謠言傳播算法」。
• 但Gossip並非一個新東西，以前的泛洪查找、路由算法都歸屬於這個範疇，不一樣的是Gossip給這類算法提供了明確的語義、具體實施方法及收斂性證實。
• http://blog.csdn.net/u012422829/article/details/77828870

Anti-Entropy(反熵)

• Consule 使用一個高級的方式來維護 service 和 health 信息的方法。Anti-Entropy（反熵 ） 機制被用來保證在不一樣節點上的備份（replica）都持有最新版本
• Agent
• 　　每一個Consul agent維護它本身的服務集合以及檢查註冊和健康信息。agent負責執行本身的健康檢查和更新本地狀態。
• Catalog
• 　　Consul的服務發現基於一個服務目錄。這個目錄是經過聚合agents提交的信息造成的。目錄維護了集羣的高級視圖，它包括哪些服務可用，哪些節點容許這些服務，健康信息等等。目錄是用來展現這些信息的，能夠經過各類Consul提供的接口，包含DNS和HTTP。
• 　　與agent相比，目錄上下文中的服務和檢查的字段更爲有限。這是由於目錄只服務於記錄和返回關於服務，節點和健康的信息。
• 　　只有server節點維護目錄。這是由於目錄是經過Raft日誌複製來提供一個統一的集羣視圖。
• http://blog.mallux.me/2017/03/19/consul/
• http://www.voidcn.com/article/p-oqtnkvov-ye.html

一致性Raft

• Consul使用Raft算法實現分佈式存儲的一致性。Raft節點在集羣中有follower,candidate或leader三種狀態，初始爲follower，在這個狀態下節點能夠接收來自leader的日誌單元和投票選leader。若是一段時間內收不到來自leader的心跳，則升級爲candidate向集羣全部node發送投票邀請，若是candidate收到過半節點的投票則升級爲leader，leader負責接收日誌單元並複製給全部follower
• 集羣當選出leader後才能接收新的日誌單元，節點收到日誌時把日誌轉發給leader，leader將日誌保存到本地存儲複製給全部follower，當超過半數的follower成功複製後日志單元狀態變爲‘committed’，進而交給狀態機去執行。而後leader會將日誌單元的committ狀態發送給全部follower讓他們來更新到各自狀態機。
• Consul自動的經過快照機制將Raft日誌壓縮來避免其無限增加
• 在consul集羣裏，只有server結點經過Raft算法進行數據一致性管理，緣由是Raft集羣的結點數量不能太多(在3-5)，若是client也參與到Raft那麼隨着集羣結點數量增長，在Raft算法下集羣效率會降低，client結點只是將數據請求轉發給server

 

Raft啓動方式

• Raft集羣的啓動方式有兩種，其中一種直接的辦法是用個配置文件記錄全部server的列表，每一個server啓動後用這個靜態的列表做爲Raft的server，但這須要全部server維護一個靜態的配置文件
• ‘-bootstrap’參數，若是集羣先啓動一個server而且他優先成爲leader(Consul在這裏作了特殊設置，讓這個bootstrap server從log中恢復成leader狀態)，以後加入的全部server一直是follower狀態。但這還有個問題，就是仍是得固定一臺server成爲第一個leader，啓動參數必須與其餘server不一樣(必須帶有-bootstrap）
• ‘-bootstrap-expect’參數，全部server都用同一參數’-boostrap-expect N’說明集羣的server個數爲N，在有N個server join進來後，cluster開始啓動raft邏輯選主。注意，N必定要與server總數相同，不然會出現split-brain(雙主)問題，好比N=3 兒集羣server總數爲7，就極可能出現兩個leader的狀況。

讀操做一致性

• 對於讀操做，consul支持多種一致性模式：
• ‘default’, 這種模式下若是leader由於與成員分離致使新的leader被選出的狀況下，雖然舊的leader不能再提交日誌，但還能夠負責進行讀取操做，這回致使部分讀取的數據是過時的。但這種狀態不會維持多長時間，由於舊的leader的狀態很快就會降級爲follower
• ‘consistent’，這種模式下要求leader給follower發消息確認仍然是leader，這就形成了讀取操做時多了一步操做增長了延遲
• ‘stale’，這個模式下每一個server均可以負責讀取，這就致使讀出來的數據由於還未在leader把數據複製到所有follower時被讀出兒形成不一致，但這種狀況也是少數，而且效率會很是快，而且即使沒有leader的狀況下還可以提供讀操做

 

健康檢查

• Agent的一個重要任務是作系統級和程序級的健康檢測，檢測經過配置文件或HTTP接口來定義並被保存到Agent所運行的節點
• 定時腳本檢查(script+Interval), 調用一個第三方的程序進行健康檢測，使用退出碼或標準輸出來代表檢測結果(相似Nagios), 輸出內容不能超過4K，默認的檢查超時時間是30秒，能夠經過配置文件裏的」timeout」來定義。Agent使用enable_script_checks參數來打開這種檢查
• 腳本退出碼與檢測結果對應關係：
• 0, passing
• 1, warning
• other, failing
• 腳本的任何輸出內容會被保存到消息的‘Output’字段， Agent啓動後
• 定時HTTP檢查(HTTP+Interval), 定時經過HTTP GET調用指定的URL，根絕HTTP返回碼判斷服務狀態。‘2xx’表示經過檢查，‘429’表示警告，其他均表示故障。默認狀況下http請求的timeout與檢查的interval相同，最長爲10秒。能夠經過‘timeout’來在配置文件裏設置。檢查返回的內容大小不能超過4K，超過部分會被截斷。默認狀況下支持SSL，能夠經過tls_skip_verify來關掉。
• 定時TCP檢查(TCP+Interval), 定時經過TCP鏈接檢查指定host/IP和端口，根據是否可以創建鏈接成功與否斷定service狀態，成功鏈接表示service正常，不然表示事態危急. 默認超時時間10秒。
• TTL檢查，經過服務主動的定時更新TTL，超過期間的定位service故障。
• 定時Docker檢查，經過調用常駐docker裏的一個檢查程序來進行，這個程序經過調用Docker Exec API來啓動，須要consul agent具備調用Docker HTTP API或Unix Socket的權限。consul用 DOCKER_HOST 來定位Docker API端點，檢查程序運行完後要返回適當的退出碼和輸出，輸出內容不能超過4K。Agent須要經過enable_script_check來打開這種檢查
• 默認會將check的狀態設置爲‘critical’，這是防止服務在沒有被檢查前就被加入到調用這個服務的系統裏

 

 

狀態監視

• 使用Whach能夠監視KV、nodes、service、checks等對象的變化，當有更新時會觸發watch定義的可執行的handler。
• Watch經過阻塞的HTTP API實現，Agent會根據調用相應api請求自動監視指定內容，當有變化時通知handler
• Watch還能夠加入到Agent的配置文件中的watches生成
• watch還能夠經過‘consule watch’命令來直接運行並把結果輸出處處理程序
• 當watch監控到數據的更新，能夠調用一個handler還作後續處理，watch會將監控的結果以JSON格式發送給handler的標準輸入(stdin), watch不一樣的對象結果的格式會不一樣
• watch的類型：
• Key
• keprefix
• services
• nodes
• service
• checks
• event

 

Session會話

• Consul 提供了一個可用於 構建分佈式鎖 的會話（session）機制。 Session 充當節點、運行情況檢查和鍵/值數據之間的綁定層。 它們旨在提供細粒度的鎖定，並受到鬆散耦合的分佈式系統的分佈式鎖服務（The Chubby Lock Service for Loosely-Coupled Distributed Systems）的大量啓發。
• Consul 中的 session 表示具備很是特定語義的 contract 。 當構建會話時，能夠提供節點名稱、健康檢查列表、行爲、TTL 和 鎖定延遲。 新構造的 session 具備可用於識別它的命名 ID。 此 ID 可與 KV 存儲一塊兒使用以獲取鎖：用於互斥的諮詢機制。
• Consule 提供的 contract ，在下列任何狀況下，會話將失效：
• 節點已取消註冊
• 任何健康檢查都被取消註冊
• 任何健康檢查都進入臨界狀態
• 會話被明確銷燬
• TTL 到期（若是適用）
• 當 session 無效時，會被銷燬，不能再使用。 相關鎖的操做取決於在建立時指定的行爲。 Consul 支持 release 和 delete 行爲。 若是未指定任何內容，則 release 行爲是缺省值。

 

---

---

 

 

命令

kv - Key/Value存儲

agent - Agent控制

catalog - 管理nodes和services

health - 管理健康監測

session - Session操做

acl - ACL建立和管理

event - 用戶Events

status - Consul系統狀態

 

Agent API

/v1/agent/checks : 返回本地agent註冊的全部檢查(包括配置文件和HTTP接口)

/v1/agent/services : 返回本地agent註冊的全部 服務

/v1/agent/members : 返回agent在集羣的gossip pool中看到的成員

/v1/agent/self : 返回本地agent的配置和成員信息

/v1/agent/join/<address> : 觸發本地agent加入node

/v1/agent/force-leave/<node>>: 強制刪除node

/v1/agent/check/register : 在本地agent增長一個檢查項，使用PUT方法傳輸一個json格式的數據

/v1/agent/check/deregister/<checkID> : 註銷一個本地agent的檢查項

/v1/agent/check/pass/<checkID> : 設置一個本地檢查項的狀態爲passing

/v1/agent/check/warn/<checkID> : 設置一個本地檢查項的狀態爲warning

/v1/agent/check/fail/<checkID> : 設置一個本地檢查項的狀態爲critical

/v1/agent/service/register : 在本地agent增長一個新的服務項，使用PUT方法傳輸一個json格式的數據

/v1/agent/service/deregister/<serviceID> : 註銷一個本地agent的服務項

 

Catalog API

/v1/catalog/register : Registers a new node, service, or check

/v1/catalog/deregister : Deregisters a node, service, or check

/v1/catalog/datacenters : Lists known datacenters

/v1/catalog/nodes : Lists nodes in a given DC

/v1/catalog/services : Lists services in a given DC

/v1/catalog/service/<service> : Lists the nodes in a given service

/v1/catalog/node/<node> : Lists the services provided by a node

 

Health API

/v1/healt/node/<node>: 返回node所定義的檢查，可用參數?dc=

/v1/health/checks/<service>: 返回和服務相關聯的檢查，可用參數?dc=

/v1/health/service/<service>: 返回給定datacenter中給定node中service

/v1/health/state/<state>: 返回給定datacenter中指定狀態的服務，state能夠是"any", "unknown", "passing", "warning", or "critical"，可用參數?dc=

Session API

/v1/session/create: Creates a new session

/v1/session/destroy/<session>: Destroys a given session

/v1/session/info/<session>: Queries a given session

/v1/session/node/<node>: Lists sessions belonging to a node

/v1/session/list: Lists all the active sessions

ACL API

/v1/acl/create: Creates a new token with policy

/v1/acl/update: Update the policy of a token

/v1/acl/destroy/<id>: Destroys a given token

/v1/acl/info/<id>: Queries the policy of a given token

/v1/acl/clone/<id>: Creates a new token by cloning an existing token

/v1/acl/list: Lists all the active tokens

Event API

/v1/event/fire/<name>: 觸發一個新的event，用戶event須要name和其餘可選的參數，使用PUT方法

/v1/event/list: 返回agent知道的events

Status API

/v1/status/leader : 返回當前集羣的Raft leader

/v1/status/peers : 返回當前集羣中參與投票的節點

自定義事件

Event:

consul event -name=test -http-addr=localhost:8500

consul watch -type=event -name=test "echo 'see it'」

Key:

curl -XPUT 'http://localhost:8500/v1/kv/web/k1' -d '{"name":"mm"}’

consul watch -type=key –key=web/k1 "echo 'see it'」

更多內容見:

http://blog.csdn.net/younger_china/article/details/52243799

 

 

---

 

Why client per node

SRV 中的target實際指向了註冊節點的域名,因此說明 consul 的 DNS 規則是無論你service 註冊的時候不管你怎麼提交本身的 IP, 在 DNS 上,永遠以註冊的Consul節點的 IP 做爲 Service 的實際 IP,都是 SRV 規則致使的,

因此總結一下,在本地部署 consul Client 的緣由是標識 Service 的實際 IP, 這確實也是逼不得已的方式,若是使用 HTTPDNS 的話,效率不但低,並且算是一個私有協議,不利於和基礎環境的融合.