【Consul】CONSUL調研

【Consul】CONSUL調研

2016年08月18日 18:31:53 YoungerChina 閱讀數：1962更多

所屬專欄： Consul修煉

 

版權聲明：原創不易，轉載請註明出處！ https://blog.csdn.net/iamonlyme/article/details/52243700

 

1   什麼是consul？

Consul是一個服務管理軟件:

1.    支持多數據中心下，分佈式高可用的，服務發現和配置共享。

2.    consul支持健康檢查，容許存儲鍵值對。

3.    一致性協議採用 Raft 算法,用來保證服務的高可用。

4.    成員管理和消息廣播 採用GOSSIP協議，支持ACL訪問控制。

 

ACL技術在路由器中被普遍採用，它是一種基於包過濾的流控制技術。控制列表經過把源地址、目的地址及端口號做爲數據包檢查的基本元素，並能夠規定符合條件的數據包是否容許經過。

gossip就是p2p協議。他主要要作的事情是，去中心化。 這個協議就是模擬人類中傳播謠言的行爲而來。首先要傳播謠言就要有種子節點。種子節點每秒都會隨機向其餘節點發送本身所擁有的節點列表，以及須要傳播的消息。任何新加入的節點，就在這種傳播方式下很快地被全網所知道。

 

什麼是服務註冊？

一個服務將其位置信息在「中心註冊節點」註冊的過程。該服務通常會將它的主機IP地址以及端口號進行註冊，有時也會有服務訪問的認證信息，使用協議，版本號，以及關於環境的一些細節信息。

什麼是服務發現？

服務發現可讓一個應用或者組件發現其運行環境以及其它應用或組件的信息。用戶配置一個服務發現工具就能夠將實際容器跟運行配置分離開。常見配置信息包括：ip、端口號、名稱等。

當一項服務存在於多個主機節點上時，client端如何決策獲取相應正確的IP和port?

在傳統狀況下，當出現服務存在於多個主機節點上時，都會使用靜態配置的方法來實現服務信息的註冊。

而當在一個複雜的系統裏，須要較強的可擴展性時，服務被頻繁替換時，爲避免服務中斷，動態的服務註冊和發現就很重要。

相關開源項目：Zookeeper，Doozer，Etcd，強一致性的項目，這些項目主要用於服務間的協調，同時又可用於服務的註冊。

什麼是強一致性協議？

按照某一順序串行執行存儲對象讀寫操做，更新存儲對象以後， 後續訪問老是讀到最新值。 假如進程A先更新了存儲對象，存儲系統保證後續A,B,C進程的讀取操做都將返回最新值。強一致性模型有幾種常見實現方法， 主從同步複製， 以及quorum複製等。

 

2  consul的具體應用場景

1. Docker、coreos 實例的註冊與配置共享

2. vitess集羣

3. SaaS應用的配置共享

4.與confd服務集成，動態生成nignx與haproxy配置文件

 

3  優點

1. Raft算法

使用 Raft 算法來保證一致性，比poxes算法更直接。zookeeper採用的時poxes算法。

Raft大概將整個過程分爲三個階段，leader election，log replication和commit(safety)。

每一個server處於三個狀態：leader，follower，candidate。正常狀況下，全部server中只有一個是leader，其它的都是follower。server之間經過RPC消息通訊。follower不會主動發起RPC消息。leader和candidate(選主的時候)會主動發起RPC消息。

首先選擇一個leader全權負責管理日誌複製，leader從客戶端接收log entries，將它們複製給集羣中的其它機器，而後負責告訴其它機器何時將日誌應用於它們的狀態機。舉個例子，leader能夠在無需詢問其它server的狀況下決定把新entries放在哪一個位置，數據永遠是從leader流向其它機器。一個leader能夠fail或者與其餘機器失去鏈接，這種情形下會有新的leader被選舉出來。

http://www.jdon.com/artichect/raft.html

http://blog.csdn.net/cszhouwei/article/details/38374603

 

2. 支持多數據中心

內外網的服務採用不一樣的端口進行監聽。這樣能夠避免單點故障。zookeeper等不支持多數據中心功能的支持

 

3. 支持健康檢查

 

4. 提供web界面

 

5. 支持http協議與dns協議接口

 

4  組建集羣

一個consul agent就是一個獨立的程序。一個長時間運行的守護進程，運行在concul集羣中的每一個節點上。

啓動一個consul agent ，只是啓動一個孤立的node，若是想知道集羣中的其餘節點，應該將consul agent加入到集羣中去 cluster。

agent有兩種模式：server與client。server模式包含了一致性的工做：保證一致性和可用性（在部分失敗的狀況下），響應RPC，同步數據到其餘節點代理。

client 模式用於與server進行通訊，轉發RPC到服務的代理agent，它僅保存自身的少許一些狀態，是很是輕量化的東西。自己是相對無狀態的。

agent除去設置server/client模式、數據路徑以外，還最好設置node的名稱和ip。

一張經典的consul架構圖片：

 

LAN gossip pool包含了同一局域網內全部節點，包括server與client。這基本上是位於同一個數據中心DC。

WAN gossip pool通常僅包含server，將跨越多個DC數據中心，經過互聯網或廣域網進行通訊。

Leader服務器負責全部的RPC請求，查詢並相應。因此其餘服務器收到client的RPC請求時，會轉發到leader服務器。

第一，沒有必要配置客戶端與服務器的地址; 發現是自動完成的。 第二，檢測節點故障的工做不放置在服務器上，但被分佈。 這使得故障檢測比天真的心跳方案更具擴展性。 第三，它是做爲一個消息層通知時，重要事件，如leader選舉舉行。

 

5   參考文獻

[01]http://blog.csdn.net/viewcode/article/details/45915179