![頭圖.jpg](https://ucc.alicdn.com/pic/developer-ecology/824bc310028840f38fff8071ed5b2515.jpg)

作者 | 楊翊（席翁）  Nacos PMC
來源|阿[裡巴巴雲原生公眾號](https://mp.weixin.qq.com/s/nShELZj8rjeeWRh_zuSbFw)

## Nacos 簡介
![1.jpeg](https://ucc.alicdn.com/pic/developer-ecology/756f15ea62c2469b9317c8f59260d3b3.jpeg)

Nacos 在阿里巴巴起源於 2008 年五彩石專案，該專案完成了微服務拆分和業務中臺建設，隨著雲端計算和開源環境的興起，2018 年我們深刻感受到開源軟體行業的影響，因此決定將 Nacos 開源，輸出阿里十年關於服務發現和配管管理的沉澱，推動微服務行業發展，加速企業數字化轉型。

目前 Nacos 支援主流微服務開發語言 & 主流服務框架和配置管理框架，比如支援 Duboo 和 SCA， 還對接了一些雲原生的元件比如 coreDNS 和 sentinel 等。

客戶端語言方面支援諸如 Java、go python 等主流語言，還有近期剛釋出正式版本的 C# 和 C++，在此感謝所有社群貢獻者的支援。

![2.jpeg](https://ucc.alicdn.com/pic/developer-ecology/ca5bd67be3844b528ac93a8c92fa70ae.jpeg)

Nacos 開源 2 年多以來，共釋出了 34 個版本，其中有一些比較重要的里程碑版本；Nacos 還非常年輕，有很大的進步空間，歡迎社群及各界大佬一起共同建設。

![3.jpeg](https://ucc.alicdn.com/pic/developer-ecology/fcfa545bdaba4aba8f3afba5f232316f.jpeg)

## Nacos 1.X 架構及問題
接下來我們看一下 nacos1.x 架構及其分析一下存在的比較重要的問題。首先來看一下架構簡圖。

### Nacos 1.X 架構層次

![4.jpeg](https://ucc.alicdn.com/pic/developer-ecology/a40410451cf34cee8a62e9aeed187241.jpeg)

Nacos 1.X 大致分為 5 層， 分別是接入、通訊、功能、同步和持久化。

**接入層**是使用者最直接互動的層面，主要有 Nacos 客戶端，以及依賴客戶端的 Dubbo 和 SCA 以及使用者操作的控制檯 Console 組成。客戶端和 Console 進行服務和配置操作，統一透過 HTTP 的 OpenAPI 發起通訊請求。

**通訊層**主要基於 HTTP 的短連線請求模型進行，部分推送功能透過 UDP 進行通訊。

**功能**目前有服務發現和配置管理，這層也就是實際管理服務和配置的業務層。

**同步層**有資料同步的 AP 模式 Distro 和 CP 模式 Raft，還有有一個最簡易的水平通知 Notify，用處各不相同：

- Distro：非持久化服務的同步模式。
- Raft：持久化服務的同步模式、以及使用 Derby 作為配置的儲存時同步配置操作。
- Notify：使用 MySQL 作為配置的儲存時，通知其他節點更新快取及發起配置推送。

**持久化層** Nacos 使用 MySQL、Derby 和本地檔案系統來進行資料的持久化 配置資訊，使用者資訊，許可權資訊儲存在 MySQL 或 Derby 資料庫中， 持久化服務資訊及服務和例項後設資料資訊儲存在本地檔案系統。

### Nacos 1.X 架構下的服務模型
我們透過一個服務發現的流程，再深入熟悉一下 Nacos 1.X 架構和基於當前架構的 Nacos 服務發現模型。

![5.jpeg](https://ucc.alicdn.com/pic/developer-ecology/8b00ba1492384eb3a073fc0bd61290e7.jpeg)

Nacos 客戶端註冊服務會透過 OpenAPI 傳送 Http 註冊服務的請求，請求內容會帶上服務資訊及例項資訊，通常這個步驟是由微服務框架 SCA 和 dubbo 完成。

服務端收到請求後，會先在 Contoller 中進行資料的讀取和校驗，比如 IP 是否合法，服務名是否正確等等。校驗透過後，如果這個服務是第一次註冊，Nacos 會在服務端生成一個 Service 物件，然後把這次註冊的例項資訊存入這個 Service 物件中；如果 Nacos 服務端已經有了這個 Service 物件，那麼就會直接把新註冊的例項資訊存入物件。這個 Service 物件透過 名稱空間+Group+Service 的組合來保證唯一性。

完成例項存入 Service 的同時，會觸發兩個事件，其中一個事件是用於資料同步的，Nacos 服務端會根據這個服務是否是臨時物件的資訊，使用 Distro 或者 Raft 協議進行同步，通知其他的 Nacos 節點該服務發生了變更；另一個事件則通知在該 Nacos 服務節點上訂閱了該服務的訂閱者，並根據訂閱者資訊，透過 UDP 的方式，把最新的服務列表推送到訂閱者客戶端上。這就完成了一次服務註冊流程。

另外，對於那些被定義為持久化的服務的所有資訊，都會透過 raft 協議，保證能夠寫入到檔案系統中被持久化。

最後，其他的 Nacos 節點，在透過同步而進行 Service 變更的時候也會觸發通知訂閱者的事件，從而使在其他 Nacos 服務節點上訂閱該服務的訂閱者也能收到推送。

### 1.X 架構存在的問題

粗略介紹了下 Nacos1.X 的架構和服務發現模型，接下來分析一下 Nacos1.X 架構所面臨的幾個比較重要的問題。

一句話總結，心跳多，無效查詢多，心跳續約感知變化慢，連線消耗大，資源空耗嚴重。

![6.jpeg](https://ucc.alicdn.com/pic/developer-ecology/f0d31c18afa54f4bb5460d4516087cab.jpeg)

- **心跳數量多，導致 TPS 居高不下**

> 透過心跳續約，當服務規模上升時，特別是類似 Dubbo 的介面級服務較多時，心跳及配置後設資料的輪詢數量眾多，導致叢集 TPS 很高，系統資源高度空耗。

- **透過心跳續約感知服務變化，時延長**

> 心跳續約需要達到超時時間才會移除並通知訂閱者，預設為 15s，時延較長，時效性差。若改短超時時間，當網路抖動時，會頻繁觸發變更推送，對客戶端服務端都有更大損耗。

- **UDP 推送不可靠，導致 QPS 居高不下**

> 由於 UDP 不可靠，因此客戶端測需要每隔一段時間進行對賬查詢，保證客戶端快取的服務列表的狀態正確，當訂閱客戶端規模上升時，叢集 QPS 很高，但大多數服務列表其實不會頻繁改變，造成無效查詢，從而存在資源空耗。

- **基於 HTTP 短連線模型，TIME_WAIT 狀態連線過多**

> HTTP 短連線模型，每次客戶端請求都會建立和銷燬 TCP 連結，TCP 協議銷燬的連結狀態是 WAIT_TIME，完全釋放還需要一定時間，當 TPS 和 QPS 較高時，服務端和客戶端可能有大量的 WAIT_TIME 狀態連結，從而會導致 connect time out 錯誤或者 Cannot assign requested address 的問題。

- **配置模組的 30 秒長輪詢引起的頻繁 GC**

> 配置模組使用 HTTP 短連線阻塞模型來模擬長連線通訊，但是由於並非真實的長連線模型，因此每 30 秒需要進行一次請求和資料的上下文切換，每一次切換都有引起造成一次記憶體浪費，從而導致服務端頻繁 GC。

## Nacos 2.0 架構及新模型
### Nacos 2.0 架構層次

Nacos 2.X 在 1.X 的架構基礎上 新增了對長連線模型的支援，同時保留對舊客戶端和 openAPI 的核心功能支援。

![7.jpeg](https://ucc.alicdn.com/pic/developer-ecology/8e4ccf764e4843789571322bbef06eb9.jpeg)

通訊層目前透過 gRPC 和 Rsocket 實現了長連線 RPC 呼叫和推送能力。

在服務端測，新增一個連結層，用來將不同型別的 Request 請求，將來自不同客戶端的不同型別請求，轉化為相同語意的功能資料結構，複用業務處理邏輯。同時，將來的流量控制和負載均衡等功能也會在連結層處理。

其他架構分層在大體上保持不變。

### Nacos 2.0 新服務模型

雖然 Nacos2.0 的在架構層次上並未做太大的變化，但是具體的模型細節卻有不小的改動，依舊使用註冊服務的流程，再深入瞭解一下 Nacos2.0 服務模型的變化。

![8.jpeg](https://ucc.alicdn.com/pic/developer-ecology/6cddc5b6a17b43cd8a04c377a651b14e.jpeg)

由於通訊使用了 RPC 方式，因此某一客戶端的所有請求（無論是註冊還是訂閱）都透過同一個連結和同一個服務節點進行，不像之前透過 HTTP 連線可能每次請求都請求在不同的 Nacos 節點上，這就導致了服務發現的資料內容由原來的無狀態化變為了與連線狀態繫結的一種有狀態資料。為了適應這種變化，需要改變一下資料模型，因此抽象了一個新資料結構，將同一個客戶端透過該連結釋出和訂閱的內容關聯起來，暫命名為 Client。這個 Client 不是客戶端的意思，而是這個客戶端所相關的資料內容，一個連結與一個 Client 對應。

當客戶端釋出了服務時，該客戶端所釋出的所有服務與訂閱者資訊會被更新到與該客戶端連結相對應的 Client 物件中，然後透過事件機制觸發對索引資訊的更新。這個索引資訊是客戶端連結和服務的索引，方便快速聚合生成需要推送的服務緯度的資料。

索引資訊更新完成後，會觸發推送事件，此時會將所有和該服務有關的 Client 物件，透過剛產生的索引資訊聚合起來，當資料聚合完成後，再從客戶端連結中篩選出訂閱該服務的訂閱者的客戶端連結，將推送資料透過該連結，推送回去。這樣一次釋出變更的主鏈路就完成了。

回過頭看資料同步，客戶端釋出了服務時實際更新的物件從原來的 Service 變成 Client 物件，所以需要同步的內容也變成了 Client 物件；同時服務端間的通訊方式也會換成 RPC。這裡只有真正被客戶端更新的 Client 物件會觸發同步，如果是透過同步而更新的 Client 物件不會再次觸發同步。

最後看 Metadata，Metadata 是從 1.X 版本中的 Service 物件和 Instance 物件中分離出來的一些屬性：比如服務的後設資料 label 標籤，例項的上下線狀態、權重和後設資料 label 標籤等。這些後設資料可以被 openAPI 單獨修改，在聚合資料時生效。之所以將後設資料拆分出來，區別於基礎資料，原因是基礎資料比如：ip 埠，服務名等一經發布不應該被修改，而且應當以釋出時的資訊為準；但其他的原資料，比如上下線狀態和權重，通常是在執行過程中動態調節的，因此拆分開之後，分為兩條不同的處理工作流應該更加合理。

### Nacos 2.0 架構的優缺點

前面簡要介紹了 Nacos 2.0 的架構和新模型的工作方式，接下來我們分析一下這樣的改動有哪些優缺點。

![9.jpeg](https://ucc.alicdn.com/pic/developer-ecology/c97a6582f9204b6fbf90ca8f0741110b.jpeg)

### 優點

- 客戶端不再需要定時傳送例項心跳，只需要有一個維持連線可用 keepalive 訊息即可。重複 TPS 可以大幅降低。

- TCP 連線斷開可以被快速感知到，提升反應速度。

- 長連線的流式推送，比 UDP 更加可靠；nio 的機制具有更高的吞吐量，而且由於可靠推送，可以加長客戶端用於對賬服務列表的時間，甚至刪除相關的請求。重複的無效 QPS 可以大幅降低。

- 長連線避免頻繁連線開銷，可以大幅緩解 TIME_ WAIT 問題。

- 真實的長連線，解決配置模組 GC 問題。

- 更細粒度的同步內容，減少服務節點間的通訊壓力。

### 缺點

沒有銀彈的方案，新架構也會引入一些新問題：

- 內部結構複雜度上升，管理連線狀態，連線的負載均衡需要管理。

- 資料又原來的無狀態，變為與連線繫結的有狀態資料，流程鏈路更長。

- RPC 協議的觀測性不如 HTTP。即使 gRPC 基於 HTTP2.0Stream 實現，仍然不如直接使用 HTTP 協議來的直觀。

## Nacos 2.X 規劃

接下來簡單分享下 Nacos 2.X 的後期規劃，主要分為文件、質量和 Roadmap。

在文件和質量方面，Nacos 1.X 都做的不是很好。文件內容較少，僅有簡單使用文件；和版本有一定脫節，更新不及時；沒有對技術內容的說明，參與貢獻難度高。程式碼質量及測試質量也不是很高，雖然已經使用 checkstyle 進行了 codeStyle 的校驗以及開啟了社群協作 review。但是這還遠遠不夠。Nacos 2.X 將會逐步更新、細化官網使用文件；透過電子書對技術細節進行解析；透過 Github 展示技術方案，促進討論及貢獻；並且對程式碼進行大量重構及 UT 和 IT 的治理工作，在未來將 Benchmark 也會開源出來，方便給開源使用者進行壓測。

![10.jpeg](https://ucc.alicdn.com/pic/developer-ecology/ed86c2eec109466b8be8078e87a4bb82.jpeg)

而 RoadMap 方面，Nacos 2.X 會對專案做大幅度的重構，完成初步外掛化，並對剛才 2.0 架構的一些缺點，如負載均衡，可觀測性進行提升。

## 加入我們

歡迎在 [Nacos github](https://github.com/alibaba/nacos) 上提交 issue 與 PR 進行討論和貢獻，或加入 Nacos 社群群參與社群討論。

除了參與開源，我們也歡迎更多有能力及有意願的同學加入阿里雲共建雲原生，詳情請看[雲原生應用平臺](https://job.alibaba.com/zhaopin/position_detail.htm?spm=ata.13261165.0.0.7ed41401Q4Za06&trace=qrcode_share&positionCode=GP665241)。

### **作者簡介**

楊翊，花名席翁。Nacos PMC，主要參與的是服務發現模組，和做一些核心重構和提升的工作。Apache SharadingSphere PMC，主要負責和參與過的模組有 路由模組、分散式事務、 資料同步、以及彈性擴容。

支援 gRPC 長連結，深度解讀 Nacos 2.0 架構設計及新模型

相關文章