[[358854]]

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

前言

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

注冊(cè)中心

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

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

高可用介紹

當(dāng)我們?cè)诹母呖捎脮r(shí)，我們?cè)诹氖裁?

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

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

客戶端重試

先統(tǒng)一一下語(yǔ)義，在微服務(wù)架構(gòu)中一般會(huì)有三個(gè)角色：Consumer、Provider 和 Registry，在今天注冊(cè)中心的主題中，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)其中一臺(tái)機(jī)器宕機(jī)時(shí)，為了不影響整體運(yùn)行，客戶端會(huì)存在重試機(jī)制

輪詢 server

邏輯非常簡(jiǎn)單，拿到地址列表，在請(qǐng)求成功之前逐個(gè)嘗試，直到成功為止。

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

一致性協(xié)議 distro

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

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

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

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

• Nacos 啟動(dòng)時(shí)首先從其他遠(yuǎn)程節(jié)點(diǎn)同步全部數(shù)據(jù)
• Nacos 每個(gè)節(jié)點(diǎn)是平等的都可以處理寫(xiě)入請(qǐng)求，同時(shí)把新數(shù)據(jù)同步到其他節(jié)點(diǎn)
• 每個(gè)節(jié)點(diǎn)只負(fù)責(zé)部分?jǐn)?shù)據(jù)，定時(shí)發(fā)送自己負(fù)責(zé)數(shù)據(jù)校驗(yàn)值到其他節(jié)點(diǎn)來(lái)保持?jǐn)?shù)據(jù)一致性

集群正常狀態(tài)

如上圖所示，每個(gè)節(jié)點(diǎn)服務(wù)一部分服務(wù)的讀寫(xiě)，但每個(gè)節(jié)點(diǎn)都可以接收到讀寫(xiě)請(qǐng)求，這時(shí)就存在兩種讀寫(xiě)情況：

當(dāng)該節(jié)點(diǎn)接收到屬于該節(jié)點(diǎn)負(fù)責(zé)的服務(wù)時(shí)，直接讀寫(xiě)。

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

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

部分節(jié)點(diǎn)宕機(jī)

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

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

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

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

本地緩存文件 Failover 機(jī)制

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

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

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

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

Nacos snapshot 文件目錄

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

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

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

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

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

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

心跳同步服務(wù)

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

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

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

調(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" 依次刪除各個(gè)服務(wù)

過(guò) 5s 后刷新，服務(wù)又再次被注冊(cè)了上來(lái)，符合我們對(duì)心跳注冊(cè)服務(wù)的預(yù)期。

集群部署模式高可用

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

節(jié)點(diǎn)數(shù)量

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

多可用區(qū)部署

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

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

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

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

部署模式

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

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

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

MSE Nacos 的高可用最佳實(shí)踐

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

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

下面模擬一個(gè)節(jié)點(diǎn)宕機(jī)的場(chǎng)景，來(lái)看看 K8s 如何實(shí)現(xiàn)自恢復(fù)。

一個(gè)三節(jié)點(diǎn)的 Nacos 集群：

正常狀態(tài)

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

恢復(fù)中

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

恢復(fù)后 leader 重選

總結(jié)

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

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