大家好，我是三友~~

今天就應某位小伙伴的要求，來講一講Nacos作為服務注冊中心底層的實現原理

不知你是否跟我一樣，在使用Nacos時有以下幾點疑問：

• 臨時實例和永久實例是什么？有什么區別？
• 服務實例是如何注冊到服務端的？
• 服務實例和服務端之間是如何保活的？
• 服務訂閱是如何實現的？
• 集群間數據是如何同步的？CP還是AP？
• Nacos的數據模型是什么樣的？
• ...

本文就通過探討上述問題來探秘Nacos服務注冊中心核心的底層實現原理。

雖然Nacos最新版本已經到了2.x版本，但是為了照顧那些還在用1.x版本的同學，所以本文我會同時去講1.x版本和2.x版本的實現

觀前提醒，本文又又又是一篇超長的干貨，非常適合一鍵三連~~

臨時實例和永久實例

臨時實例和永久實例在Nacos中是一個非常非常重要的概念

之所以說它重要，主要是因為我在讀源碼的時候發現，臨時實例和永久實例在底層的許多實現機制是完全不同的

臨時實例

臨時實例在注冊到注冊中心之后僅僅只保存在服務端內部一個緩存中，不會持久化到磁盤

這個服務端內部的緩存在注冊中心屆一般被稱為服務注冊表

當服務實例出現異常或者下線之后，就會把這個服務實例從服務注冊表中剔除

永久實例

永久服務實例不僅僅會存在服務注冊表中，同時也會被持久化到磁盤文件中

當服務實例出現異常或者下線，Nacos只會將服務實例的健康狀態設置為不健康，并不會對將其從服務注冊表中剔除

所以這個服務實例的信息你還是可以從注冊中心看到，只不過處于不健康狀態

這是就是兩者最最最基本的區別

當然除了上述最基本的區別之外，兩者還有很多其它的區別，接下來本文還會提到

這里你可能會有一個疑問

為什么Nacos要將服務實例分為臨時實例和永久實例?

主要還是因為應用場景不同

臨時實例就比較適合于業務服務，服務下線之后可以不需要在注冊中心中查看到

永久實例就比較適合需要運維的服務，這種服務幾乎是永久存在的，比如說MySQL、Redis等等

MySQL、Redis等服務實例可以通過SDK手動注冊

對于這些服務，我們需要一直看到服務實例的狀態，即使出現異常，也需要能夠查看時實的狀態

所以從這可以看出Nacos跟你印象中的注冊中心不太一樣，他不僅僅可以注冊平時業務中的實例，還可以注冊像MySQL、Redis這個服務實例的信息到注冊中心

在SpringCloud環境底下，一般其實都是業務服務，所以默認注冊服務實例都是臨時實例

當然如果你想改成永久實例，可以通過下面這個配置項來完成

spring
??cloud:
????nacos:
??????discovery:
????????#ephemeral單詞是臨時的意思，設置成false，就是永久實例了
????????ephemeral:?false

這里還有一個小細節

在1.x版本中，一個服務中可以既有臨時實例也有永久實例，服務實例是永久還是臨時是由服務實例本身決定的

但是2.x版本中，一個服務中的所有實例要么都是臨時的要么都是永久的，是由服務決定的，而不是具體的服務實例

所以在2.x可以說是臨時服務和永久服務

為什么2.x把臨時還是永久的屬性由實例本身決定改成了由服務決定?

其實很簡單，你想想，假設對一個MySQL服務來說，它的每個服務實例肯定都是永久的，不會出現一些是永久的，一些是臨時的情況吧

所以臨時還是永久的屬性由服務本身決定其實就更加合理了

服務注冊

作為一個服務注冊中心，服務注冊肯定是一個非常重要的功能

所謂的服務注冊，就是通過注冊中心提供的客戶端SDK（或者是控制臺）將服務本身的一些元信息，比如ip、端口等信息發送到注冊中心服務端

服務端在接收到服務之后，會將服務的信息保存到前面提到的服務注冊表中

