一文詳解 Nacos 高可用特性

前言

服務注冊發現是一個經久不衰的話題，Dubbo 早期開源時默認的注冊中心 ZooKeeper 最早進入人們的視線，并且在很長一段時間里，人們將注冊中心和 ZooKeeper 劃上了等號，可能 ZooKeeper 的設計者都沒有想到這款產品對微服務領域造成了如此深厚的影響，直到 Spring Cloud 開始流行，其自帶的 Eureka 進入了人們的視野，人們這才意識到原來注冊中心還可以有其他的選擇，再到后來，熱衷于開源的阿里把目光也聚焦在了注冊中心這個領域， Nacos 橫空出世，

Kirito 在做注冊中心選型時的思考：曾經我沒得選，現在我只想選擇一個好的注冊中心，它最好是開源的，這樣開放透明，有自我的掌控力，不僅要開源，它還要有活躍的社區，以確保特性演進能夠滿足日益增長的業務需求，出現問題也能即使修復，功能還要很強大，除了滿足注冊服務、推送服務外，還要有完善的微服務體系中所需的功能，最重要的，它還要穩定，最好有大廠的實際使用場景背書，證明這是一個經得起實戰考驗的產品，當然，云原生特性，安全特性也是很重要的······

似乎 Kirito 對注冊中心的要求實在是太高了，但這些五花八門的注冊中心呈現在用戶眼前，總是免不了一番比較，正如上面所言，功能特性、成熟度、可用性、用戶體驗度、云原生特性、安全都是可以拿出來做比較的話題，今天這篇文章重點介紹的是 Nacos 在可用性上的體現，希望借助于這篇文章，能夠讓你對 Nacos 有一個更加深刻的認識，

高可用介紹

當我們在聊高可用時，我們在聊什么？

• 系統可用性達到 99.99%
• 在分布式系統中，部分節點宕機，依舊不影響系統整體運行
• 服務端集群化部署多個節點

這些都可以認為是高可用，而我今天介紹的 Nacos 高可用，則是 Nacos 為了提升系統穩定性而采取的一系列手段，Nacos 的高可用不僅僅存在于服務端，同時也存在于客戶端，以及一些與可用性相關的功能特性中，這些點組裝起來，共同構成了 Nacos 的高可用，

客戶端重試

先統一一下語意，在微服務架構中一般會有三個角色：Consumer、Provider 和 Registry，在今天注冊中心的主題中，Registry 是 nacos-server，而 Consumer 和 Provider 都是 nacos-client，

在生產環境，我們往往需要搭建 Nacos 集群，在 Dubbo 也需要顯式地配置上集群地址：

<dubbo:registry protocol="nacos" address="192.168.0.1:8848,192.168.0.2:8848,192.168.0.3:8848"/>

當其中一臺機器宕機時，為了不影響整體運行，客戶端會存在重試機制，

邏輯非常簡單，拿到地址串列，在請求成功之前逐個嘗試，直到成功為止，

該可用性保證存在于 nacos-client 端，

一致性協議 distro

首先給各位讀者打個強心劑，不用看到”一致性協議“這幾個字就被勸退，本節不會探討一致性協議的實作程序，而是重點介紹其與高可用相關的特性，有的文章介紹 Nacos 的一致性模型是 AP + CP，這么說很容易讓人誤解，其實 Nacos 并不是支持兩種一致性模型，也并不是支持兩種模型的切換，介紹一致性模型之前，需要先了解到 Nacos 中的兩個概念：臨時服務和持久化服務，

• 臨時服務（Ephemeral）：臨時服務健康檢查失敗后會從串列中洗掉，常用于服務注冊發現場景，
• 持久化服務（Persistent）：持久化服務健康檢查失敗后會被標記成不健康，常用于 DNS 場景，

臨時服務使用的是 Nacos 為服務注冊發現場景定制化的私有協議 distro，其一致性模型是 AP；而持久化服務使用的是 raft 協議，其一致性模型是 CP，所以以后不要再說 Nacos 是 AP + CP 了，更建議加上服務節點狀態或者使用場景的約束，

