目錄

• 客戶端與叢集的互動
• 資料同步
  • 例項資訊同步
  • 服務叢集資訊
• 關於priv-raft協議
• Nacos叢集在k8s中的實踐

這片博文來源於我在公司部門內的分享，我隱去了和公司專案相關的部分，重新整理，從幾個方面談一下Nacos的設計（作為註冊中心，基於此時的develop分支）

客戶端與叢集的互動

首先需要宣告的是Nacos Cluster雖然內部使用了Raft協議但是對於Nacos客戶端，Cluster例項是無狀態的。客戶端配置叢集地址有兩種方式：
1.通過配置serverAddr列表，客戶端將訪問叢集時，隨機從列表中選擇一個例項訪問：

NamingService configService = NacosFactory.createNamingService("10.22.0.137:30253,10.22.0.137:30254,10.22.0.137:30255");

當然，一般情況下我們並不會直接配置Nacos例項的IP，可用用域名，以便能動態發現。

2.通過Properties配置endpoint，定時訪問，感知叢集變化，並隨機從介面返回的列表中選擇一個例項訪問，客戶端會與Endpoint建立LONG PULL。

Properties properties = new Properties();
properties.put(PropertyKeyConst.ENDPOINT,"10.18.90.16");
properties.put(PropertyKeyConst.ENDPOINT_PORT,"8850");
 
NamingService configService = NacosFactory.createNamingService(properties);
 

• endpoint環境隔離最佳實踐

資料同步

例項資訊同步

例項資訊的由一個叫 Distro （com.alibaba.nacos.naming.consistency.ephemeral.distro.DistroConsistencyServiceImpl）的一致性協議維護，有如下幾個特點：

1. 最終一致性，由例項間通過http同步(com.alibaba.nacos.naming.consistency.ephemeral.distro.TaskDispatcher.TaskScheduler)到除了自己的每個例項節點，且攜帶自己全量資料
   
2. 資料不持久化，儲存在記憶體（com.alibaba.nacos.naming.consistency.ephemeral.distro.DataStore）
3. 每個節點通過演算法，只接受一部分請求（com.alibaba.nacos.naming.web.DistroFilter），如果不屬於例項自己的請求過來則通過演算法確定並轉發。

舉例解釋一下第3點：現有Nacos叢集例項A,B,C 共3個。從客戶端與叢集的互動知道，客戶端隨機從A,B,C中隨機選擇一個例項訪問，客戶端NACOS-DEMO選擇訪問B的註冊例項介面，如果NACOS-DEMO的請求應該屬於C處理的話，本次請求將會被B例項中的DistroFilter攔截掉，並由B轉發到C。理解起來，其實挺繞的，但是為什麼這麼設計呢？畢竟A,B,C的例項資料都會最終一致的，我隨機訪問任意一個例項就好了

我的解釋是：
由於資料是最終一致的，中間會存在同步過程，所以如果存在寫了馬上查的場景，則很有可能查不到的情況（客戶端寫和查兩次請求落在了兩個不同的例項）。但是如果通過演算法，一個例項的增刪改查都在同一個確定的例項，就不會出現這種情況了。

服務叢集資訊

• 通過Open API服務建立介面建立,則直接通過raft協議 持久化到叢集內所有節點
• 如果例項註冊時，如果服務叢集不存在，則靜默建立，前面說了，例項註冊時，會通過Distro 協議通過例項資料到叢集內其它節點，由於例項資訊也附帶了服務叢集等資訊，所以例項上也順便同步了服務叢集等資訊。所以，預設情況下，靜默建立的服務叢集等資訊也是沒有持久化的。當例項註冊時ephemeral欄位設定為false，除了上訴的同步方式外，還會呼叫raft協議，該協議會同步到其它節點並持久化（Raft協議中規定，只有leader才能處理客戶端請求，所有當發現自己不是leader時，會轉發請求，實現如下圖所示）：
  
  

ephemeral欄位的介紹

（Nacos 在 1.0.0版本 instance級別增加了一個ephemeral欄位，該欄位表示註冊的例項是否是臨時例項還是持久化例項。如果是臨時例項，則不會在 Nacos 服務端持久化儲存，需要通過上報心跳的方式進行包活，如果一段時間內沒有上報心跳，則會被 Nacos 服務端摘除。在被摘除後如果又開始上報心跳，則會重新將這個例項註冊。持久化例項則會持久化被 Nacos 服務端，此時即使註冊例項的客戶端程序不在，這個例項也不會從服務端刪除，只會將健康狀態設為不健康）

關於priv-raft協議

Raft協議第8節部分內容：

Clients of Raft send all of their requests to the leader.
When a client first starts up, it connects to a randomlychosen
server. If the client’s first choice is not the leader,
that server will reject the client’s request and supply information
about the most recent leader it has heard from
(AppendEntries requests include the network address of
the leader). If the leader crashes, client requests will time
out; clients then try again with randomly-chosen servers
--------------------------------------------------------------------------
Raft的客戶將所有請求傳送給leader。當客戶機第一次啟動時，
它連線到隨機選擇的伺服器。如果客戶機的首選不是leader，
伺服器將拒絕客戶機的請求，並提供它最近聽到的leader的資訊。
如果leader崩潰，客戶端請求將超時;然後，客戶端再次嘗試隨機選擇的伺服器

Nacos官網說，自己實現的事一個輕量級的raft協議，原因我認為至少有如下兩點：

1. 客戶端是隨機選擇並訪問Nacos例項的
2. Nacos例項分為leader和flower，leader負責寫入，leader和flower都可以查詢，標準的raft協議，客戶端所有請求會發送給leader保證強一致性，nacos的實現是最終一致性。

Raft協議論文

Nacos叢集在k8s中的實踐

Nacos在VM環境下，部署叢集就比較簡單了，如下圖：

只需要在部署Nacos 例項時，在conf/Cluster.conf 中把自己和叢集內其它例項的地址整合到一起即可，比如上圖的架構，Cluster.conf檔案可以是這樣：

ip1:8848

ip2:8848

ip3:8848

這樣就構成了叢集。Nacos例項會輪詢Cluster.conf 檔案，以保證叢集在有新的例項加入時能相互發現以實現例項的擴縮容，具體程式碼實現在（com.alibaba.nacos.naming.cluster.ServerListManager.ServerListUpdater）。

所以在k8s環境下Nacos的叢集應該怎麼玩？毋庸置疑的是，我們不再需要手動去更改Cluster.conf檔案來維護叢集，必須使用k8s的機制去完成自動擴縮容，那麼問題來了，k8s完成擴縮容,，叢集自己怎麼知道呢？

其實是peer-finder-plugin 和 上面說的自動輪詢Cluster.conf機制來達到的。

分析：
通過Helm使用官方的chart包部署的nacos叢集，每一個pod有兩個容器：

• peer-finder-plugin-install : 是一個initContainers ，這個映象唯一的作用是安裝 peer-finder外掛相關的指令碼到指定目錄（plugins/peer-finder/），結束後就死亡。
• nacos-cluster：nacos本體映象，映象啟動時，除了啟動自身的服務外，還會同時呼叫peer-finder-plugin-install 安裝好的指令碼啟動peer-finder（nacos dockerfile）
  peer-finder這個外掛很簡單，使用go語言寫的一個定時輪詢的程式，核心程式碼：
  

peer-finder輪詢（1秒）指定的k8s service ，如果service下面的pod地址列表發生變化，則重新寫入Cluster.conf檔案。這裡的k8s service就必須是headless型別的了，因為只有解析headless提供的域名，才能獲取所有pod的地址列表。

pod啟動時序圖：

呼叫關係圖:

相關推薦