1、1.x版本的實現

在Nacos在1.x版本的時候，服務注冊是通過Http接口實現的

代碼如下

整個邏輯比較簡單，因為Nacos服務端本身就是用SpringBoot寫的

但是在2.x版本的實現就比較復雜了

2、2.x版本的實現

2.1、通信協議的改變

2.x版本相比于1.x版本最主要的升級就是客戶端和服務端通信協議的改變，由1.x版本的Http改成了2.x版本gRPC

gRPC是谷歌公司開發的一個高性能、開源和通用的RPC框架，Java版本的實現底層也是基于Netty來的

之所以改成了gRPC，主要是因為Http請求會頻繁創建和銷毀連接，白白浪費資源

所以在2.x版本之后，為了提升性能，就將通信協議改成了gRPC

根據官網顯示，整體的效果還是很明顯，相比于1.x版本，注冊性能總體提升至少2倍

雖然通信方式改成了gRPC，但是2.x版本服務端依然保留了Http注冊的接口，所以用1.x的Nacos SDK依然可以注冊到2.x版本的服務端

2.2、具體的實現

Nacos客戶端在啟動的時候，會通過gRPC跟服務端建立長連接

這個連接會一直存在，之后客戶端與服務端所有的通信都是基于這個長連接來的

當客戶端發起注冊的時候，就會通過這個長連接，將服務實例的信息發送給服務端

服務端拿到服務實例，跟1.x一樣，也會存到服務注冊表

除了注冊之外，當注冊的是臨時實例時，2.x還會將服務實例信息存儲到客戶端中的一個緩存中，供Redo操作

所謂的Redo操作，其實就是一個補償機制，本質是個定時任務，默認每3s執行一次

這個定時任務作用是，當客戶端與服務端重新建立連接時（因為一些異常原因導致連接斷開）

那么之前注冊的服務實例肯定還要繼續注冊服務端（斷開連接服務實例就會被剔除服務注冊表）

所以這個Redo操作一個很重要的作用就是重連之后的重新注冊的作用

除了注冊之外，比如服務訂閱之類的操作也需要Redo操作，當連接重新建立，之前客戶端的操作都需要Redo一下

小總結

1.x版本是通過Http協議來進行服務注冊的

2.x由于客戶端與服務端的通信改成了gRPC長連接，所以改成通過gRPC長連接來注冊

2.x比1.x多個Redo操作，當注冊的服務實例是臨時實例是，出現網絡異常，連接重新建立之后，客戶端需要將服務注冊、服務訂閱之類的操作進行重做

這里你可能會有個疑問

既然2.x有Redo機制保證客戶端與服務端通信正常之后重新注冊，那么1.x有類似的這種Redo機制么？

當然也會有，接下往下看。

心跳機制

心跳機制，也可以被稱為保活機制，它的作用就是服務實例告訴注冊中心我這個服務實例還活著

在正常情況下，服務關閉了，那么服務會主動向Nacos服務端發送一個服務下線的請求

Nacos服務端在接收到請求之后，會將這個服務實例從服務注冊表中剔除

但是對于異常情況下，比如出現網絡問題，可能導致這個注冊的服務實例無法提供服務，處于不可用狀態，也就是不健康

而此時在沒有任何機制的情況下，服務端是無法知道這個服務處于不可用狀態

所以為了避免這種情況，一些注冊中心，就比如Nacos、Eureka，就會用心跳機制來判斷這個服務實例是否能正常

在Nacos中，心跳機制僅僅是針對臨時實例來說的，臨時實例需要靠心跳機制來保活

心跳機制在1.x和2.x版本的實現也是不一樣的

1.x心跳實現

在1.x中，心跳機制實現是通過客戶端和服務端各存在的一個定時任務來完成的

在服務注冊時，發現是臨時實例，客戶端會開啟一個5s執行一次的定時任務

這個定時任務會構建一個Http請求，攜帶這個服務實例的信息，然后發送到服務端

