K60至尊版剛預(yù)熱 一加Ace2 Pro正面硬剛
Redmi這邊剛?cè)缁鹑巛钡男麄髁薑60 Ultra的各種技術(shù)和硬件配置，作為競(jìng)品的一加也坐不住了。一加中國(guó)區(qū)總裁李杰發(fā)布了兩條微博，表示在自家的一加Ace2上早就已經(jīng)采用了和PixelWo
大家好，我是三友~~
今天就應(yīng)某位小伙伴的要求，來講一講Nacos作為服務(wù)注冊(cè)中心底層的實(shí)現(xiàn)原理
不知你是否跟我一樣，在使用Nacos時(shí)有以下幾點(diǎn)疑問：
本文就通過探討上述問題來探秘Nacos服務(wù)注冊(cè)中心核心的底層實(shí)現(xiàn)原理。
雖然Nacos最新版本已經(jīng)到了2.x版本，但是為了照顧那些還在用1.x版本的同學(xué)，所以本文我會(huì)同時(shí)去講1.x版本和2.x版本的實(shí)現(xiàn)
觀前提醒，本文又又又是一篇超長(zhǎng)的干貨，非常適合一鍵三連~~
臨時(shí)實(shí)例和永久實(shí)例在Nacos中是一個(gè)非常非常重要的概念
之所以說它重要，主要是因?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ì)持久化到磁盤
這個(gè)服務(wù)端內(nèi)部的緩存在注冊(cè)中心屆一般被稱為服務(wù)注冊(cè)表
當(dāng)服務(wù)實(shí)例出現(xiàn)異?；蛘呦戮€之后，就會(huì)把這個(gè)服務(wù)實(shí)例從服務(wù)注冊(cè)表中剔除
永久實(shí)例
永久服務(wù)實(shí)例不僅僅會(huì)存在服務(wù)注冊(cè)表中，同時(shí)也會(huì)被持久化到磁盤文件中
當(dāng)服務(wù)實(shí)例出現(xiàn)異?；蛘呦戮€，Nacos只會(huì)將服務(wù)實(shí)例的健康狀態(tài)設(shè)置為不健康，并不會(huì)對(duì)將其從服務(wù)注冊(cè)表中剔除
所以這個(gè)服務(wù)實(shí)例的信息你還是可以從注冊(cè)中心看到，只不過處于不健康狀態(tài)
這是就是兩者最最最基本的區(qū)別
當(dāng)然除了上述最基本的區(qū)別之外，兩者還有很多其它的區(qū)別，接下來本文還會(huì)提到
這里你可能會(huì)有一個(gè)疑問
為什么Nacos要將服務(wù)實(shí)例分為臨時(shí)實(shí)例和永久實(shí)例?
主要還是因?yàn)閼?yīng)用場(chǎng)景不同
臨時(shí)實(shí)例就比較適合于業(yè)務(wù)服務(wù)，服務(wù)下線之后可以不需要在注冊(cè)中心中查看到
永久實(shí)例就比較適合需要運(yùn)維的服務(wù)，這種服務(wù)幾乎是永久存在的，比如說MySQL、Redis等等
MySQL、Redis等服務(wù)實(shí)例可以通過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í)例，可以通過下面這個(gè)配置項(xiàng)來完成
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可以說是臨時(shí)服務(wù)和永久服務(wù)
圖片
為什么2.x把臨時(shí)還是永久的屬性由實(shí)例本身決定改成了由服務(wù)決定?
其實(shí)很簡(jiǎn)單，你想想，假設(shè)對(duì)一個(gè)MySQL服務(wù)來說，它的每個(gè)服務(wù)實(shí)例肯定都是永久的，不會(huì)出現(xiàn)一些是永久的，一些是臨時(shí)的情況吧
所以臨時(shí)還是永久的屬性由服務(wù)本身決定其實(shí)就更加合理了
作為一個(gè)服務(wù)注冊(cè)中心，服務(wù)注冊(cè)肯定是一個(gè)非常重要的功能
所謂的服務(wù)注冊(cè)，就是通過注冊(cè)中心提供的客戶端SDK（或者是控制臺(tái)）將服務(wù)本身的一些元信息，比如ip、端口等信息發(fā)送到注冊(cè)中心服務(wù)端
服務(wù)端在接收到服務(wù)之后，會(huì)將服務(wù)的信息保存到前面提到的服務(wù)注冊(cè)表中
在Nacos在1.x版本的時(shí)候，服務(wù)注冊(cè)是通過Http接口實(shí)現(xiàn)的
圖片
代碼如下
圖片
整個(gè)邏輯比較簡(jiǎn)單，因?yàn)镹acos服務(wù)端本身就是用SpringBoot寫的
但是在2.x版本的實(shí)現(xiàn)就比較復(fù)雜了
2.x版本相比于1.x版本最主要的升級(jí)就是客戶端和服務(wù)端通信協(xié)議的改變，由1.x版本的Http改成了2.x版本gRPC
gRPC是谷歌公司開發(fā)的一個(gè)高性能、開源和通用的RPC框架，Java版本的實(shí)現(xiàn)底層也是基于Netty來的
之所以改成了gRPC，主要是因?yàn)镠ttp請(qǐng)求會(huì)頻繁創(chuàng)建和銷毀連接，白白浪費(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ù)端
Nacos客戶端在啟動(dòng)的時(shí)候，會(huì)通過gRPC跟服務(wù)端建立長(zhǎng)連接
圖片
這個(gè)連接會(huì)一直存在，之后客戶端與服務(wù)端所有的通信都是基于這個(gè)長(zhǎng)連接來的
當(dāng)客戶端發(fā)起注冊(cè)的時(shí)候，就會(huì)通過這個(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ǔ)到客戶端中的一個(gè)緩存中，供Redo操作
所謂的Redo操作，其實(shí)就是一個(gè)補(bǔ)償機(jī)制，本質(zhì)是個(gè)定時(shí)任務(wù)，默認(rèn)每3s執(zhí)行一次
這個(gè)定時(shí)任務(wù)作用是，當(dāng)客戶端與服務(wù)端重新建立連接時(shí)（因?yàn)橐恍┊惓Ｔ驅(qū)е逻B接斷開）
那么之前注冊(cè)的服務(wù)實(shí)例肯定還要繼續(xù)注冊(cè)服務(wù)端（斷開連接服務(wù)實(shí)例就會(huì)被剔除服務(wù)注冊(cè)表）
所以這個(gè)Redo操作一個(gè)很重要的作用就是重連之后的重新注冊(cè)的作用
除了注冊(cè)之外，比如服務(wù)訂閱之類的操作也需要Redo操作，當(dāng)連接重新建立，之前客戶端的操作都需要Redo一下
1.x版本是通過Http協(xié)議來進(jìn)行服務(wù)注冊(cè)的
2.x由于客戶端與服務(wù)端的通信改成了gRPC長(zhǎng)連接，所以改成通過gRPC長(zhǎng)連接來注冊(cè)
2.x比1.x多個(gè)Redo操作，當(dāng)注冊(cè)的服務(wù)實(shí)例是臨時(shí)實(shí)例是，出現(xiàn)網(wǎng)絡(luò)異常，連接重新建立之后，客戶端需要將服務(wù)注冊(cè)、服務(wù)訂閱之類的操作進(jìn)行重做
這里你可能會(huì)有個(gè)疑問
既然2.x有Redo機(jī)制保證客戶端與服務(wù)端通信正常之后重新注冊(cè)，那么1.x有類似的這種Redo機(jī)制么？
當(dāng)然也會(huì)有，接下往下看。
心跳機(jī)制，也可以被稱為保活機(jī)制，它的作用就是服務(wù)實(shí)例告訴注冊(cè)中心我這個(gè)服務(wù)實(shí)例還活著
圖片
在正常情況下，服務(wù)關(guān)閉了，那么服務(wù)會(huì)主動(dòng)向Nacos服務(wù)端發(fā)送一個(gè)服務(wù)下線的請(qǐng)求
Nacos服務(wù)端在接收到請(qǐng)求之后，會(huì)將這個(gè)服務(wù)實(shí)例從服務(wù)注冊(cè)表中剔除
但是對(duì)于異常情況下，比如出現(xiàn)網(wǎng)絡(luò)問題，可能導(dǎo)致這個(gè)注冊(cè)的服務(wù)實(shí)例無法提供服務(wù)，處于不可用狀態(tài)，也就是不健康
而此時(shí)在沒有任何機(jī)制的情況下，服務(wù)端是無法知道這個(gè)服務(wù)處于不可用狀態(tài)
所以為了避免這種情況，一些注冊(cè)中心，就比如Nacos、Eureka，就會(huì)用心跳機(jī)制來判斷這個(gè)服務(wù)實(shí)例是否能正常
在Nacos中，心跳機(jī)制僅僅是針對(duì)臨時(shí)實(shí)例來說的，臨時(shí)實(shí)例需要靠心跳機(jī)制來?；?span style="display:none">CxT28資訊網(wǎng)——每日最新資訊28at.com
心跳機(jī)制在1.x和2.x版本的實(shí)現(xiàn)也是不一樣的
在1.x中，心跳機(jī)制實(shí)現(xiàn)是通過客戶端和服務(wù)端各存在的一個(gè)定時(shí)任務(wù)來完成的
在服務(wù)注冊(cè)時(shí)，發(fā)現(xiàn)是臨時(shí)實(shí)例，客戶端會(huì)開啟一個(gè)5s執(zhí)行一次的定時(shí)任務(wù)
圖片
這個(gè)定時(shí)任務(wù)會(huì)構(gòu)建一個(gè)Http請(qǐng)求，攜帶這個(gè)服務(wù)實(shí)例的信息，然后發(fā)送到服務(wù)端
圖片
在Nacos服務(wù)端也會(huì)開啟一個(gè)定時(shí)任務(wù)，默認(rèn)也是5s執(zhí)行一次，去檢查這些服務(wù)實(shí)例最后一次心跳的時(shí)間，也就是客戶端最后一次發(fā)送Http請(qǐng)求的時(shí)間
圖片
這就是1.x版本的心跳機(jī)制，本質(zhì)就是兩個(gè)定時(shí)任務(wù)
其實(shí)1.x的這個(gè)心跳還有一個(gè)作用，就是跟上一節(jié)說的gRPC時(shí)Redo操作的作用是一樣的
服務(wù)在處理心跳的時(shí)候，發(fā)現(xiàn)心跳攜帶這個(gè)服務(wù)實(shí)例的信息在注冊(cè)表中沒有，此時(shí)就會(huì)添加到服務(wù)注冊(cè)表
所以心跳也有Redo的類似效果
在2.x版本之后，由于通信協(xié)議改成了gRPC，客戶端與服務(wù)端保持長(zhǎng)連接，所以2.x版本之后它是利用這個(gè)gRPC長(zhǎng)連接本身的心跳來?；?span style="display:none">CxT28資訊網(wǎng)——每日最新資訊28at.com
一旦這個(gè)連接斷開，服務(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ì)去檢查超過20s沒有發(fā)送請(qǐng)求數(shù)據(jù)的連接
一旦發(fā)現(xiàn)有連接已經(jīng)超過20s沒發(fā)送請(qǐng)求，那么就會(huì)向這個(gè)連接對(duì)應(yīng)的客戶端發(fā)送一個(gè)請(qǐng)求
如果請(qǐng)求不通或者響應(yīng)失敗，此時(shí)服務(wù)端也會(huì)認(rèn)為與客戶端的這個(gè)連接異常，從而將這個(gè)客戶端注冊(cè)的服務(wù)實(shí)例從服務(wù)注冊(cè)表中剔除
所以對(duì)于2.x版本，主要是兩種機(jī)制來進(jìn)行?；睿?span style="display:none">CxT28資訊網(wǎng)——每日最新資訊28at.com
心跳機(jī)制僅僅針對(duì)臨時(shí)實(shí)例而言
1.x心跳機(jī)制是通過客戶端和服務(wù)端兩個(gè)定時(shí)任務(wù)來完成的，客戶端定時(shí)上報(bào)心跳信息，服務(wù)端定時(shí)檢查心跳時(shí)間，超過15s標(biāo)記不健康，超過30s直接剔除
1.x心跳機(jī)制還有類似2.x的Redo作用，服務(wù)端發(fā)現(xiàn)心跳的服務(wù)信息不存在會(huì)，會(huì)將服務(wù)信息添加到注冊(cè)表，相當(dāng)于重新注冊(cè)了
2.x是基于gRPC長(zhǎng)連接本身的心跳機(jī)制和服務(wù)端的定時(shí)檢查機(jī)制來的，出現(xiàn)異常直接剔除
前面說了，心跳機(jī)制僅僅是臨時(shí)實(shí)例用來保護(hù)的機(jī)制
而對(duì)于永久實(shí)例來說，一般來說無法主動(dòng)上報(bào)心跳
就比如說MySQL實(shí)例，肯定是不會(huì)主動(dòng)上報(bào)心跳到Nacos的，所以這就導(dǎo)致無法通過心跳機(jī)制來?；?span style="display:none">CxT28資訊網(wǎng)——每日最新資訊28at.com
所以針對(duì)永久實(shí)例的情況，Nacos通過一種叫健康檢查的機(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的方式就是根據(jù)服務(wù)實(shí)例的ip和端口去判斷是否能連接成功，如果連接成功，就認(rèn)為健康，反之就任務(wù)不健康
HTTP的方式就是向服務(wù)實(shí)例的ip和端口發(fā)送一個(gè)Http請(qǐng)求，請(qǐng)求路徑是需要設(shè)置的，如果能正常請(qǐng)求，說明實(shí)例健康，反之就不健康
MySQL的方式是一種特殊的檢查方式，他可以執(zhí)行下面這條Sql來判斷數(shù)據(jù)庫是不是主庫
圖片
默認(rèn)情況下，都是通過TCP的方式來探測(cè)服務(wù)實(shí)例是否還活著
所謂的服務(wù)發(fā)現(xiàn)就是指當(dāng)有服務(wù)實(shí)例注冊(cè)成功之后，其它服務(wù)可以發(fā)現(xiàn)這些服務(wù)實(shí)例
Nacos提供了兩種發(fā)現(xiàn)方式：
主動(dòng)查詢就是指客戶端主動(dòng)向服務(wù)端查詢需要關(guān)注的服務(wù)實(shí)例，也就是拉（pull）的模式
服務(wù)訂閱就是指客戶端向服務(wù)端發(fā)送一個(gè)訂閱服務(wù)的請(qǐng)求，當(dāng)被訂閱的服務(wù)有信息變動(dòng)就會(huì)主動(dòng)將服務(wù)實(shí)例的信息推送給訂閱的客戶端，本質(zhì)就是推（push）模式
圖片
在我們平時(shí)使用時(shí)，一般來說都是選擇使用訂閱的方式，這樣一旦有服務(wù)實(shí)例數(shù)據(jù)的變動(dòng)，客戶端能夠第一時(shí)間感知
并且Nacos在整合SpringCloud的時(shí)候，默認(rèn)就是使用訂閱的方式
對(duì)于這兩種服務(wù)發(fā)現(xiàn)方式，1.x和2.x版本實(shí)現(xiàn)也是不一樣
服務(wù)查詢其實(shí)兩者實(shí)現(xiàn)都很簡(jiǎn)單
1.x整體就是發(fā)送Http請(qǐng)求去查詢服務(wù)實(shí)例，2.x只不過是將Http請(qǐng)求換成了gRPC的請(qǐng)求
服務(wù)端對(duì)于查詢的處理過程都是一樣的，從服務(wù)注冊(cè)表中查出符合查詢條件的服務(wù)實(shí)例進(jìn)行返回
不過對(duì)于服務(wù)訂閱，兩者的機(jī)制就稍微復(fù)雜一點(diǎn)
在Nacos客戶端，不論是1.x還是2.x都是通過SDK中的NamingService#subscribe方法來發(fā)起訂閱的
圖片
當(dāng)有服務(wù)實(shí)例數(shù)據(jù)變動(dòng)的時(shí)，客戶端就會(huì)回調(diào)EventListener，就可以拿到最新的服務(wù)實(shí)例數(shù)據(jù)了
雖然1.x還是2.x都是同樣的方法，但是具體的實(shí)現(xiàn)邏輯是不一樣的
在1.x版本的時(shí)候，服務(wù)訂閱的處理邏輯大致會(huì)有以下三步：
第一步，客戶端在啟動(dòng)的時(shí)候，會(huì)去構(gòu)建一個(gè)叫PushReceiver的類
這個(gè)類會(huì)去創(chuàng)建一個(gè)UDP Socket，端口是隨機(jī)的
圖片
其實(shí)通過名字就可以知道這個(gè)類的作用，就是通過UDP的方式接收服務(wù)端推送的數(shù)據(jù)的
第二步，調(diào)用NamingService#subscribe來發(fā)起訂閱時(shí)，會(huì)先去服務(wù)端查詢需要訂閱服務(wù)的所有實(shí)例信息
之后會(huì)將所有服務(wù)實(shí)例數(shù)據(jù)存到客戶端的一個(gè)內(nèi)部緩存中
圖片
并且在查詢的時(shí)候，會(huì)將這個(gè)UDP Socket的端口作為一個(gè)參數(shù)傳到服務(wù)端
服務(wù)端接收到這個(gè)UDP端口后，后續(xù)就通過這個(gè)端口給客戶端推送服務(wù)實(shí)例數(shù)據(jù)
第三步，會(huì)為這次訂閱開啟一個(gè)不定時(shí)執(zhí)行的任務(wù)
之所以不定時(shí)，是因?yàn)檫@個(gè)當(dāng)執(zhí)行異常的時(shí)候，下次執(zhí)行的時(shí)間間隔就會(huì)變長(zhǎng)，但是最多不超過60s，正常是10s，這個(gè)10s是查詢服務(wù)實(shí)例是服務(wù)端返回的
這個(gè)任務(wù)會(huì)去從服務(wù)端查詢訂閱的服務(wù)實(shí)例信息，然后更新內(nèi)部緩存
這里你可能會(huì)有個(gè)疑問
既然有了服務(wù)變動(dòng)推送的功能，為什么還要定時(shí)去查詢更新服務(wù)實(shí)例信息呢?
其實(shí)很簡(jiǎn)單，那就是因?yàn)閁DP通信不穩(wěn)定導(dǎo)致的
雖然有Push，但是由于UDP通信自身的不確定性，有可能會(huì)導(dǎo)致客戶端接收變動(dòng)信息失敗
所以這里就加了一個(gè)定時(shí)任務(wù)，彌補(bǔ)這種可能性，屬于一個(gè)兜底的方案。
這就是1.x版本的服務(wù)訂閱的實(shí)現(xiàn)
圖片
講完1.x的版本實(shí)現(xiàn)，接下來就講一講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ù)端直接通過這個(gè)長(zhǎng)連接將服務(wù)信息發(fā)送給客戶端
客戶端拿到最新服務(wù)實(shí)例數(shù)據(jù)之后的處理方式就跟1.x是一樣了
除了處理方式一樣，2.x也繼承了1.x的其他的東西
比如客戶端依然會(huì)有服務(wù)實(shí)例的緩存
定時(shí)對(duì)比機(jī)制也保留了，只不過這個(gè)定時(shí)對(duì)比的機(jī)制默認(rèn)是關(guān)閉狀態(tài)
之所以默認(rèn)關(guān)閉，主要還是因?yàn)殚L(zhǎng)連接還是比較穩(wěn)定的原因
當(dāng)客戶端出現(xiàn)異常，接收不到請(qǐng)求，那么服務(wù)端會(huì)直接跟客戶端斷開連接
當(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)不支持訂閱了
服務(wù)查詢1.x是通過Http請(qǐng)求；2.x通過gRPC請(qǐng)求
服務(wù)訂閱1.x是通過UDP來推送的；2.x就基于gRPC長(zhǎng)連接來實(shí)現(xiàn)的
1.x和2.x客戶端都有服務(wù)實(shí)例的緩存，也有定時(shí)對(duì)比機(jī)制，只不過1.x會(huì)自動(dòng)開啟；2.x提供了一個(gè)開個(gè)，可以手動(dòng)選擇是否開啟，默認(rèn)不開啟
由于Nacos是支持集群模式的，所以一定會(huì)涉及到分布式系統(tǒng)中不可避免的數(shù)據(jù)一致性問題
再說數(shù)據(jù)一致性問題之前，先來討論一下服務(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é)任。
談到數(shù)據(jù)一致性問題，一定離不開兩個(gè)著名分布式理論
CAP定理中，三個(gè)字母分別代表這些含義：
所謂的CAP定理，就是指在一個(gè)分布式系統(tǒng)中，CAP這三個(gè)指標(biāo)，最多同時(shí)只能滿足其中的兩個(gè)，不可能三個(gè)都同時(shí)滿足
圖片
為什么三者不能同時(shí)滿足？
對(duì)于一個(gè)分布式系統(tǒng)，網(wǎng)絡(luò)分區(qū)是一定需要滿足的
而所謂分區(qū)指的是系統(tǒng)中的服務(wù)部署在不同的網(wǎng)絡(luò)區(qū)域中
圖片
比如，同一套系統(tǒng)可能同時(shí)在北京和上海都有部署，那么他們就處于不同的網(wǎng)絡(luò)分區(qū)，就可能出現(xiàn)無法互相訪問的情況
當(dāng)然，你也可以把所有的服務(wù)都放在一個(gè)網(wǎng)絡(luò)分區(qū)，但是當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時(shí)，整個(gè)系統(tǒng)都無法對(duì)外提供服務(wù)，那這還有什么意義呢？
所以分布式系統(tǒng)一定需要滿足分區(qū)容錯(cuò)性，把系統(tǒng)部署在不同的區(qū)域網(wǎng)絡(luò)中
此時(shí)只剩下了一致性和可用性，它們?yōu)槭裁床荒芡瑫r(shí)滿足？
其實(shí)答案很簡(jiǎn)單，就因?yàn)榭赡艹霈F(xiàn)網(wǎng)絡(luò)分區(qū)導(dǎo)致的通信失敗。
比如說，現(xiàn)在出現(xiàn)了網(wǎng)絡(luò)分區(qū)的問題，上圖中的A網(wǎng)絡(luò)區(qū)域和B網(wǎng)絡(luò)區(qū)域無法相互訪問
此時(shí)假設(shè)往上圖中的A網(wǎng)絡(luò)區(qū)域發(fā)送請(qǐng)求，將服務(wù)中的一個(gè)值 i 屬性設(shè)置成 1
圖片
如果保證可用性，此時(shí)由于A和B網(wǎng)絡(luò)不通，此時(shí)只有A中的服務(wù)修改成功，B無法修改成功，此時(shí)數(shù)據(jù)AB區(qū)域數(shù)據(jù)就不一致性，也就沒有保證數(shù)據(jù)一致性
如果保證一致性，此時(shí)由于A和B網(wǎng)絡(luò)不通，所以此時(shí)A也不能修改成功，必須修改失敗，否則就會(huì)導(dǎo)致AB數(shù)據(jù)不一致
雖然A沒修改成功，保證了數(shù)據(jù)一致性，AB還是之前相同的數(shù)據(jù)，但是此時(shí)整個(gè)系統(tǒng)已經(jīng)沒有寫可用性了，無法成功寫數(shù)據(jù)了。
所以從上面分析可以看出，在有分區(qū)容錯(cuò)性的前提下，可用性和一致性是無法同時(shí)保證的。
雖然無法同時(shí)一致性和可用性，但是能不能換種思路來思考一下這個(gè)問題
首先我們可以先保證系統(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)：
BASE理論其實(shí)就是妥協(xié)之后的產(chǎn)物。
Nacos其實(shí)目前是同時(shí)支持AP和CP的
具體使用AP還是CP得取決于Nacos內(nèi)部的具體功能，并不是有的文章說的可以通過一個(gè)配置自由切換。
就以服務(wù)注冊(cè)舉例來說，對(duì)于臨時(shí)實(shí)例來說，Nacos會(huì)優(yōu)先保證可用性，也就是AP
對(duì)于永久實(shí)例，Nacos會(huì)優(yōu)先保證數(shù)據(jù)的一致性，也就是CP
接下來我們就來講一講Nacos的CP和AP的實(shí)現(xiàn)原理
對(duì)于AP來說，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)都可以接收來自客戶端的讀寫請(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è)表中
圖片
這樣其它客戶端就可以從這個(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ù)同步的過程發(fā)生異常，服務(wù)實(shí)例也成功注冊(cè)到一個(gè)Nacos服務(wù)中，對(duì)外部而言，整個(gè)Nacos集群是可用的，也就達(dá)到了AP的效果
同時(shí)為了滿足BASE理論，Nacos也有下面兩種機(jī)制保證最終節(jié)點(diǎn)間數(shù)據(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ì)不上，那就說明其它服務(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ù)是一樣的了。
Nacos的CP實(shí)現(xiàn)是基于Raft算法來實(shí)現(xiàn)的
在1.x版本早期，Nacos是自己手動(dòng)實(shí)現(xiàn)Raft算法
在2.x版本，Nacos移除了手動(dòng)實(shí)現(xiàn)Raft算法，轉(zhuǎn)而擁抱基于螞蟻開源的JRaft框架
在Raft算法，每個(gè)節(jié)點(diǎn)主要有三個(gè)狀態(tài)
集群?jiǎn)?dòng)時(shí)都是節(jié)點(diǎn)Follower，經(jīng)過一段時(shí)間會(huì)轉(zhuǎn)換成Candidate狀態(tài)，再經(jīng)過一系列復(fù)雜的選擇算法，選出一個(gè)Leader
圖片
這個(gè)選舉算法比較復(fù)雜，完全值得另寫一篇文章，這里就不細(xì)說了。不過立個(gè)flag，如果本篇文章點(diǎn)贊量超過28個(gè)，我連夜爆肝，再來一篇。
當(dāng)有寫請(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)處理寫請(qǐng)求
比如，有個(gè)客戶端連到的上圖中的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è)的過程
為什么說Raft是保證CP的呢？
主要是因?yàn)镽aft在處理寫的時(shí)候有一個(gè)判斷過程
所以，一旦發(fā)生故障，導(dǎo)致接收不到半數(shù)的Follower寫成功的響應(yīng)，整個(gè)集群就直接寫失敗，這就很符合CP的概念了。
不過這里還有一個(gè)小細(xì)節(jié)需要注意
Nacos在處理查詢服務(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è)問題
如果客戶端查詢的Follower節(jié)點(diǎn)沒有及時(shí)處理Leader同步過來的寫請(qǐng)求（過半響應(yīng)的節(jié)點(diǎn)中不包括這個(gè)節(jié)點(diǎn)），此時(shí)在這個(gè)Follower其實(shí)是查不到最新的數(shù)據(jù)的，這就會(huì)導(dǎo)致數(shù)據(jù)的不一致
所以說，雖然Raft協(xié)議規(guī)定要求從Leader節(jié)點(diǎn)查最新的數(shù)據(jù)，但是Nacos至少在讀服務(wù)實(shí)例數(shù)據(jù)時(shí)并沒有遵守這個(gè)協(xié)議
當(dāng)然對(duì)于其它的一些數(shù)據(jù)的讀寫請(qǐng)求有的還是遵守了這個(gè)協(xié)議。
JRaft對(duì)于讀請(qǐng)求其實(shí)是做了很多優(yōu)化的，其實(shí)從Follower節(jié)點(diǎn)通過一定的機(jī)制也是能夠保證讀到最新的數(shù)據(jù)
在Nacos中，一個(gè)服務(wù)的確定是由三部分信息確定
通過上面三者就可以確定同一個(gè)服務(wù)了
在服務(wù)注冊(cè)和訂閱的時(shí)候，必須要指定上述三部分信息，如果不指定，Nacos就會(huì)提供默認(rèn)的信息
不過，在Nacos中，在服務(wù)里面其實(shí)還是有一個(gè)集群的概念
圖片
在服務(wù)注冊(cè)的時(shí)候，可以指定這個(gè)服務(wù)實(shí)例在哪個(gè)集體的集群中，默認(rèn)是在DEFAULT集群下
在SpringCloud環(huán)境底下可以通過如下配置去設(shè)置
spring cloud: nacos: discovery: cluster-name: sanyoujavaCluster在服務(wù)訂閱的時(shí)候，可以指定訂閱哪些集群下的服務(wù)實(shí)例
當(dāng)然，也可以不指定，如果不指定話，默認(rèn)就是訂閱這個(gè)服務(wù)下的所有集群的服務(wù)實(shí)例
我們?nèi)粘Ｊ褂弥锌梢詫⒉渴鹪谙嗤瑓^(qū)域的服務(wù)劃分為同一個(gè)集群，比如杭州屬于一個(gè)集群，上海屬于一個(gè)集群
這樣服務(wù)調(diào)用的時(shí)候，就可以優(yōu)先使用同一個(gè)地區(qū)的服務(wù)了，比跨區(qū)域調(diào)用速度更快。
本文鏈接：http://www.www897cc.com/showinfo-26-56584-0.html萬字+20張圖探秘Nacos注冊(cè)中心核心實(shí)現(xiàn)原理
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)