distro 協議與高可用有什么關系呢？上一節我們提到 nacos-server 節點宕機后，客戶端會重試，但少了一個前提，即 nacos-server 少了一個節點后依舊可以正常作業，Nacos 這種有狀態的應用和一般無狀態的 Web 應用不同，并不是說只要存活一個節點就可以對外提供服務的，需要分 case 討論，這與其一致性協議的設計有關，distro 協議的作業流程如下：

• Nacos 啟動時首先從其他遠程節點同步全部資料，
• Nacos 每個節點是平等的都可以處理寫入請求，同時把新資料同步到其他節點，
• 每個節點只負責部分資料，定時發送自己負責資料的校驗值到其他節點來保持資料一致性，

如上圖所示，每個節點負責一部分服務的寫入，但每個節點都可以接收到寫入請求，這時就存在兩種情況：

• 當該節點接收到屬于該節點負責的服務時，直接寫入，
• 當該節點接收到不屬于該節點負責的服務時，將在集群內部路由，轉發給對應的節點，從而完成寫入，

讀取操作則不需要路由，因為集群中的各個節點會同步服務狀態，每個節點都會有一份最新的服務資料，

而當節點發生宕機后，原本該節點負責的一部分服務的寫入任務會轉移到其他節點，從而保證 Nacos 集群整體的可用性，

一個比較復雜的情況是，節點沒有宕機，但是出現了網路磁區，即下圖所示：

這個情況會損害可用性，客戶端會表現為有時候服務存在有時候服務不存在，

綜上，Nacos 的 distro 一致性協議可以保證在大多數情況下，集群中的機器宕機后依舊不損害整體的可用性，該可用性保證存在于 nacos-server 端，

本地快取檔案 Failover 機制

注冊中心發生故障最壞的一個情況是整個 Server 端宕機，這時候 Nacos 依舊有高可用機制做兜底，

一道經典的 Dubbo 面試題：當 Dubbo 應用運行時，Nacos 注冊中心宕機，會不會影響 RPC 呼叫，這個題目大多數應該都能回答出來，因為 Dubbo 記憶體里面是存了一份地址的，一方面這樣的設計是為了性能，因為不可能每次 RPC 呼叫時都讀取一次注冊中心，另一面，注冊中心宕機后記憶體會有一份資料，這也起到了可用性的保障（盡管可能 Dubbo 設計者并沒有考慮這個因素），

那如果，我在此基礎上再拋出一個問題：Nacos 注冊中心宕機，Dubbo 應用發生重啟，會不會影響 RPC 呼叫，如果了解了 Nacos 的 Failover 機制，應當得到和上一題同樣的回答：不會，

Nacos 存在本地檔案快取機制，nacos-client 在接收到 nacos-server 的服務推送之后，會在記憶體中保存一份，隨后會落盤存盤一份快照，snapshot 默認的存盤路徑為：{USER_HOME}/nacos/naming/ 中：

這份檔案有兩種價值，一是用來排查服務端是否正常推送了服務；二是當客戶端加載服務時，如果無法從服務端拉取到資料，會默認從本地檔案中加載，

前提是構建 NacosNaming 時傳入了該引數：namingLoadCacheAtStart=true
Dubbo 2.7.4 及以上版本支持該 Nacos 引數；開啟該引數的方式：dubbo.registry.address=nacos://127.0.0.1:8848?namingLoadCacheAtStart=true

在生產環境，推薦開啟該引數，以避免注冊中心宕機后，導致服務不可用，在服務注冊發現場景，可用性和一致性 trade off 時，我們大多數時候會優先考慮可用性，

細心的讀者還注意到
{USER_HOME}/nacos/naming/{namespace} 下除了快取檔案之外還有一個 failover 檔案夾，里面存放著和 snapshot 一致的檔案夾，這是 Nacos 的另一個 failover 機制，snapshot 是按照某個歷史時刻的服務快斬訓復恢復，而 failover 中的服務可以人為修改，以應對一些極端場景，

該可用性保證存在于 nacos-client 端，

心跳同步服務

心跳機制一般廣泛存在于分布式通信領域，用于確認存活狀態，一般心跳請求和普通請求的設計是有差異的，心跳請求一般被設計的足夠精簡，這樣在定時探測時可以盡可能避免性能下降，而在 Nacos 中，出于可用性的考慮，一個心跳報文包含了全部的服務資訊，這樣相比僅僅發送探測資訊降低了吞吐量，而提升了可用性，怎么理解呢？考慮以下的兩種場景：