在Nacos服務端也會開啟一個定時任務，默認也是5s執行一次，去檢查這些服務實例最后一次心跳的時間，也就是客戶端最后一次發送Http請求的時間

• 當最后一次心跳時間超過15s，但沒有超過30s，會把這服務實例標記成不健康
• 當最后一次心跳超過30s，直接把服務從服務注冊表中剔除

這就是1.x版本的心跳機制，本質就是兩個定時任務

其實1.x的這個心跳還有一個作用，就是跟上一節說的gRPC時Redo操作的作用是一樣的

服務在處理心跳的時候，發現心跳攜帶這個服務實例的信息在注冊表中沒有，此時就會添加到服務注冊表

所以心跳也有Redo的類似效果

2.x心跳實現

在2.x版本之后，由于通信協議改成了gRPC，客戶端與服務端保持長連接，所以2.x版本之后它是利用這個gRPC長連接本身的心跳來保活

一旦這個連接斷開，服務端就會認為這個連接注冊的服務實例不可用，之后就會將這個服務實例從服務注冊表中提出剔除

除了連接本身的心跳之外，Nacos還有服務端的一個主動檢測機制

Nacos服務端也會啟動一個定時任務，默認每隔3s執行一次

這個任務會去檢查超過20s沒有發送請求數據的連接

一旦發現有連接已經超過20s沒發送請求，那么就會向這個連接對應的客戶端發送一個請求

如果請求不通或者響應失敗，此時服務端也會認為與客戶端的這個連接異常，從而將這個客戶端注冊的服務實例從服務注冊表中剔除

所以對于2.x版本，主要是兩種機制來進行保活：

• 連接本身的心跳機制，斷開就直接剔除服務實例
• Nacos主動檢查機制，服務端會對20s沒有發送數據的連接進行檢查，出現異常時也會主動斷開連接，剔除服務實例

小總結

心跳機制僅僅針對臨時實例而言

1.x心跳機制是通過客戶端和服務端兩個定時任務來完成的，客戶端定時上報心跳信息，服務端定時檢查心跳時間，超過15s標記不健康，超過30s直接剔除

1.x心跳機制還有類似2.x的Redo作用，服務端發現心跳的服務信息不存在會，會將服務信息添加到注冊表，相當于重新注冊了

2.x是基于gRPC長連接本身的心跳機制和服務端的定時檢查機制來的，出現異常直接剔除

健康檢查

前面說了，心跳機制僅僅是臨時實例用來保護的機制

而對于永久實例來說，一般來說無法主動上報心跳

就比如說MySQL實例，肯定是不會主動上報心跳到Nacos的，所以這就導致無法通過心跳機制來保活

所以針對永久實例的情況，Nacos通過一種叫健康檢查的機制去判斷服務實例是否活著

健康檢查跟心跳機制剛好相反，心跳機制是服務實例向服務端發送請求

而所謂的健康檢查就是服務端主動向服務實例發送請求，去探測服務實例是否活著

健康檢查機制在1.x和2.x的實現機制是一樣的

Nacos服務端在會去創建一個健康檢查任務，這個任務每次執行時間間隔會在2000~7000毫秒之間

當任務觸發的時候，會根據設置的健康檢查的方式執行不同的邏輯，目前主要有以下三種方式：

• TCP
• HTTP
• MySQL

TCP的方式就是根據服務實例的ip和端口去判斷是否能連接成功，如果連接成功，就認為健康，反之就任務不健康

HTTP的方式就是向服務實例的ip和端口發送一個Http請求，請求路徑是需要設置的，如果能正常請求，說明實例健康，反之就不健康

MySQL的方式是一種特殊的檢查方式，他可以執行下面這條Sql來判斷數據庫是不是主庫

默認情況下，都是通過TCP的方式來探測服務實例是否還活著

服務發現

所謂的服務發現就是指當有服務實例注冊成功之后，其它服務可以發現這些服務實例

Nacos提供了兩種發現方式：

• 主動查詢
• 服務訂閱

主動查詢就是指客戶端主動向服務端查詢需要關注的服務實例，也就是拉（pull）的模式

