[[358854]]

本文轉(zhuǎn)載自微信公眾號「Kirito的技術(shù)分享」，作者kiritomoe。轉(zhuǎn)載本文請聯(lián)系Kirito的技術(shù)分享公眾號。   

前言

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

注冊中心

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

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

高可用介紹

當(dāng)我們在聊高可用時，我們在聊什么?

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

這些都可以認為是高可用，而我今天介紹的 Nacos 高可用，則是一些 Nacos 為了提升系統(tǒng)穩(wěn)定性而采取的一系列手段。Nacos 的高可用不僅僅存在于服務(wù)端，同時它也存在于客戶端，以及一些與可用性相關(guān)的功能特性中。這些點組裝起來，共同構(gòu)成了 Nacos 的高可用。

客戶端重試

先統(tǒng)一一下語義，在微服務(wù)架構(gòu)中一般會有三個角色：Consumer、Provider 和 Registry，在今天注冊中心的主題中，Registry 是 nacos-server，而 Consumer 和 Provider 都是 nacos-client。

在生產(chǎn)環(huán)境，我們往往需要搭建 Nacos 集群，在 Dubbo 也需要顯式地配置上集群地址：

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

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

輪詢 server

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

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

一致性協(xié)議 distro

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

• 臨時服務(wù)(Ephemeral)：臨時服務(wù)健康檢查失敗后會從列表中刪除，常用于服務(wù)注冊發(fā)現(xiàn)場景。
• 持久化服務(wù)(Persistent)：持久化服務(wù)健康檢查失敗后會被標(biāo)記成不健康，常用于 DNS 場景。

臨時服務(wù)使用的是 Nacos 為服務(wù)注冊發(fā)現(xiàn)場景定制化的私有協(xié)議 distro，其一致性模型是 AP;而持久化服務(wù)使用的是 raft 協(xié)議，其一致性模型是 CP。所以以后不要再說 Nacos 是 AP + CP 了，更建議加上服務(wù)節(jié)點狀態(tài)或者使用場景的約束。

distro 協(xié)議與高可用有什么關(guān)系呢?上一節(jié)我們提到 nacos-server 節(jié)點宕機后，客戶端會重試，但少了一個前提，即 nacos-server 少了一個節(jié)點后依舊可以正常工作。Nacos 這種有狀態(tài)的應(yīng)用和一般無狀態(tài)的 Web 應(yīng)用不同，并不是說只要存活一個節(jié)點就可以對外提供服務(wù)的，需要分 case 討論，這與其一致性協(xié)議的設(shè)計有關(guān)。distro 協(xié)議的工作流程如下：

• Nacos 啟動時首先從其他遠程節(jié)點同步全部數(shù)據(jù)
• Nacos 每個節(jié)點是平等的都可以處理寫入請求，同時把新數(shù)據(jù)同步到其他節(jié)點
• 每個節(jié)點只負責(zé)部分數(shù)據(jù)，定時發(fā)送自己負責(zé)數(shù)據(jù)校驗值到其他節(jié)點來保持數(shù)據(jù)一致性

集群正常狀態(tài)

如上圖所示，每個節(jié)點服務(wù)一部分服務(wù)的讀寫，但每個節(jié)點都可以接收到讀寫請求，這時就存在兩種讀寫情況：

當(dāng)該節(jié)點接收到屬于該節(jié)點負責(zé)的服務(wù)時，直接讀寫。

當(dāng)該節(jié)點接收到不屬于該節(jié)點負責(zé)的服務(wù)時，將在集群內(nèi)部路由，轉(zhuǎn)發(fā)給對應(yīng)的節(jié)點，從而完成讀寫。

而當(dāng)節(jié)點發(fā)生宕機后，原本該節(jié)點負責(zé)的一部分服務(wù)的讀寫任務(wù)會轉(zhuǎn)移到其他節(jié)點，從而保證 Nacos 集群整體的可用性。

部分節(jié)點宕機

一個比較復(fù)雜的情況是，節(jié)點沒有宕機，但是出現(xiàn)了網(wǎng)絡(luò)分區(qū)，即下圖所示：

網(wǎng)絡(luò)分區(qū)

這個情況會損害可用性，客戶端會表現(xiàn)為有時候服務(wù)存在有時候服務(wù)不存在。

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

本地緩存文件 Failover 機制

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

一道經(jīng)典的 Dubbo 面試題：當(dāng) Dubbo 應(yīng)用運行時，Nacos 注冊中心宕機，會不會影響 RPC 調(diào)用。這個題目大多數(shù)應(yīng)該都能回答出來，因為 Dubbo 內(nèi)存里面是存了一份地址的，一方面這樣的設(shè)計是為了性能，因為不可能每次 RPC 調(diào)用時都讀取一次注冊中心，另一面，這也起到了可用性的保障(盡管可能 Dubbo 設(shè)計者并沒有考慮這個因素)。