• nacos-server 節點全部宕機，服務資料全部丟失，nacos-server 即使恢復運作，也無法恢復出服務，而心跳包含全部內容可以在心跳期間就恢復出服務，保證可用性，
• nacos-server 出現網路磁區，由于心跳可以創建服務，從而在極端網路故障下，依舊保證基礎的可用性，

以下是對心跳同步服務的測驗，使用阿里云 MSE 提供 Nacos 集群進行測驗：

呼叫 OpenApi 依次洗掉各個服務：

curl -X "DELETE mse-xxx-p.nacos-ans.mse.aliyuncs.com:8848/nacos/v1/ns/service?serviceName=providers:com.alibaba.edas.boot.EchoService:1.0.0:DUBBO&groupName=DEFAULT_GROUP"

過 5s 后重繪，服務又再次被注冊了上來，符合我們對心跳注冊服務的預期，

集群部署模式高可用

最后給大家分享的 Nacos 高可用特性來自于其部署架構，

節點數量

我們知道在生產集群中肯定不能以單機模式運行 Nacos，那么第一個問題便是：我應該部署幾臺機器？前面我們提到 Nacos 有兩個一致性協議：distro 和 raft，distro 協議不會有腦裂問題，所以理論來說，節點數大于等于 2 即可；raft 協議的投票選舉機制則建議是 2n+1 個節點，綜合來看，選擇 3 個節點是起碼的，其次處于吞吐量和更高可用性的考量，可以選擇 5 個，7 個，甚至 9 個節點的集群，

多可用區部署

組成集群的 Nacos 節點，應該盡可能考慮兩個因素：

• 各個節點之間的網路時延不能很高，否則會影響資料同步，
• 各個節點所處機房、可用區應當盡可能分散，以避免單點故障，

以阿里云的 ECS 為例，選擇同一個 Region 的不同可用區就是一個很好的實踐，

部署模式

主要分為 K8s 部署和 ECS 部署兩種模式，

ECS 部署的優點在于簡單，購買三臺機器即可搭建集群，如果你熟練 Nacos 集群部署的話，這不是難事，但無法解決運維問題，如果 Nacos 某個節點出現 OOM 或者磁盤問題，很難迅速摘除，無法實作自運維，

K8s 部署的有點在于云原生運維能力強，可以在節點宕機后實作自恢復，保障 Nacos 的平穩運行，前面提到過，Nacos 和無狀態的 Web 應用不同，它是一個有狀態的應用，所以在 K8s 中部署，往往要借助于 StatefulSet 和 Operator 等組件才能實作 Nacos 集群的部署和運維，

MSE Nacos 的高可用最佳實踐

阿里云微服務引擎 MSE 提供了 Nacos 集群的托管能力，實作了集群部署模式的高可用，

• 當創建多個節點的集群時，系統會默認分配在不同可用區，同時，這對于用戶來說又是透明的，用戶只需要關心 Nacos 的功能即可，MSE 替用戶兜底可用性，
• MSE 底層使用 K8s 運維模式部署 Nacos，歷史上出現過用戶誤用 Nacos 導致部分節點宕機的問題，但借助于 K8s 的自運維模式，宕機節點迅速被拉起，以至于用戶可能都沒有意識到自己發生宕機，

下面模擬一個節點宕機的場景，來看看 K8s 如何實作自恢復，

一個三節點的 Nacos 集群：

執行kubectl delete pod mse-7654c960-1605278296312-reg-center-0-2 以模擬部分節點宕機的場景，

大概 2 分鐘后，節點恢復，并且角色發生了轉換，Leader 從殺死的 2 號節點轉給 1 號節點，

總結

本文從多個角度出發，總結了一下 Nacos 是如何保障高可用的，高可用特性絕不是靠服務端多部署幾個節點就可以獲得的，而是要結合客戶端使用方式、服務端部署模式、使用場景綜合來考慮的一件事，

特別是在服務注冊發現場景，Nacos 為可用性做了非常多的努力，而這些保障，ZooKeeper 是不一定有的，在做注冊中心選型時，可用性保障上，Nacos 絕對是優秀的，