服務訂閱就是指客戶端向服務端發送一個訂閱服務的請求，當被訂閱的服務有信息變動就會主動將服務實例的信息推送給訂閱的客戶端，本質就是推（push）模式

在我們平時使用時，一般來說都是選擇使用訂閱的方式，這樣一旦有服務實例數據的變動，客戶端能夠第一時間感知

并且Nacos在整合SpringCloud的時候，默認就是使用訂閱的方式

對于這兩種服務發現方式，1.x和2.x版本實現也是不一樣

服務查詢其實兩者實現都很簡單

1.x整體就是發送Http請求去查詢服務實例，2.x只不過是將Http請求換成了gRPC的請求

服務端對于查詢的處理過程都是一樣的，從服務注冊表中查出符合查詢條件的服務實例進行返回

不過對于服務訂閱，兩者的機制就稍微復雜一點

在Nacos客戶端，不論是1.x還是2.x都是通過SDK中的NamingService#subscribe方法來發起訂閱的

當有服務實例數據變動的時，客戶端就會回調EventListener，就可以拿到最新的服務實例數據了

雖然1.x還是2.x都是同樣的方法，但是具體的實現邏輯是不一樣的

1.x服務訂閱實現

在1.x版本的時候，服務訂閱的處理邏輯大致會有以下三步：

第一步，客戶端在啟動的時候，會去構建一個叫PushReceiver的類

這個類會去創建一個UDP Socket，端口是隨機的

其實通過名字就可以知道這個類的作用，就是通過UDP的方式接收服務端推送的數據的

第二步，調用NamingService#subscribe來發起訂閱時，會先去服務端查詢需要訂閱服務的所有實例信息

之后會將所有服務實例數據存到客戶端的一個內部緩存中

并且在查詢的時候，會將這個UDP Socket的端口作為一個參數傳到服務端

服務端接收到這個UDP端口后，后續就通過這個端口給客戶端推送服務實例數據

第三步，會為這次訂閱開啟一個不定時執行的任務

之所以不定時，是因為這個當執行異常的時候，下次執行的時間間隔就會變長，但是最多不超過60s，正常是10s，這個10s是查詢服務實例是服務端返回的

這個任務會去從服務端查詢訂閱的服務實例信息，然后更新內部緩存

這里你可能會有個疑問

既然有了服務變動推送的功能，為什么還要定時去查詢更新服務實例信息呢?

其實很簡單，那就是因為UDP通信不穩定導致的

雖然有Push，但是由于UDP通信自身的不確定性，有可能會導致客戶端接收變動信息失敗

所以這里就加了一個定時任務，彌補這種可能性，屬于一個兜底的方案。

這就是1.x版本的服務訂閱的實現

2.x服務訂閱的實現

講完1.x的版本實現，接下來就講一講2.x版本的實現

由于2.x版本換成了gRPC長連接的方式，所以2.x版本服務數據變更推送已經完全拋棄了1.x的UDP做法

當有服務實例變動的時候，服務端直接通過這個長連接將服務信息發送給客戶端

客戶端拿到最新服務實例數據之后的處理方式就跟1.x是一樣了

除了處理方式一樣，2.x也繼承了1.x的其他的東西

比如客戶端依然會有服務實例的緩存

定時對比機制也保留了，只不過這個定時對比的機制默認是關閉狀態

之所以默認關閉，主要還是因為長連接還是比較穩定的原因

當客戶端出現異常，接收不到請求，那么服務端會直接跟客戶端斷開連接

當恢復正常，由于有Redo操作，所以還是能拿到最新的實例信息的

所以2.x版本的服務訂閱功能的實現大致如下圖所示

這里還有個細節需要注意

在1.x版本的時候，任何服務都是可以被訂閱的

但是在2.x版本中，只支持訂閱臨時服務，對于永久服務，已經不支持訂閱了

小總結

服務查詢1.x是通過Http請求；2.x通過gRPC請求

服務訂閱1.x是通過UDP來推送的；2.x就基于gRPC長連接來實現的

