大家好，我是悟空呀。
前言
上篇我們講解了如何使用 Nacos 作爲註冊中心和配置中心。
這次我們來聊下 Nacos 的註冊服務的底層原理。
Nacos 作爲註冊中心，用來接收客戶端（服務實例）發起的註冊請求，並將註冊信息存放到註冊中心進行管理。
那麼一條註冊請求到底會經歷哪些步驟呢？
知識點預告
先上一張整體的流程圖：
- 集羣環境：如果是 Nacos 集羣環境，那麼拓撲結構是什麼樣的。
- 組裝請求：客戶端組裝註冊請求，下一步對 Nacos 服務發起遠程調用。
- 隨機節點：客戶端隨機選擇集羣中的一個 Nacos 節點發起註冊，實現負載均衡。
- 路由轉發：Nacos 節點收到註冊請求後，看下是不是屬於自己的，不是的話，就進行路由轉發。
- 處理請求：轉發給指定的節點後，該節點就會將註冊請求中的實例信息解析出來，存到自定義的內存結構中。
- 最終一致性：通過 Nacos 自研的 Distro 協議執行
延遲異步任務，將註冊信息同步給集羣中的其他節點，保證了數據的最終一致性。 - 異步重試：如果註冊失敗，客戶端將會切換 Nacos 節點，再次發起註冊請求，保證高可用性。
這些知識點裏面還有很多細節，我會通過畫圖 + 源碼剖析的方式給大家解答。如果遇到源碼看不太懂的地方，可以多看下我畫的圖，然後翻下源碼，對照着一起看。
小 Tip：本文使用的 Nacos 版本： 2.0.4。
一、源頭：發起註冊
1.1 閱讀源碼的小技巧
上篇我們講到加上一個註解 @EnableDiscoveryClient 就可以使服務自動註冊到 Nacos。
那麼這個發起註冊的地方到底在哪呢？註冊信息又是長什麼樣的呢？
告訴大家一個看源碼的小技巧，拿到源碼後，不是直接各個文件都看一篇，而是先看源碼中帶的 example 文件夾。如下圖所示，找到 example 的 App 類，裏面就有發起註冊的實例代碼。如下圖所示：
當然，我們也可以通過官網給的 curl 命令發起 HTTP 請求：
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.11&port=8080'
留個問題：我們都是加一個 Nacos 註解 @EnableDiscoveryClient，就會自動把服務實例註冊到 Nacos，這個是怎麼做到的？
1.2 發起註冊的流程圖
先來看一下代碼的流程圖：
跟着這個流程圖，我們 debug 來看下。
1.3 組裝註冊的實例信息
入口的核心代碼如下圖所示，它會組裝註冊的實例信息，放到一個 instance 變量裏面：
通過代碼調試，我們可以看到裏面的實例信息長這樣：
1.4 組裝註冊請求 request
發起註冊的核心方法是 doRegisterService()，組裝的 request 如下圖所示，裏面有之前組裝的實例信息 instance，還有指定的 namespace（Nacos 的命名空間）、serviceName（服務名），groupName（Nacos 的分組）。
1.5 發起遠程調用
requestToServer() 方法裏面會調用 RpcClient 的 request() 方法：
response = this.currentConnection.request(request, timeoutMills);
就是向 Nacos 發起遠程調用，如果是 Nacos 集羣，則是向集羣中的某個 Nacos 節點發起遠程調用。
接下來我們看下客戶端是如何選擇一個 Nacos 節點進行註冊的。
二、集羣環境：分佈式的前提
如果是 Nacos 集羣環境，客戶端會隨機選擇一個 Nacos 節點發起註冊。
2.1 搭建好一套Nacos 集羣環境
爲了講解客戶端是如何註冊到 Nacos 集羣環境的底層原理，我在本地搭建了一個 Nacos 集羣環境，有 3 個 Nacos 服務，它們的 IP 相同，端口號不同。
192.168.10.197:8848
192.168.10.197:8858
192.168.10.197:8868
然後服務 A 和服務 B 都是配置了 Nacos 集羣的 IP 和 端口號的，配置如下所示
spring.cloud.nacos.discovery.server-addr
=192.168.10.197:8848,192.168.10.197:8858,192.168.10.197:8868
整體的結構如下圖所示，服務 A 和 服務 B 都往 Nacos 集羣進行註冊。
但是裏面有一個問題：服務 A 註冊時，是向所有 Nacos 節點發起註冊呢？還是隻向其中一個節點發起註冊？如果只向一個節點註冊，要向哪個節點註冊呢？
答案：在 Client 發起註冊之前，會有一個後臺線程隨機拿到 Nacos 集羣服務列表中的一個地址。
Nacos 爲什麼會這樣設計？
- 這其實就是一個負載均衡的思想在裏面，每個節點都均勻的分攤請求。
- 保證高可用，當某個節點宕機後，重新拿到其他的 Nacos 節點來建立連接。
接下來我們看下服務 A 是怎麼隨機拿到一個 Nacos 節點的。
三、隨機節點：平等的世界
我們來看下客戶端是如何隨機選擇一個節點的，流程圖如下：
那麼如何找到這些代碼邏輯呢？思路是怎麼樣的？
我們之前講過，RpcClient 會發起 request 請求，用的是和 Nacos 建立 currentConnection 連接來發起調用，代碼如下：
// 發起調用
response = this.currentConnection.request(request, timeoutMills);
這個 currentConnection 是客戶端和 Nacos 集羣中的某個節點建立的連接，我們找下它在哪裏賦值的。代碼如下：
// 拿到 Nacos 節點信息
serverInfo = recommendServer.get() == null ? nextRpcServer() : recommendServer.get();
// 連接 Nacos 節點
connectToServer = connectToServer(serverInfo);
// 賦值 currentConnection
this.currentConnection = connectToServer;
而連接的信息是通過參數 serverInfo 傳進去的，所以我們再看下 serverInfo 在哪裏賦值的。
這個 nextRpcServer() 方法裏面會拿到一個隨機的 Nacos 地址：
// 一個 int 隨機數，範圍 [0 ~ Nacos 個數)
currentIndex.set(new Random().nextInt(serverList.size()));
// index 自增 1
int index = currentIndex.incrementAndGet() % getServerList().size();
// 返回 Nacos 地址
return getServerList().get(index);
小結：客戶端生成一個隨機數，然後通過這個隨機數從 Nacos 服務列表中拿到一個 Nacos 服務地址返回給客戶端，然後客戶端通過這個地址和 Nacos 服務建立連接。Nacos 服務列表中的節點都是平等的，隨機拿到的任何一個節點都是可以用來發起調用的。
四、路由轉發：不是我的菜
4.1 發起和轉發請求的流程
爲了演示發起註冊的流程，我在這裏模擬了一個註冊請求。
用的是 curl 命令，對 Nacos 節點（127.0.0.1:8848）發起註冊請求：
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.11&port=8080'
請求 URL：/nacos/v1/ns/instance
請求參數：
- serviceName=nacos.naming.serviceName
- ip=20.18.7.11
- port=8080'
之前我們講到，Nacos 的有多個節點可以分別處理請求，當節點發現這個請求不是屬於自己的，就會進行轉發。
如下圖所示：
服務 A 隨機選擇一個 Nacos 節點（圖中爲 Nacos1）發起註冊請求，請求參數中包含了實例信息，Nacos 1 根據實例信息 hash + 取模拿到正確的節點，如果不屬於自己，則將請求轉發給其他節點（圖中爲 Nacos2）
那麼路由轉發的細節是怎麼樣的？這個就涉及到 Distro 協議了，我們接着往下看。
4.1 路由轉發的邏輯
其實 Nacos 節點的路由轉發邏輯比較簡單，先來看下流程圖：
步驟如下：
- ① Nacos 節點從客戶端發起的 request 中拿到客戶端的實例信息生成 distroTag，如 IP + port 或 service name。
- ② Nacos 根據 distroTag 生成 hash 值。
- ③ 用 hash 值對 Nacos 節點數進行
取餘，拿到餘數，比如 0、1、2、3。 - ④ 根據餘數從 Nacos 節點列表中拿到指定的節點地址。
我沒看懂的點：我這裏啓動了三個 Nacos 節點，如下圖所示的 三個 Running 節點。但是爲什麼 Nacos 的 ServersList 會多了一個 192.168.10.197:8848的節點？
4.2 路由轉發源碼分析
入口文件是 DistroFilter.java：
naming/src/main/java/com/alibaba/nacos/naming/web/DistroFilter.java
請求會先到 DistroFilter 類的 doFilter() 方法，拿到正確的節點地址後，將請求轉發出去。
獲取需要轉發節點地址的代碼如下：
// 找到 Nacos 集羣中的目標節點
final String targetServer = distroMapper.mapSrv(distroTag);
// mapSrv 方法會先 hash，然後再取模，responsibleTag的值類似這樣："20.18.7.11:8080"
int index = distroHash(responsibleTag) % servers.size();
// distroHash 方法裏面會對 客戶端的 ip+port 字符串或者服務名字符串 進行 hash
Math.abs(responsibleTag.hashCode() % Integer.MAX_VALUE);
不論是自己處理註冊請求還是轉發給其他節點來處理，都會把實例信息存儲起來，那麼是如何進行存儲的？
五、處理請求：快到碗裏來
Nacos 目前有兩個版本，v1 和 v2，如果是 v1，則是 instanceController 來處理註冊請求，否則用 instanceControllerV2。本篇我們只講解 v1 版本是怎麼處理請求的。
先上流程圖：
測試用的發起註冊的命令：
curl -X POST 'http://127.0.0.1:8858/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.11&port=8080'
核心代碼就是這個：
有一個 synchronized 鎖，將臨時的實例信息存放起來，所以重點看下 這個 consistencyService.put() 方法做了什麼事情。
先看下源碼：
onPut(key, value);
// 開啓 1s 的延遲任務，將數據同步給其他 Nacos 節點
distroProtocol.sync(new DistroKey(key,KeyBuilder.INSTANCE_LIST_KEY_PREFIX),DataOperation.CHANGE,
DistroConfig.getInstance().getSyncDelayMillis());
這裏面做了三件事情：
- ① 將實例信息存放到內存緩存 concurrentHashMap 裏面。
- ② 添加一個任務到 BlockingQueue 裏面，這個任務就是將最新的實例列表通過 UDP 的方式推送給所有客戶端（服務實例），這樣客戶端就拿到了最新的服務實例列表。
- ③ 開啓 1s 的延遲任務，將數據通過給其他 Nacos 節點。
注意：針對第二點和第三點，屬於 Distro 一致性協議的一部分，裏面的內容還比較多，我們放到下一講專門來講。
知識點預告：
-
這裏的存儲實例和同步的方式和 Eureka 有什麼區別？Eureka 用的三層緩存架構，Nacos 用的 CopyOnWrite 技術。
-
如何推送給所有客戶端的？UDP 方式。
-
如何同步給 Nacos 其他節點的？Distro 一致性協議。
六、總結
本文通過發起一條註冊請求，講解了 Nacos 客戶端如何隨機選擇節點、Nacos Server 如何路由、Nacos Server 如何存儲註冊實例。
核心流程：
下一篇預告：Nacos 的一致性協議 Distro 協議，揭祕 AP 架構。
我是悟空，期待與你一起打怪升級變強！