16 圖 | Nacos 架構原理①：一條注冊請求會經歷什么？

作者：悟空聊架構 2022-04-13 18:24:22

開發前端

本文通過發起一條注冊請求，講解了 Nacos 客戶端如何隨機選擇節點、Nacos Server 如何將請求進行路由轉發、Nacos Server 如何存儲注冊實例。

這次我們來聊下 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 和 B 注冊到集群

但是里面有一個問題：服務 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的節點?

IDEA 啟動了三個 nacos 節點

nacos 控制臺有四個節點

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 鎖，然后執行 put 操作將臨時的實例信息存放起來，所以重點看下這個 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 一致性協議。

六、總結