1.x和2.x客戶端都有服務實例的緩存，也有定時對比機制，只不過1.x會自動開啟；2.x提供了一個開個，可以手動選擇是否開啟，默認不開啟

數據一致性

由于Nacos是支持集群模式的，所以一定會涉及到分布式系統中不可避免的數據一致性問題

1、服務實例的責任機制

再說數據一致性問題之前，先來討論一下服務實例的責任機制

什么是服務實例的責任機制？

比如上面提到的服務注冊、心跳管理、監控檢查機制，當只有一個Nacos服務時，那么自然而言這個服務會去檢查所有的服務實例的心跳時間，執行所有服務實例的健康檢查任務

但是當出現Nacos服務出現集群時，為了平衡各Nacos服務的壓力，Nacos會根據一定的規則讓每個Nacos服務只管理一部分服務實例的

當然每個Nacos服務的注冊表還是全部的服務實例數據

這個管理機制我給他起了一個名字，就叫做責任機制，因為我在1.x和2.x都提到了responsible這個單詞

本質就是Nacos服務對哪些服務實例負有心跳監測，健康檢查的責任。

2、CAP定理和BASE理論

談到數據一致性問題，一定離不開兩個著名分布式理論

• CAP定理
• BASE理論

CAP定理中，三個字母分別代表這些含義：

• C，Consistency單詞的縮寫，代表一致性，指分布式系統中各個節點的數據保持強一致，也就是每個時刻都必須一樣，不一樣整個系統就不能對外提供服務
• A，Availability單詞的縮寫，代表可用性，指整個分布式系統保持對外可用，即使從每個節點獲取的數據可能都不一樣，只要能獲取到就行
• P，Partition tolerance單詞的縮寫，代表分區容錯性。

所謂的CAP定理，就是指在一個分布式系統中，CAP這三個指標，最多同時只能滿足其中的兩個，不可能三個都同時滿足

為什么三者不能同時滿足？

對于一個分布式系統，網絡分區是一定需要滿足的

而所謂分區指的是系統中的服務部署在不同的網絡區域中

比如，同一套系統可能同時在北京和上海都有部署，那么他們就處于不同的網絡分區，就可能出現無法互相訪問的情況

當然，你也可以把所有的服務都放在一個網絡分區，但是當網絡出現故障時，整個系統都無法對外提供服務，那這還有什么意義呢？

所以分布式系統一定需要滿足分區容錯性，把系統部署在不同的區域網絡中

此時只剩下了一致性和可用性，它們為什么不能同時滿足？

其實答案很簡單，就因為可能出現網絡分區導致的通信失敗。

比如說，現在出現了網絡分區的問題，上圖中的A網絡區域和B網絡區域無法相互訪問

此時假設往上圖中的A網絡區域發送請求，將服務中的一個值 i 屬性設置成 1

如果保證可用性，此時由于A和B網絡不通，此時只有A中的服務修改成功，B無法修改成功，此時數據AB區域數據就不一致性，也就沒有保證數據一致性

如果保證一致性，此時由于A和B網絡不通，所以此時A也不能修改成功，必須修改失敗，否則就會導致AB數據不一致

雖然A沒修改成功，保證了數據一致性，AB還是之前相同的數據，但是此時整個系統已經沒有寫可用性了，無法成功寫數據了。

所以從上面分析可以看出，在有分區容錯性的前提下，可用性和一致性是無法同時保證的。

雖然無法同時一致性和可用性，但是能不能換種思路來思考一下這個問題

首先我們可以先保證系統的可用性，也就是先讓系統能夠寫數據，將A區域服務中的i修改成1

之后當AB區域之間網絡恢復之后，將A區域的i值復制給B區域，這樣就能夠保證AB區域間的數據最終是一致的了

這不就皆大歡喜了么

這種思路其實就是BASE理論的核心要點，優先保證可用性，數據最終達成一致性。

BASE理論主要是包括以下三點：

