Consul的反熵

熵

熵是衡量某個體系中事物混亂程度的一個指標，是從熱力學第二定律借鑑過來的。

熵增原理

孤立系統的熵永不自動減小，熵在可逆過程當中不變，在不可逆過程當中增長。
熵增長原理是熱力學第二定律的又一種表述，它更爲歸納地指出了不可逆過程的進行方向；同時，更深入地指出了熱力學第二定律是大量分子無規則運動所具備的統計規律，所以只適用於大量分子構成的系統，不適用於單個分子或少許分子構成的系統。

[來自百度百科]

Consul爲何要反熵

舉個現實社會的例子，國家是由一個個的人組成的，小國家幾萬人口，大國家幾億人口，每一個人都有本身的想法，不可能這些人沒有組織就能維持這個國家的運轉。我國有省市縣鄉四級行政區劃，鄉管理幾十個村，縣管理十幾個鄉，市管理十幾個縣，省管理十幾個市。若是讓省直接去管理以萬爲單位的村，李村的村長貪污了補貼款，張村的馬路被壓壞了，隔壁王村放開二胎後仍是沒人生孩子…，確定是管不過來的。經過這種層級的行政劃分，國家獲得了有序的治理，而不是亂哄哄一片。

Consul面對的問題也是相似的，它是一個分佈式的服務發現系統，須要作服務註冊、健康檢查、服務發現，以及在成員之間共享這些服務信息。大點的系統可能有成千上萬的服務，分佈在成百上千的節點，服務應該註冊在哪些節點，數據在節點之間怎麼同步，節點失敗了怎麼辦，怎樣保證增長節點數量不會致使性能明顯降低…若是不解決好這些問題，整個系統可能就會變得混亂，走向失控和崩潰。

理解兩個組件

這裏首先介紹跟服務和健康檢查緊密相關的兩個部件：Agent和Catalog，可讓你們更容易理解Consul的反熵。

Agent

Agent存在於Consul的每個節點中，負責維護註冊到其上的服務和健康檢查，以及執行這些健康檢查，更新本地服務的健康信息。

Catalog

Catalog存在於Server 節點，聚合了各個Agent採集的信息，包括服務、健康檢查、相關的節點，以及它們對應的狀態，服務發現就是基於Catalog來作的。

然而Catalog中這些信息的字段要比Agent維護的少不少，由於Catelog只是一個視圖，它沒有關於服務、健康檢查和節點的設置項信息。

反熵機制

根據前邊對熵的說明，Consul 的反熵就是讓Consul集羣更有序，而其反熵機制就和上邊提到的兩個部件緊密相關。

當服務或健康檢查在Agent註冊後，信息就會通知到Catalog中；當Agent中根據健康檢查的服務狀態發生變化時，狀態也會通知到Catalog中；當服務或健康檢查從Agent中消失後，Catalog中也會移除相對應的信息。

Agent負責註冊到其上的服務及健康檢查，Catalog負責聚合集羣各個Agent的數據用於服務發現，Agent同步最新數據到Catalog，各個Agent的數據不斷收斂到Catalog，從而實現集羣的有序運做。波斯碼建議你們經過調用Consul API中的Agent和Catalog接口來驗證這個機制。

週期同步

除了當變化發生時Agent主動通知外，Agent還有一個定時器執行到Catalog的完整同步操做。極端狀況下，若是在Catalog中移除了某個Agent的全部信息，過一會這些信息也會從新同步到Catalog中。爲了下降同步可能致使的併發影響，針對不一樣的集羣規模默認了不一樣的同步週期：

集羣規模	同步週期
1 – 128	1 minute
129 – 256	2 minutes
257 – 512	3 minutes
513 – 1024	4 minutes
…	…

這個同步間隔只是一個近似值，爲了防止大量節點同時同步致使驚羣效應，實際程序中會在同步週期內引入一個隨機值來錯開同時請求。

同步的異常處理

同步的時候可能會出現各類問題，好比Agent配置錯誤、磁盤滿了、沒有寫入權限、網絡不通等等，出現這些問題時，Agent會記錄日誌後繼續運行，而後等待下一次週期同步嘗試。

啓用Tag Override

若是開啓這個選項，則Agent同步數據到Catalog時，將不會同步服務的tag數據。舉個實際的例子：主從部署的redis，使用sentinel監控實例的狀態，若是主redis下線，則某個從redis升級爲可寫的主實例。假設使用服務的tag做爲主從的標識，這裏就不能使用服務註冊時的tag，而應該經過sentinel獲取redis實例的主從狀態，而後設置到Catalog中，服務發現才能獲取到當前實際的redis主實例。

這篇文章由Consul官方文檔整理而來，加入了波斯碼我的的一些理解。點此查看原文。

另外歡迎加入800人Consul交流羣：234939415，交流使用Consul的各類姿式。