建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
大家好，我是三友~~
今天就應(yīng)某位小伙伴的要求，來(lái)講一講Nacos作為服務(wù)注冊(cè)中心底層的實(shí)現(xiàn)原理
不知你是否跟我一樣，在使用Nacos時(shí)有以下幾點(diǎn)疑問(wèn)：
- 臨時(shí)實(shí)例和永久實(shí)例是什么？有什么區(qū)別？
- 服務(wù)實(shí)例是如何注冊(cè)到服務(wù)端的？
- 服務(wù)實(shí)例和服務(wù)端之間是如何保活的？
- 服務(wù)訂閱是如何實(shí)現(xiàn)的？
- 集群間數(shù)據(jù)是如何同步的？CP還是AP？
- Nacos的數(shù)據(jù)模型是什么樣的？
- ...
本文就通過(guò)探討上述問(wèn)題來(lái)探秘Nacos服務(wù)注冊(cè)中心核心的底層實(shí)現(xiàn)原理。
雖然Nacos最新版本已經(jīng)到了2.x版本，但是為了照顧那些還在用1.x版本的同學(xué)，所以本文我會(huì)同時(shí)去講1.x版本和2.x版本的實(shí)現(xiàn)
觀(guān)前提醒，本文又又又是一篇超長(zhǎng)的干貨，非常適合一鍵三連~~
臨時(shí)實(shí)例和永久實(shí)例
臨時(shí)實(shí)例和永久實(shí)例在Nacos中是一個(gè)非常非常重要的概念
之所以說(shuō)它重要，主要是因?yàn)槲以谧x源碼的時(shí)候發(fā)現(xiàn)，臨時(shí)實(shí)例和永久實(shí)例在底層的許多實(shí)現(xiàn)機(jī)制是完全不同的
臨時(shí)實(shí)例
臨時(shí)實(shí)例在注冊(cè)到注冊(cè)中心之后僅僅只保存在服務(wù)端內(nèi)部一個(gè)緩存中，不會(huì)持久化到磁盤(pán)
這個(gè)服務(wù)端內(nèi)部的緩存在注冊(cè)中心屆一般被稱(chēng)為服務(wù)注冊(cè)表
當(dāng)服務(wù)實(shí)例出現(xiàn)異?；蛘呦戮€(xiàn)之后，就會(huì)把這個(gè)服務(wù)實(shí)例從服務(wù)注冊(cè)表中剔除
永久實(shí)例
永久服務(wù)實(shí)例不僅僅會(huì)存在服務(wù)注冊(cè)表中，同時(shí)也會(huì)被持久化到磁盤(pán)文件中
當(dāng)服務(wù)實(shí)例出現(xiàn)異常或者下線(xiàn)，Nacos只會(huì)將服務(wù)實(shí)例的健康狀態(tài)設(shè)置為不健康，并不會(huì)對(duì)將其從服務(wù)注冊(cè)表中剔除
所以這個(gè)服務(wù)實(shí)例的信息你還是可以從注冊(cè)中心看到，只不過(guò)處于不健康狀態(tài)
這是就是兩者最最最基本的區(qū)別
當(dāng)然除了上述最基本的區(qū)別之外，兩者還有很多其它的區(qū)別，接下來(lái)本文還會(huì)提到
這里你可能會(huì)有一個(gè)疑問(wèn)
為什么Nacos要將服務(wù)實(shí)例分為臨時(shí)實(shí)例和永久實(shí)例?
主要還是因?yàn)閼?yīng)用場(chǎng)景不同
臨時(shí)實(shí)例就比較適合于業(yè)務(wù)服務(wù)，服務(wù)下線(xiàn)之后可以不需要在注冊(cè)中心中查看到
永久實(shí)例就比較適合需要運(yùn)維的服務(wù)，這種服務(wù)幾乎是永久存在的，比如說(shuō)MySQL、Redis等等
MySQL、Redis等服務(wù)實(shí)例可以通過(guò)SDK手動(dòng)注冊(cè)
對(duì)于這些服務(wù)，我們需要一直看到服務(wù)實(shí)例的狀態(tài)，即使出現(xiàn)異常，也需要能夠查看時(shí)實(shí)的狀態(tài)
所以從這可以看出Nacos跟你印象中的注冊(cè)中心不太一樣，他不僅僅可以注冊(cè)平時(shí)業(yè)務(wù)中的實(shí)例，還可以注冊(cè)像MySQL、Redis這個(gè)服務(wù)實(shí)例的信息到注冊(cè)中心
在SpringCloud環(huán)境底下，一般其實(shí)都是業(yè)務(wù)服務(wù)，所以默認(rèn)注冊(cè)服務(wù)實(shí)例都是臨時(shí)實(shí)例
當(dāng)然如果你想改成永久實(shí)例，可以通過(guò)下面這個(gè)配置項(xiàng)來(lái)完成
spring
cloud:
nacos:
discovery:
#ephemeral單詞是臨時(shí)的意思，設(shè)置成false，就是永久實(shí)例了
ephemeral: false這里還有一個(gè)小細(xì)節(jié)
在1.x版本中，一個(gè)服務(wù)中可以既有臨時(shí)實(shí)例也有永久實(shí)例，服務(wù)實(shí)例是永久還是臨時(shí)是由服務(wù)實(shí)例本身決定的
但是2.x版本中，一個(gè)服務(wù)中的所有實(shí)例要么都是臨時(shí)的要么都是永久的，是由服務(wù)決定的，而不是具體的服務(wù)實(shí)例
所以在2.x可以說(shuō)是臨時(shí)服務(wù)和永久服務(wù)
圖片
為什么2.x把臨時(shí)還是永久的屬性由實(shí)例本身決定改成了由服務(wù)決定?
其實(shí)很簡(jiǎn)單，你想想，假設(shè)對(duì)一個(gè)MySQL服務(wù)來(lái)說(shuō)，它的每個(gè)服務(wù)實(shí)例肯定都是永久的，不會(huì)出現(xiàn)一些是永久的，一些是臨時(shí)的情況吧
所以臨時(shí)還是永久的屬性由服務(wù)本身決定其實(shí)就更加合理了
服務(wù)注冊(cè)
作為一個(gè)服務(wù)注冊(cè)中心，服務(wù)注冊(cè)肯定是一個(gè)非常重要的功能
所謂的服務(wù)注冊(cè)，就是通過(guò)注冊(cè)中心提供的客戶(hù)端SDK（或者是控制臺(tái)）將服務(wù)本身的一些元信息，比如ip、端口等信息發(fā)送到注冊(cè)中心服務(wù)端
服務(wù)端在接收到服務(wù)之后，會(huì)將服務(wù)的信息保存到前面提到的服務(wù)注冊(cè)表中
1、1.x版本的實(shí)現(xiàn)
在Nacos在1.x版本的時(shí)候，服務(wù)注冊(cè)是通過(guò)Http接口實(shí)現(xiàn)的
圖片
代碼如下
圖片
整個(gè)邏輯比較簡(jiǎn)單，因?yàn)镹acos服務(wù)端本身就是用SpringBoot寫(xiě)的
但是在2.x版本的實(shí)現(xiàn)就比較復(fù)雜了
2、2.x版本的實(shí)現(xiàn)
2.1、通信協(xié)議的改變
2.x版本相比于1.x版本最主要的升級(jí)就是客戶(hù)端和服務(wù)端通信協(xié)議的改變，由1.x版本的Http改成了2.x版本gRPC
gRPC是谷歌公司開(kāi)發(fā)的一個(gè)高性能、開(kāi)源和通用的RPC框架，Java版本的實(shí)現(xiàn)底層也是基于Netty來(lái)的
之所以改成了gRPC，主要是因?yàn)镠ttp請(qǐng)求會(huì)頻繁創(chuàng)建和銷(xiāo)毀連接，白白浪費(fèi)資源
所以在2.x版本之后，為了提升性能，就將通信協(xié)議改成了gRPC
根據(jù)官網(wǎng)顯示，整體的效果還是很明顯，相比于1.x版本，注冊(cè)性能總體提升至少2倍
雖然通信方式改成了gRPC，但是2.x版本服務(wù)端依然保留了Http注冊(cè)的接口，所以用1.x的Nacos SDK依然可以注冊(cè)到2.x版本的服務(wù)端
2.2、具體的實(shí)現(xiàn)
Nacos客戶(hù)端在啟動(dòng)的時(shí)候，會(huì)通過(guò)gRPC跟服務(wù)端建立長(zhǎng)連接
圖片
這個(gè)連接會(huì)一直存在，之后客戶(hù)端與服務(wù)端所有的通信都是基于這個(gè)長(zhǎng)連接來(lái)的
當(dāng)客戶(hù)端發(fā)起注冊(cè)的時(shí)候，就會(huì)通過(guò)這個(gè)長(zhǎng)連接，將服務(wù)實(shí)例的信息發(fā)送給服務(wù)端
服務(wù)端拿到服務(wù)實(shí)例，跟1.x一樣，也會(huì)存到服務(wù)注冊(cè)表
除了注冊(cè)之外，當(dāng)注冊(cè)的是臨時(shí)實(shí)例時(shí)，2.x還會(huì)將服務(wù)實(shí)例信息存儲(chǔ)到客戶(hù)端中的一個(gè)緩存中，供Redo操作
所謂的Redo操作，其實(shí)就是一個(gè)補(bǔ)償機(jī)制，本質(zhì)是個(gè)定時(shí)任務(wù)，默認(rèn)每3s執(zhí)行一次
這個(gè)定時(shí)任務(wù)作用是，當(dāng)客戶(hù)端與服務(wù)端重新建立連接時(shí)（因?yàn)橐恍┊惓Ｔ驅(qū)е逻B接斷開(kāi)）
那么之前注冊(cè)的服務(wù)實(shí)例肯定還要繼續(xù)注冊(cè)服務(wù)端（斷開(kāi)連接服務(wù)實(shí)例就會(huì)被剔除服務(wù)注冊(cè)表）
所以這個(gè)Redo操作一個(gè)很重要的作用就是重連之后的重新注冊(cè)的作用
除了注冊(cè)之外，比如服務(wù)訂閱之類(lèi)的操作也需要Redo操作，當(dāng)連接重新建立，之前客戶(hù)端的操作都需要Redo一下
小總結(jié)
1.x版本是通過(guò)Http協(xié)議來(lái)進(jìn)行服務(wù)注冊(cè)的
2.x由于客戶(hù)端與服務(wù)端的通信改成了gRPC長(zhǎng)連接，所以改成通過(guò)gRPC長(zhǎng)連接來(lái)注冊(cè)
2.x比1.x多個(gè)Redo操作，當(dāng)注冊(cè)的服務(wù)實(shí)例是臨時(shí)實(shí)例是，出現(xiàn)網(wǎng)絡(luò)異常，連接重新建立之后，客戶(hù)端需要將服務(wù)注冊(cè)、服務(wù)訂閱之類(lèi)的操作進(jìn)行重做
這里你可能會(huì)有個(gè)疑問(wèn)
既然2.x有Redo機(jī)制保證客戶(hù)端與服務(wù)端通信正常之后重新注冊(cè)，那么1.x有類(lèi)似的這種Redo機(jī)制么？
當(dāng)然也會(huì)有，接下往下看。
心跳機(jī)制
心跳機(jī)制，也可以被稱(chēng)為?；顧C(jī)制，它的作用就是服務(wù)實(shí)例告訴注冊(cè)中心我這個(gè)服務(wù)實(shí)例還活著
圖片
在正常情況下，服務(wù)關(guān)閉了，那么服務(wù)會(huì)主動(dòng)向Nacos服務(wù)端發(fā)送一個(gè)服務(wù)下線(xiàn)的請(qǐng)求
Nacos服務(wù)端在接收到請(qǐng)求之后，會(huì)將這個(gè)服務(wù)實(shí)例從服務(wù)注冊(cè)表中剔除
但是對(duì)于異常情況下，比如出現(xiàn)網(wǎng)絡(luò)問(wèn)題，可能導(dǎo)致這個(gè)注冊(cè)的服務(wù)實(shí)例無(wú)法提供服務(wù)，處于不可用狀態(tài)，也就是不健康
而此時(shí)在沒(méi)有任何機(jī)制的情況下，服務(wù)端是無(wú)法知道這個(gè)服務(wù)處于不可用狀態(tài)
所以為了避免這種情況，一些注冊(cè)中心，就比如Nacos、Eureka，就會(huì)用心跳機(jī)制來(lái)判斷這個(gè)服務(wù)實(shí)例是否能正常
在Nacos中，心跳機(jī)制僅僅是針對(duì)臨時(shí)實(shí)例來(lái)說(shuō)的，臨時(shí)實(shí)例需要靠心跳機(jī)制來(lái)?；?/p>
心跳機(jī)制在1.x和2.x版本的實(shí)現(xiàn)也是不一樣的
1.x心跳實(shí)現(xiàn)
在1.x中，心跳機(jī)制實(shí)現(xiàn)是通過(guò)客戶(hù)端和服務(wù)端各存在的一個(gè)定時(shí)任務(wù)來(lái)完成的
在服務(wù)注冊(cè)時(shí)，發(fā)現(xiàn)是臨時(shí)實(shí)例，客戶(hù)端會(huì)開(kāi)啟一個(gè)5s執(zhí)行一次的定時(shí)任務(wù)
圖片
這個(gè)定時(shí)任務(wù)會(huì)構(gòu)建一個(gè)Http請(qǐng)求，攜帶這個(gè)服務(wù)實(shí)例的信息，然后發(fā)送到服務(wù)端
圖片
在Nacos服務(wù)端也會(huì)開(kāi)啟一個(gè)定時(shí)任務(wù)，默認(rèn)也是5s執(zhí)行一次，去檢查這些服務(wù)實(shí)例最后一次心跳的時(shí)間，也就是客戶(hù)端最后一次發(fā)送Http請(qǐng)求的時(shí)間
- 當(dāng)最后一次心跳時(shí)間超過(guò)15s，但沒(méi)有超過(guò)30s，會(huì)把這服務(wù)實(shí)例標(biāo)記成不健康
- 當(dāng)最后一次心跳超過(guò)30s，直接把服務(wù)從服務(wù)注冊(cè)表中剔除
圖片
這就是1.x版本的心跳機(jī)制，本質(zhì)就是兩個(gè)定時(shí)任務(wù)
其實(shí)1.x的這個(gè)心跳還有一個(gè)作用，就是跟上一節(jié)說(shuō)的gRPC時(shí)Redo操作的作用是一樣的
服務(wù)在處理心跳的時(shí)候，發(fā)現(xiàn)心跳攜帶這個(gè)服務(wù)實(shí)例的信息在注冊(cè)表中沒(méi)有，此時(shí)就會(huì)添加到服務(wù)注冊(cè)表
所以心跳也有Redo的類(lèi)似效果
2.x心跳實(shí)現(xiàn)
在2.x版本之后，由于通信協(xié)議改成了gRPC，客戶(hù)端與服務(wù)端保持長(zhǎng)連接，所以2.x版本之后它是利用這個(gè)gRPC長(zhǎng)連接本身的心跳來(lái)保活
一旦這個(gè)連接斷開(kāi)，服務(wù)端就會(huì)認(rèn)為這個(gè)連接注冊(cè)的服務(wù)實(shí)例不可用，之后就會(huì)將這個(gè)服務(wù)實(shí)例從服務(wù)注冊(cè)表中提出剔除
除了連接本身的心跳之外，Nacos還有服務(wù)端的一個(gè)主動(dòng)檢測(cè)機(jī)制
Nacos服務(wù)端也會(huì)啟動(dòng)一個(gè)定時(shí)任務(wù)，默認(rèn)每隔3s執(zhí)行一次
這個(gè)任務(wù)會(huì)去檢查超過(guò)20s沒(méi)有發(fā)送請(qǐng)求數(shù)據(jù)的連接
一旦發(fā)現(xiàn)有連接已經(jīng)超過(guò)20s沒(méi)發(fā)送請(qǐng)求，那么就會(huì)向這個(gè)連接對(duì)應(yīng)的客戶(hù)端發(fā)送一個(gè)請(qǐng)求
如果請(qǐng)求不通或者響應(yīng)失敗，此時(shí)服務(wù)端也會(huì)認(rèn)為與客戶(hù)端的這個(gè)連接異常，從而將這個(gè)客戶(hù)端注冊(cè)的服務(wù)實(shí)例從服務(wù)注冊(cè)表中剔除
所以對(duì)于2.x版本，主要是兩種機(jī)制來(lái)進(jìn)行?；睿?/p>
- 連接本身的心跳機(jī)制，斷開(kāi)就直接剔除服務(wù)實(shí)例
- Nacos主動(dòng)檢查機(jī)制，服務(wù)端會(huì)對(duì)20s沒(méi)有發(fā)送數(shù)據(jù)的連接進(jìn)行檢查，出現(xiàn)異常時(shí)也會(huì)主動(dòng)斷開(kāi)連接，剔除服務(wù)實(shí)例
小總結(jié)
心跳機(jī)制僅僅針對(duì)臨時(shí)實(shí)例而言
1.x心跳機(jī)制是通過(guò)客戶(hù)端和服務(wù)端兩個(gè)定時(shí)任務(wù)來(lái)完成的，客戶(hù)端定時(shí)上報(bào)心跳信息，服務(wù)端定時(shí)檢查心跳時(shí)間，超過(guò)15s標(biāo)記不健康，超過(guò)30s直接剔除
1.x心跳機(jī)制還有類(lèi)似2.x的Redo作用，服務(wù)端發(fā)現(xiàn)心跳的服務(wù)信息不存在會(huì)，會(huì)將服務(wù)信息添加到注冊(cè)表，相當(dāng)于重新注冊(cè)了
2.x是基于gRPC長(zhǎng)連接本身的心跳機(jī)制和服務(wù)端的定時(shí)檢查機(jī)制來(lái)的，出現(xiàn)異常直接剔除
健康檢查
前面說(shuō)了，心跳機(jī)制僅僅是臨時(shí)實(shí)例用來(lái)保護(hù)的機(jī)制
而對(duì)于永久實(shí)例來(lái)說(shuō)，一般來(lái)說(shuō)無(wú)法主動(dòng)上報(bào)心跳
就比如說(shuō)MySQL實(shí)例，肯定是不會(huì)主動(dòng)上報(bào)心跳到Nacos的，所以這就導(dǎo)致無(wú)法通過(guò)心跳機(jī)制來(lái)保活
所以針對(duì)永久實(shí)例的情況，Nacos通過(guò)一種叫健康檢查的機(jī)制去判斷服務(wù)實(shí)例是否活著
健康檢查跟心跳機(jī)制剛好相反，心跳機(jī)制是服務(wù)實(shí)例向服務(wù)端發(fā)送請(qǐng)求
而所謂的健康檢查就是服務(wù)端主動(dòng)向服務(wù)實(shí)例發(fā)送請(qǐng)求，去探測(cè)服務(wù)實(shí)例是否活著
圖片
健康檢查機(jī)制在1.x和2.x的實(shí)現(xiàn)機(jī)制是一樣的
Nacos服務(wù)端在會(huì)去創(chuàng)建一個(gè)健康檢查任務(wù)，這個(gè)任務(wù)每次執(zhí)行時(shí)間間隔會(huì)在2000~7000毫秒之間
當(dāng)任務(wù)觸發(fā)的時(shí)候，會(huì)根據(jù)設(shè)置的健康檢查的方式執(zhí)行不同的邏輯，目前主要有以下三種方式：
- TCP
- HTTP
- MySQL
TCP的方式就是根據(jù)服務(wù)實(shí)例的ip和端口去判斷是否能連接成功，如果連接成功，就認(rèn)為健康，反之就任務(wù)不健康
HTTP的方式就是向服務(wù)實(shí)例的ip和端口發(fā)送一個(gè)Http請(qǐng)求，請(qǐng)求路徑是需要設(shè)置的，如果能正常請(qǐng)求，說(shuō)明實(shí)例健康，反之就不健康
MySQL的方式是一種特殊的檢查方式，他可以執(zhí)行下面這條Sql來(lái)判斷數(shù)據(jù)庫(kù)是不是主庫(kù)
圖片
默認(rèn)情況下，都是通過(guò)TCP的方式來(lái)探測(cè)服務(wù)實(shí)例是否還活著
服務(wù)發(fā)現(xiàn)
所謂的服務(wù)發(fā)現(xiàn)就是指當(dāng)有服務(wù)實(shí)例注冊(cè)成功之后，其它服務(wù)可以發(fā)現(xiàn)這些服務(wù)實(shí)例
Nacos提供了兩種發(fā)現(xiàn)方式：
- 主動(dòng)查詢(xún)
- 服務(wù)訂閱
主動(dòng)查詢(xún)就是指客戶(hù)端主動(dòng)向服務(wù)端查詢(xún)需要關(guān)注的服務(wù)實(shí)例，也就是拉（pull）的模式
服務(wù)訂閱就是指客戶(hù)端向服務(wù)端發(fā)送一個(gè)訂閱服務(wù)的請(qǐng)求，當(dāng)被訂閱的服務(wù)有信息變動(dòng)就會(huì)主動(dòng)將服務(wù)實(shí)例的信息推送給訂閱的客戶(hù)端，本質(zhì)就是推（push）模式
圖片
在我們平時(shí)使用時(shí)，一般來(lái)說(shuō)都是選擇使用訂閱的方式，這樣一旦有服務(wù)實(shí)例數(shù)據(jù)的變動(dòng)，客戶(hù)端能夠第一時(shí)間感知
并且Nacos在整合SpringCloud的時(shí)候，默認(rèn)就是使用訂閱的方式
對(duì)于這兩種服務(wù)發(fā)現(xiàn)方式，1.x和2.x版本實(shí)現(xiàn)也是不一樣
服務(wù)查詢(xún)其實(shí)兩者實(shí)現(xiàn)都很簡(jiǎn)單
1.x整體就是發(fā)送Http請(qǐng)求去查詢(xún)服務(wù)實(shí)例，2.x只不過(guò)是將Http請(qǐng)求換成了gRPC的請(qǐng)求
服務(wù)端對(duì)于查詢(xún)的處理過(guò)程都是一樣的，從服務(wù)注冊(cè)表中查出符合查詢(xún)條件的服務(wù)實(shí)例進(jìn)行返回
不過(guò)對(duì)于服務(wù)訂閱，兩者的機(jī)制就稍微復(fù)雜一點(diǎn)
在Nacos客戶(hù)端，不論是1.x還是2.x都是通過(guò)SDK中的NamingService#subscribe方法來(lái)發(fā)起訂閱的
圖片
當(dāng)有服務(wù)實(shí)例數(shù)據(jù)變動(dòng)的時(shí)，客戶(hù)端就會(huì)回調(diào)EventListener，就可以拿到最新的服務(wù)實(shí)例數(shù)據(jù)了
雖然1.x還是2.x都是同樣的方法，但是具體的實(shí)現(xiàn)邏輯是不一樣的
1.x服務(wù)訂閱實(shí)現(xiàn)
在1.x版本的時(shí)候，服務(wù)訂閱的處理邏輯大致會(huì)有以下三步：
第一步，客戶(hù)端在啟動(dòng)的時(shí)候，會(huì)去構(gòu)建一個(gè)叫PushReceiver的類(lèi)
這個(gè)類(lèi)會(huì)去創(chuàng)建一個(gè)UDP Socket，端口是隨機(jī)的
圖片
其實(shí)通過(guò)名字就可以知道這個(gè)類(lèi)的作用，就是通過(guò)UDP的方式接收服務(wù)端推送的數(shù)據(jù)的
第二步，調(diào)用NamingService#subscribe來(lái)發(fā)起訂閱時(shí)，會(huì)先去服務(wù)端查詢(xún)需要訂閱服務(wù)的所有實(shí)例信息
之后會(huì)將所有服務(wù)實(shí)例數(shù)據(jù)存到客戶(hù)端的一個(gè)內(nèi)部緩存中
圖片
并且在查詢(xún)的時(shí)候，會(huì)將這個(gè)UDP Socket的端口作為一個(gè)參數(shù)傳到服務(wù)端
服務(wù)端接收到這個(gè)UDP端口后，后續(xù)就通過(guò)這個(gè)端口給客戶(hù)端推送服務(wù)實(shí)例數(shù)據(jù)
第三步，會(huì)為這次訂閱開(kāi)啟一個(gè)不定時(shí)執(zhí)行的任務(wù)
之所以不定時(shí)，是因?yàn)檫@個(gè)當(dāng)執(zhí)行異常的時(shí)候，下次執(zhí)行的時(shí)間間隔就會(huì)變長(zhǎng)，但是最多不超過(guò)60s，正常是10s，這個(gè)10s是查詢(xún)服務(wù)實(shí)例是服務(wù)端返回的
這個(gè)任務(wù)會(huì)去從服務(wù)端查詢(xún)訂閱的服務(wù)實(shí)例信息，然后更新內(nèi)部緩存
這里你可能會(huì)有個(gè)疑問(wèn)
既然有了服務(wù)變動(dòng)推送的功能，為什么還要定時(shí)去查詢(xún)更新服務(wù)實(shí)例信息呢?
其實(shí)很簡(jiǎn)單，那就是因?yàn)閁DP通信不穩(wěn)定導(dǎo)致的
雖然有Push，但是由于UDP通信自身的不確定性，有可能會(huì)導(dǎo)致客戶(hù)端接收變動(dòng)信息失敗
所以這里就加了一個(gè)定時(shí)任務(wù)，彌補(bǔ)這種可能性，屬于一個(gè)兜底的方案。
這就是1.x版本的服務(wù)訂閱的實(shí)現(xiàn)
圖片
2.x服務(wù)訂閱的實(shí)現(xiàn)
講完1.x的版本實(shí)現(xiàn)，接下來(lái)就講一講2.x版本的實(shí)現(xiàn)
由于2.x版本換成了gRPC長(zhǎng)連接的方式，所以2.x版本服務(wù)數(shù)據(jù)變更推送已經(jīng)完全拋棄了1.x的UDP做法
當(dāng)有服務(wù)實(shí)例變動(dòng)的時(shí)候，服務(wù)端直接通過(guò)這個(gè)長(zhǎng)連接將服務(wù)信息發(fā)送給客戶(hù)端
客戶(hù)端拿到最新服務(wù)實(shí)例數(shù)據(jù)之后的處理方式就跟1.x是一樣了
除了處理方式一樣，2.x也繼承了1.x的其他的東西
比如客戶(hù)端依然會(huì)有服務(wù)實(shí)例的緩存
定時(shí)對(duì)比機(jī)制也保留了，只不過(guò)這個(gè)定時(shí)對(duì)比的機(jī)制默認(rèn)是關(guān)閉狀態(tài)
之所以默認(rèn)關(guān)閉，主要還是因?yàn)殚L(zhǎng)連接還是比較穩(wěn)定的原因
當(dāng)客戶(hù)端出現(xiàn)異常，接收不到請(qǐng)求，那么服務(wù)端會(huì)直接跟客戶(hù)端斷開(kāi)連接
當(dāng)恢復(fù)正常，由于有Redo操作，所以還是能拿到最新的實(shí)例信息的
所以2.x版本的服務(wù)訂閱功能的實(shí)現(xiàn)大致如下圖所示
圖片
這里還有個(gè)細(xì)節(jié)需要注意
在1.x版本的時(shí)候，任何服務(wù)都是可以被訂閱的
但是在2.x版本中，只支持訂閱臨時(shí)服務(wù)，對(duì)于永久服務(wù)，已經(jīng)不支持訂閱了
小總結(jié)
服務(wù)查詢(xún)1.x是通過(guò)Http請(qǐng)求；2.x通過(guò)gRPC請(qǐng)求
服務(wù)訂閱1.x是通過(guò)UDP來(lái)推送的；2.x就基于gRPC長(zhǎng)連接來(lái)實(shí)現(xiàn)的
1.x和2.x客戶(hù)端都有服務(wù)實(shí)例的緩存，也有定時(shí)對(duì)比機(jī)制，只不過(guò)1.x會(huì)自動(dòng)開(kāi)啟；2.x提供了一個(gè)開(kāi)個(gè)，可以手動(dòng)選擇是否開(kāi)啟，默認(rèn)不開(kāi)啟
數(shù)據(jù)一致性
由于Nacos是支持集群模式的，所以一定會(huì)涉及到分布式系統(tǒng)中不可避免的數(shù)據(jù)一致性問(wèn)題
1、服務(wù)實(shí)例的責(zé)任機(jī)制
再說(shuō)數(shù)據(jù)一致性問(wèn)題之前，先來(lái)討論一下服務(wù)實(shí)例的責(zé)任機(jī)制
什么是服務(wù)實(shí)例的責(zé)任機(jī)制？
比如上面提到的服務(wù)注冊(cè)、心跳管理、監(jiān)控檢查機(jī)制，當(dāng)只有一個(gè)Nacos服務(wù)時(shí)，那么自然而言這個(gè)服務(wù)會(huì)去檢查所有的服務(wù)實(shí)例的心跳時(shí)間，執(zhí)行所有服務(wù)實(shí)例的健康檢查任務(wù)
圖片
但是當(dāng)出現(xiàn)Nacos服務(wù)出現(xiàn)集群時(shí)，為了平衡各Nacos服務(wù)的壓力，Nacos會(huì)根據(jù)一定的規(guī)則讓每個(gè)Nacos服務(wù)只管理一部分服務(wù)實(shí)例的
當(dāng)然每個(gè)Nacos服務(wù)的注冊(cè)表還是全部的服務(wù)實(shí)例數(shù)據(jù)
圖片
這個(gè)管理機(jī)制我給他起了一個(gè)名字，就叫做責(zé)任機(jī)制，因?yàn)槲以?.x和2.x都提到了responsible這個(gè)單詞
本質(zhì)就是Nacos服務(wù)對(duì)哪些服務(wù)實(shí)例負(fù)有心跳監(jiān)測(cè)，健康檢查的責(zé)任。
2、CAP定理和BASE理論
談到數(shù)據(jù)一致性問(wèn)題，一定離不開(kāi)兩個(gè)著名分布式理論
- CAP定理
- BASE理論
CAP定理中，三個(gè)字母分別代表這些含義：
- C，Consistency單詞的縮寫(xiě)，代表一致性，指分布式系統(tǒng)中各個(gè)節(jié)點(diǎn)的數(shù)據(jù)保持強(qiáng)一致，也就是每個(gè)時(shí)刻都必須一樣，不一樣整個(gè)系統(tǒng)就不能對(duì)外提供服務(wù)
- A，Availability單詞的縮寫(xiě)，代表可用性，指整個(gè)分布式系統(tǒng)保持對(duì)外可用，即使從每個(gè)節(jié)點(diǎn)獲取的數(shù)據(jù)可能都不一樣，只要能獲取到就行
- P，Partition tolerance單詞的縮寫(xiě)，代表分區(qū)容錯(cuò)性。
所謂的CAP定理，就是指在一個(gè)分布式系統(tǒng)中，CAP這三個(gè)指標(biāo)，最多同時(shí)只能滿(mǎn)足其中的兩個(gè)，不可能三個(gè)都同時(shí)滿(mǎn)足
圖片
為什么三者不能同時(shí)滿(mǎn)足？
對(duì)于一個(gè)分布式系統(tǒng)，網(wǎng)絡(luò)分區(qū)是一定需要滿(mǎn)足的
而所謂分區(qū)指的是系統(tǒng)中的服務(wù)部署在不同的網(wǎng)絡(luò)區(qū)域中
圖片
比如，同一套系統(tǒng)可能同時(shí)在北京和上海都有部署，那么他們就處于不同的網(wǎng)絡(luò)分區(qū)，就可能出現(xiàn)無(wú)法互相訪(fǎng)問(wèn)的情況
當(dāng)然，你也可以把所有的服務(wù)都放在一個(gè)網(wǎng)絡(luò)分區(qū)，但是當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時(shí)，整個(gè)系統(tǒng)都無(wú)法對(duì)外提供服務(wù)，那這還有什么意義呢？
所以分布式系統(tǒng)一定需要滿(mǎn)足分區(qū)容錯(cuò)性，把系統(tǒng)部署在不同的區(qū)域網(wǎng)絡(luò)中
此時(shí)只剩下了一致性和可用性，它們?yōu)槭裁床荒芡瑫r(shí)滿(mǎn)足？
其實(shí)答案很簡(jiǎn)單，就因?yàn)榭赡艹霈F(xiàn)網(wǎng)絡(luò)分區(qū)導(dǎo)致的通信失敗。
比如說(shuō)，現(xiàn)在出現(xiàn)了網(wǎng)絡(luò)分區(qū)的問(wèn)題，上圖中的A網(wǎng)絡(luò)區(qū)域和B網(wǎng)絡(luò)區(qū)域無(wú)法相互訪(fǎng)問(wèn)
此時(shí)假設(shè)往上圖中的A網(wǎng)絡(luò)區(qū)域發(fā)送請(qǐng)求，將服務(wù)中的一個(gè)值 i 屬性設(shè)置成 1
圖片
如果保證可用性，此時(shí)由于A(yíng)和B網(wǎng)絡(luò)不通，此時(shí)只有A中的服務(wù)修改成功，B無(wú)法修改成功，此時(shí)數(shù)據(jù)AB區(qū)域數(shù)據(jù)就不一致性，也就沒(méi)有保證數(shù)據(jù)一致性
如果保證一致性，此時(shí)由于A(yíng)和B網(wǎng)絡(luò)不通，所以此時(shí)A也不能修改成功，必須修改失敗，否則就會(huì)導(dǎo)致AB數(shù)據(jù)不一致
雖然A沒(méi)修改成功，保證了數(shù)據(jù)一致性，AB還是之前相同的數(shù)據(jù)，但是此時(shí)整個(gè)系統(tǒng)已經(jīng)沒(méi)有寫(xiě)可用性了，無(wú)法成功寫(xiě)數(shù)據(jù)了。
所以從上面分析可以看出，在有分區(qū)容錯(cuò)性的前提下，可用性和一致性是無(wú)法同時(shí)保證的。
雖然無(wú)法同時(shí)一致性和可用性，但是能不能換種思路來(lái)思考一下這個(gè)問(wèn)題
首先我們可以先保證系統(tǒng)的可用性，也就是先讓系統(tǒng)能夠?qū)憯?shù)據(jù)，將A區(qū)域服務(wù)中的i修改成1
之后當(dāng)AB區(qū)域之間網(wǎng)絡(luò)恢復(fù)之后，將A區(qū)域的i值復(fù)制給B區(qū)域，這樣就能夠保證AB區(qū)域間的數(shù)據(jù)最終是一致的了
這不就皆大歡喜了么
這種思路其實(shí)就是BASE理論的核心要點(diǎn)，優(yōu)先保證可用性，數(shù)據(jù)最終達(dá)成一致性。
BASE理論主要是包括以下三點(diǎn)：
- 基本可用（Basically Available）：系統(tǒng)出現(xiàn)故障還是能夠?qū)ν馓峁┓?wù)，不至于直接無(wú)法用了
- 軟狀態(tài)（Soft State）：允許各個(gè)節(jié)點(diǎn)的數(shù)據(jù)不一致
- 最終一致性，（Eventually Consistent）：雖然允許各個(gè)節(jié)點(diǎn)的數(shù)據(jù)不一致，但是在一定時(shí)間之后，各個(gè)節(jié)點(diǎn)的數(shù)據(jù)最終需要一致的
BASE理論其實(shí)就是妥協(xié)之后的產(chǎn)物。
3、Nacos的AP和CP
Nacos其實(shí)目前是同時(shí)支持AP和CP的
具體使用AP還是CP得取決于Nacos內(nèi)部的具體功能，并不是有的文章說(shuō)的可以通過(guò)一個(gè)配置自由切換。
就以服務(wù)注冊(cè)舉例來(lái)說(shuō)，對(duì)于臨時(shí)實(shí)例來(lái)說(shuō)，Nacos會(huì)優(yōu)先保證可用性，也就是AP
對(duì)于永久實(shí)例，Nacos會(huì)優(yōu)先保證數(shù)據(jù)的一致性，也就是CP
接下來(lái)我們就來(lái)講一講Nacos的CP和AP的實(shí)現(xiàn)原理
3.1、Nacos的AP實(shí)現(xiàn)
對(duì)于A(yíng)P來(lái)說(shuō)，Nacos使用的是阿里自研的Distro協(xié)議
在這個(gè)協(xié)議中，每個(gè)服務(wù)端節(jié)點(diǎn)是一個(gè)平等的狀態(tài)，每個(gè)服務(wù)端節(jié)點(diǎn)正常情況下數(shù)據(jù)是一樣的，每個(gè)服務(wù)端節(jié)點(diǎn)都可以接收來(lái)自客戶(hù)端的讀寫(xiě)請(qǐng)求
圖片
當(dāng)某個(gè)節(jié)點(diǎn)剛啟動(dòng)時(shí)，他會(huì)向集群中的某個(gè)節(jié)點(diǎn)發(fā)送請(qǐng)求，拉取所有的服務(wù)實(shí)例數(shù)據(jù)到自己的服務(wù)注冊(cè)表中
圖片
這樣其它客戶(hù)端就可以從這個(gè)服務(wù)節(jié)點(diǎn)中獲取到服務(wù)實(shí)例數(shù)據(jù)了
當(dāng)某個(gè)服務(wù)端節(jié)點(diǎn)接收到注冊(cè)臨時(shí)服務(wù)實(shí)例的請(qǐng)求，不僅僅會(huì)將這個(gè)服務(wù)實(shí)例存到自身的服務(wù)注冊(cè)表，同時(shí)也會(huì)向其它所有服務(wù)節(jié)點(diǎn)發(fā)送請(qǐng)求，將這個(gè)服務(wù)數(shù)據(jù)同步到其它所有節(jié)點(diǎn)
圖片
所以此時(shí)從任意一個(gè)節(jié)點(diǎn)都是可以獲取到所有的服務(wù)實(shí)例數(shù)據(jù)的。
即使數(shù)據(jù)同步的過(guò)程發(fā)生異常，服務(wù)實(shí)例也成功注冊(cè)到一個(gè)Nacos服務(wù)中，對(duì)外部而言，整個(gè)Nacos集群是可用的，也就達(dá)到了AP的效果
同時(shí)為了滿(mǎn)足BASE理論，Nacos也有下面兩種機(jī)制保證最終節(jié)點(diǎn)間數(shù)據(jù)最終是一致的：
- 失敗重試機(jī)制
- 定時(shí)對(duì)比機(jī)制
失敗重試機(jī)制是指當(dāng)數(shù)據(jù)同步給其它節(jié)點(diǎn)失敗時(shí)，會(huì)每隔3s重試一次，直到成功
定時(shí)對(duì)比機(jī)制就是指，每個(gè)Nacos服務(wù)節(jié)點(diǎn)會(huì)定時(shí)向所有的其它服務(wù)節(jié)點(diǎn)發(fā)送一些認(rèn)證的請(qǐng)求
這個(gè)請(qǐng)求會(huì)告訴每個(gè)服務(wù)節(jié)點(diǎn)自己負(fù)責(zé)的服務(wù)實(shí)例的對(duì)應(yīng)的版本號(hào)，這個(gè)版本號(hào)隨著服務(wù)實(shí)例的變動(dòng)就會(huì)變動(dòng)
如果其它服務(wù)節(jié)點(diǎn)的數(shù)據(jù)的版本號(hào)跟自己的對(duì)不上，那就說(shuō)明其它服務(wù)節(jié)點(diǎn)的數(shù)據(jù)不是最新的
此時(shí)這個(gè)Nacos服務(wù)節(jié)點(diǎn)就會(huì)將自己負(fù)責(zé)的服務(wù)實(shí)例數(shù)據(jù)發(fā)給不是最新數(shù)據(jù)的節(jié)點(diǎn)，這樣就保證了每個(gè)節(jié)點(diǎn)的數(shù)據(jù)是一樣的了。
3.2、Nacos的CP實(shí)現(xiàn)
Nacos的CP實(shí)現(xiàn)是基于Raft算法來(lái)實(shí)現(xiàn)的
在1.x版本早期，Nacos是自己手動(dòng)實(shí)現(xiàn)Raft算法
在2.x版本，Nacos移除了手動(dòng)實(shí)現(xiàn)Raft算法，轉(zhuǎn)而擁抱基于螞蟻開(kāi)源的JRaft框架
在Raft算法，每個(gè)節(jié)點(diǎn)主要有三個(gè)狀態(tài)
- Leader，負(fù)責(zé)所有的讀寫(xiě)請(qǐng)求，一個(gè)集群只有一個(gè)
- Follower，從節(jié)點(diǎn)，主要是負(fù)責(zé)復(fù)制Leader的數(shù)據(jù)，保證數(shù)據(jù)的一致性
- Candidate，候選節(jié)點(diǎn)，最終會(huì)變成Leader或者Follower
集群?jiǎn)?dòng)時(shí)都是節(jié)點(diǎn)Follower，經(jīng)過(guò)一段時(shí)間會(huì)轉(zhuǎn)換成Candidate狀態(tài)，再經(jīng)過(guò)一系列復(fù)雜的選擇算法，選出一個(gè)Leader
圖片
這個(gè)選舉算法比較復(fù)雜，完全值得另寫(xiě)一篇文章，這里就不細(xì)說(shuō)了。不過(guò)立個(gè)flag，如果本篇文章點(diǎn)贊量超過(guò)28個(gè)，我連夜爆肝，再來(lái)一篇。
當(dāng)有寫(xiě)請(qǐng)求時(shí)，如果請(qǐng)求的節(jié)點(diǎn)不是Leader節(jié)點(diǎn)時(shí)，會(huì)將請(qǐng)求轉(zhuǎn)給Leader節(jié)點(diǎn)，由Leader節(jié)點(diǎn)處理寫(xiě)請(qǐng)求
比如，有個(gè)客戶(hù)端連到的上圖中的Nacos服務(wù)2節(jié)點(diǎn)，之后向Nacos服務(wù)2注冊(cè)服務(wù)
Nacos服務(wù)2接收到請(qǐng)求之后，會(huì)判斷自己是不是Leader節(jié)點(diǎn)，發(fā)現(xiàn)自己不是
此時(shí)Nacos服務(wù)2就會(huì)向Leader節(jié)點(diǎn)發(fā)送請(qǐng)求，Leader節(jié)點(diǎn)接收到請(qǐng)求之后，會(huì)處理服務(wù)注冊(cè)的過(guò)程
為什么說(shuō)Raft是保證CP的呢？
主要是因?yàn)镽aft在處理寫(xiě)的時(shí)候有一個(gè)判斷過(guò)程
- 首先，Leader在處理寫(xiě)請(qǐng)求時(shí)，不會(huì)直接數(shù)據(jù)應(yīng)用到自己的系統(tǒng)，而是先向所有的Follower發(fā)送請(qǐng)求，讓他們先處理這個(gè)請(qǐng)求
- 當(dāng)超過(guò)半數(shù)的Follower成功處理了這個(gè)寫(xiě)請(qǐng)求之后，Leader才會(huì)寫(xiě)數(shù)據(jù)，并返回給客戶(hù)端請(qǐng)求處理成功
- 如果超過(guò)一定時(shí)間未收到超過(guò)半數(shù)處理成功Follower的信號(hào)，此時(shí)Leader認(rèn)為這次寫(xiě)數(shù)據(jù)是失敗的，就不會(huì)處理寫(xiě)請(qǐng)求，直接返回給客戶(hù)端請(qǐng)求失敗
所以，一旦發(fā)生故障，導(dǎo)致接收不到半數(shù)的Follower寫(xiě)成功的響應(yīng)，整個(gè)集群就直接寫(xiě)失敗，這就很符合CP的概念了。
不過(guò)這里還有一個(gè)小細(xì)節(jié)需要注意
Nacos在處理查詢(xún)服務(wù)實(shí)例的請(qǐng)求直接時(shí)，并不會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給Leader節(jié)點(diǎn)處理，而是直接查當(dāng)前Nacos服務(wù)實(shí)例的注冊(cè)表
這其實(shí)就會(huì)引發(fā)一個(gè)問(wèn)題
如果客戶(hù)端查詢(xún)的Follower節(jié)點(diǎn)沒(méi)有及時(shí)處理Leader同步過(guò)來(lái)的寫(xiě)請(qǐng)求（過(guò)半響應(yīng)的節(jié)點(diǎn)中不包括這個(gè)節(jié)點(diǎn)），此時(shí)在這個(gè)Follower其實(shí)是查不到最新的數(shù)據(jù)的，這就會(huì)導(dǎo)致數(shù)據(jù)的不一致
所以說(shuō)，雖然Raft協(xié)議規(guī)定要求從Leader節(jié)點(diǎn)查最新的數(shù)據(jù)，但是Nacos至少在讀服務(wù)實(shí)例數(shù)據(jù)時(shí)并沒(méi)有遵守這個(gè)協(xié)議
當(dāng)然對(duì)于其它的一些數(shù)據(jù)的讀寫(xiě)請(qǐng)求有的還是遵守了這個(gè)協(xié)議。
JRaft對(duì)于讀請(qǐng)求其實(shí)是做了很多優(yōu)化的，其實(shí)從Follower節(jié)點(diǎn)通過(guò)一定的機(jī)制也是能夠保證讀到最新的數(shù)據(jù)
數(shù)據(jù)模型
在Nacos中，一個(gè)服務(wù)的確定是由三部分信息確定
- 命名空間（Namespace）：多租戶(hù)隔離用的，默認(rèn)是public
- 分組（Group）：這個(gè)其實(shí)可以用來(lái)做環(huán)境隔離，服務(wù)注冊(cè)時(shí)可以指定服務(wù)的分組，比如是測(cè)試環(huán)境或者是開(kāi)發(fā)環(huán)境，默認(rèn)是DEFAULT_GROUP
- 服務(wù)名（ServiceName）：這個(gè)就不用多說(shuō)了
通過(guò)上面三者就可以確定同一個(gè)服務(wù)了
在服務(wù)注冊(cè)和訂閱的時(shí)候，必須要指定上述三部分信息，如果不指定，Nacos就會(huì)提供默認(rèn)的信息
不過(guò)，在Nacos中，在服務(wù)里面其實(shí)還是有一個(gè)集群的概念
圖片
在服務(wù)注冊(cè)的時(shí)候，可以指定這個(gè)服務(wù)實(shí)例在哪個(gè)集體的集群中，默認(rèn)是在DEFAULT集群下
在SpringCloud環(huán)境底下可以通過(guò)如下配置去設(shè)置
spring
cloud:
nacos:
discovery:
cluster-name: sanyoujavaCluster在服務(wù)訂閱的時(shí)候，可以指定訂閱哪些集群下的服務(wù)實(shí)例
當(dāng)然，也可以不指定，如果不指定話(huà)，默認(rèn)就是訂閱這個(gè)服務(wù)下的所有集群的服務(wù)實(shí)例
我們?nèi)粘Ｊ褂弥锌梢詫⒉渴鹪谙嗤瑓^(qū)域的服務(wù)劃分為同一個(gè)集群，比如杭州屬于一個(gè)集群，上海屬于一個(gè)集群
這樣服務(wù)調(diào)用的時(shí)候，就可以?xún)?yōu)先使用同一個(gè)地區(qū)的服務(wù)了，比跨區(qū)域調(diào)用速度更快。
新聞名稱(chēng)：萬(wàn)字+20張圖探秘Nacos注冊(cè)中心核心實(shí)現(xiàn)原理
標(biāo)題網(wǎng)址：http://m.fisionsoft.com.cn/article/cddhgih.html