• 基本可用（Basically Available）：系統出現故障還是能夠對外提供服務，不至于直接無法用了
• 軟狀態（Soft State）：允許各個節點的數據不一致
• 最終一致性，（Eventually Consistent）：雖然允許各個節點的數據不一致，但是在一定時間之后，各個節點的數據最終需要一致的

BASE理論其實就是妥協之后的產物。

3、Nacos的AP和CP

Nacos其實目前是同時支持AP和CP的

具體使用AP還是CP得取決于Nacos內部的具體功能，并不是有的文章說的可以通過一個配置*切換。

就以服務注冊舉例來說，對于臨時實例來說，Nacos會優先保證可用性，也就是AP

對于永久實例，Nacos會優先保證數據的一致性，也就是CP

接下來我們就來講一講Nacos的CP和AP的實現原理

3.1、Nacos的AP實現

對于AP來說，Nacos使用的是阿里自研的Distro協議

在這個協議中，每個服務端節點是一個平等的狀態，每個服務端節點正常情況下數據是一樣的，每個服務端節點都可以接收來自客戶端的讀寫請求

當某個節點剛啟動時，他會向集群中的某個節點發送請求，拉取所有的服務實例數據到自己的服務注冊表中

這樣其它客戶端就可以從這個服務節點中獲取到服務實例數據了

當某個服務端節點接收到注冊臨時服務實例的請求，不僅僅會將這個服務實例存到自身的服務注冊表，同時也會向其它所有服務節點發送請求，將這個服務數據同步到其它所有節點

所以此時從任意一個節點都是可以獲取到所有的服務實例數據的。

即使數據同步的過程發生異常，服務實例也成功注冊到一個Nacos服務中，對外部而言，整個Nacos集群是可用的，也就達到了AP的效果

同時為了滿足BASE理論，Nacos也有下面兩種機制保證最終節點間數據最終是一致的：

• 失敗重試機制
• 定時對比機制

失敗重試機制是指當數據同步給其它節點失敗時，會每隔3s重試一次，直到成功

定時對比機制就是指，每個Nacos服務節點會定時向所有的其它服務節點發送一些認證的請求

這個請求會告訴每個服務節點自己負責的服務實例的對應的版本號，這個版本號隨著服務實例的變動就會變動

如果其它服務節點的數據的版本號跟自己的對不上，那就說明其它服務節點的數據不是最新的

此時這個Nacos服務節點就會將自己負責的服務實例數據發給不是最新數據的節點，這樣就保證了每個節點的數據是一樣的了。

3.2、Nacos的CP實現

Nacos的CP實現是基于Raft算法來實現的

在1.x版本早期，Nacos是自己手動實現Raft算法

在2.x版本，Nacos移除了手動實現Raft算法，轉而擁抱基于螞蟻開源的JRaft框架

在Raft算法，每個節點主要有三個狀態

• Leader，負責所有的讀寫請求，一個集群只有一個
• Follower，從節點，主要是負責復制Leader的數據，保證數據的一致性
• Candidate，候選節點，最終會變成Leader或者Follower

集群啟動時都是節點Follower，經過一段時間會轉換成Candidate狀態，再經過一系列復雜的選擇算法，選出一個Leader

這個選舉算法比較復雜，完全值得另寫一篇文章，這里就不細說了。不過立個flag，如果本篇文章點贊量超過28個，我連夜爆肝，再來一篇。

當有寫請求時，如果請求的節點不是Leader節點時，會將請求轉給Leader節點，由Leader節點處理寫請求

比如，有個客戶端連到的上圖中的Nacos服務2節點，之后向Nacos服務2注冊服務

Nacos服務2接收到請求之后，會判斷自己是不是Leader節點，發現自己不是

此時Nacos服務2就會向Leader節點發送請求，Leader節點接收到請求之后，會處理服務注冊的過程

為什么說Raft是保證CP的呢？

主要是因為Raft在處理寫的時候有一個判斷過程