那如果，我在此基礎(chǔ)上再出一道 Dubbo 面試題：Nacos 注冊中心宕機，Dubbo 應(yīng)用發(fā)生重啟，會不會影響 RPC 調(diào)用。如果了解了 Nacos 的 Failover 機制，應(yīng)當(dāng)?shù)玫胶蜕弦活}同樣的回答：不會。

Nacos 存在本地文件緩存機制，nacos-client 在接收到 nacos-server 的服務(wù)推送之后，會在內(nèi)存中保存一份，隨后會落盤存儲一份快照。snapshot 默認的存儲路徑為：{USER_HOME}/nacos/naming/ 中

Nacos snapshot 文件目錄

這份文件有兩種價值，一是用來排查服務(wù)端是否正常推送了服務(wù);二是當(dāng)客戶端加載服務(wù)時，如果無法從服務(wù)端拉取到數(shù)據(jù)，會默認從本地文件中加載。

前提是構(gòu)建 NacosNaming 時傳入了該參數(shù)：namingLoadCacheAtStart=true

Dubbo 2.7.4 及以上版本支持該 Nacos 參數(shù);開啟該參數(shù)的方式：dubbo.registry.address=nacos://127.0.0.1:8848?namingLoadCacheAtStart=true

在生產(chǎn)環(huán)境，推薦開啟該參數(shù)，以避免注冊中心宕機后，導(dǎo)致服務(wù)不可用的穩(wěn)定，在服務(wù)注冊發(fā)現(xiàn)場景，可用性和一致性 trade off 時，我們大多數(shù)時候會優(yōu)先考慮可用性。

細心的讀者還注意到 {USER_HOME}/nacos/naming/{namespace} 下除了緩存文件之外還有一個 failover 文件夾，里面存放著和 snapshot 一致的文件夾。這是 Nacos 的另一個 failover 機制，snapshot 是按照某個歷史時刻的服務(wù)快照恢復(fù)恢復(fù)，而 failover 中的服務(wù)可以人為修改，以應(yīng)對一些極端場景。

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

心跳同步服務(wù)

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

• nacos-server 節(jié)點全部宕機，服務(wù)數(shù)據(jù)全部丟失。nacos-server 即使恢復(fù)運作，也無法恢復(fù)出服務(wù)，而心跳包含全部內(nèi)容可以在心跳期間就恢復(fù)出服務(wù)，保證可用性。
• nacos-server 出現(xiàn)網(wǎng)絡(luò)分區(qū)。由于心跳可以創(chuàng)建服務(wù)，從而在極端網(wǎng)絡(luò)故障下，依舊保證基礎(chǔ)的可用性。

以下是對心跳同步服務(wù)的測試，使用阿里云 MSE 提供 Nacos 集群進行測試

調(diào)用 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" 依次刪除各個服務(wù)

過 5s 后刷新，服務(wù)又再次被注冊了上來，符合我們對心跳注冊服務(wù)的預(yù)期。

集群部署模式高可用

最后給大家分享的 Nacos 高可用特性來自于其部署架構(gòu)。

節(jié)點數(shù)量

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

多可用區(qū)部署

組成集群的 Nacos 節(jié)點，應(yīng)該盡可能考慮兩個因素：

各個節(jié)點之間的網(wǎng)絡(luò)時延不能很高，否則會影響數(shù)據(jù)同步

各個節(jié)點所處機房、可用區(qū)應(yīng)當(dāng)盡可能分散，以避免單點故障

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

部署模式

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

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

K8s 部署的有點在于云原生運維能力強，可以在節(jié)點宕機后實現(xiàn)自恢復(fù)，保障 Nacos 的平穩(wěn)運行。前面提到過，Nacos 和無狀態(tài)的 Web 應(yīng)用不同，它是一個有狀態(tài)的應(yīng)用，所以在 K8s 中部署，往往要借助于 StatefulSet 和 Operator 等組件才能實現(xiàn) Nacos 集群的部署和運維。

MSE Nacos 的高可用最佳實踐

阿里云 MSE(微服務(wù)引擎)提供了 Nacos 集群的托管能力，實現(xiàn)了集群部署模式的高可用。

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

下面模擬一個節(jié)點宕機的場景，來看看 K8s 如何實現(xiàn)自恢復(fù)。

一個三節(jié)點的 Nacos 集群：

正常狀態(tài)

執(zhí)行 kubectl delete pod mse-7654c960-1605278296312-reg-center-0-2 以模擬部分節(jié)點宕機的場景。

恢復(fù)中

大概 2 分鐘后，節(jié)點恢復(fù)，并且角色發(fā)生了轉(zhuǎn)換，Leader 從殺死的 2 號節(jié)點轉(zhuǎn)給 1 號節(jié)點

恢復(fù)后 leader 重選

總結(jié)

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

特別是在服務(wù)注冊發(fā)現(xiàn)場景，Nacos 為可用性做了非常多的努力，而這些保障，Zookeeper 是不一定有的。在做注冊中心選型時，可用性保障上，Nacos 絕對是優(yōu)秀的。