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官方文件整理而來，加入了波斯碼個人的一些理解。點此檢視原文。