• 首先，Leader在處理寫請求時，不會直接數據應用到自己的系統，而是先向所有的Follower發送請求，讓他們先處理這個請求
• 當超過半數的Follower成功處理了這個寫請求之后，Leader才會寫數據，并返回給客戶端請求處理成功
• 如果超過一定時間未收到超過半數處理成功Follower的信號，此時Leader認為這次寫數據是失敗的，就不會處理寫請求，直接返回給客戶端請求失敗

所以，一旦發生故障，導致接收不到半數的Follower寫成功的響應，整個集群就直接寫失敗，這就很符合CP的概念了。

不過這里還有一個小細節需要注意

Nacos在處理查詢服務實例的請求直接時，并不會將請求轉發給Leader節點處理，而是直接查當前Nacos服務實例的注冊表

這其實就會引發一個問題

如果客戶端查詢的Follower節點沒有及時處理Leader同步過來的寫請求（過半響應的節點中不包括這個節點），此時在這個Follower其實是查不到最新的數據的，這就會導致數據的不一致

所以說，雖然Raft協議規定要求從Leader節點查最新的數據，但是Nacos至少在讀服務實例數據時并沒有遵守這個協議

當然對于其它的一些數據的讀寫請求有的還是遵守了這個協議。

JRaft對于讀請求其實是做了很多優化的，其實從Follower節點通過一定的機制也是能夠保證讀到最新的數據

數據模型

在Nacos中，一個服務的確定是由三部分信息確定

• 命名空間（Namespace）：多租戶隔離用的，默認是public
• 分組（Group）：這個其實可以用來做環境隔離，服務注冊時可以指定服務的分組，比如是測試環境或者是開發環境，默認是DEFAULT_GROUP
• 服務名（ServiceName）：這個就不用多說了

通過上面三者就可以確定同一個服務了

在服務注冊和訂閱的時候，必須要指定上述三部分信息，如果不指定，Nacos就會提供默認的信息

不過，在Nacos中，在服務里面其實還是有一個集群的概念

在服務注冊的時候，可以指定這個服務實例在哪個集體的集群中，默認是在DEFAULT集群下

在SpringCloud環境底下可以通過如下配置去設置

spring
??cloud:
????nacos:
??????discovery:
????????cluster-name:?sanyoujavaCluster

在服務訂閱的時候，可以指定訂閱哪些集群下的服務實例

當然，也可以不指定，如果不指定話，默認就是訂閱這個服務下的所有集群的服務實例

我們日常使用中可以將部署在相同區域的服務劃分為同一個集群，比如杭州屬于一個集群，上海屬于一個集群

這樣服務調用的時候，就可以優先使用同一個地區的服務了，比跨區域調用速度更快。

總結

到這，終終終于總算是講完了Nacos作為注冊中心核心的實現原理

這篇文章從最開始的翻源碼、查資料到最終完成，前前后后也肝了大半個月的時間，橫跨了2023和2024，碼了上萬字

不知道你讀完整篇文章是否有所收貨

不過有一點可以確定的是，能夠看到這里的那一定都是真愛粉了

2024年到了，這里也祝大家身體健康，升職加薪，今年我也會繼續輸出硬核干貨文章

好了，本文就講到這里，如果覺得本篇對你有點幫助，歡迎點贊、在看、收藏、轉發分享給其他需要的人，你的支持就是我更新的最大動力，感謝感謝！

往期熱門文章推薦

如何去閱讀源碼，我總結了18條心法

如何寫出漂亮代碼，我總結了45個小技巧

三萬字盤點Spring/Boot的那些常用擴展點

三萬字盤點Spring 9大核心基礎功能

兩萬字盤點那些被玩爛了的設計模式

萬字+20張圖剖析Spring啟動時12個核心步驟

1.5萬字+30張圖盤點索引常見的11個知識點

1.5萬字+25張圖盤點RocketMQ 11種消息類型

掃碼或者搜索關注公眾號 三友的java日記 ，及時干貨不錯過，公眾號致力于通過畫圖加上通俗易懂的語言講解技術，讓技術更加容易學習，回復 面試 即可獲得一套面試真題。