![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/63220024c82e4284b4378c11a546347c.png)

作者 | 席翁
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/w21x8dhomqQ-1xKbWlUrKw)

繼 Nacos 1.0 釋出以來，Nacos 迅速被成千上萬家企業採用，並構建起強大的生態。但是隨著使用者深入使用，逐漸暴露一些效能問題，因此我們啟動了 Nacos 2.0 的隔代產品設計，時隔半年我們終於將其全部實現，實測效能提升 10 倍，相信能滿足所有使用者的效能需求。下面由我代表社群為大家介紹一下這款跨代產品。

# Nacos 簡介
Nacos 是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。它孵化於阿里巴巴，成長於十年雙十一的洪峰考驗，沉澱了簡單易用、穩定可靠、效能卓越的核心競爭力。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/8533cf5b22ef412382191e935e9d7be8.png)

# Nacos 2.0 架構
全新 2.0 架構不僅將效能大幅提升 10 倍，而且核心進行了分層抽象，並且實現外掛擴充套件機制。

Nacos 2.0 架構層次如下圖，它相比Nacos1.X的最主要變化是：

- 通訊層統一到 gRPC 協議，同時完善了客戶端和服務端的流量控制和負載均衡能力，提升的整體吞吐。
- 將儲存和一致性模型做了充分抽象分層，架構更簡單清晰，程式碼更加健壯，效能更加強悍。
- 設計了可擴充的介面，提升了整合能力，如讓使用者擴充套件實現各自的安全機制。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/56ba3da2b1704e39b29bfa7b8b795e20.png)

## 1. Nacos2.0 服務發現升級一致性模型
Nacos2.0 架構下的服務發現，客戶端透過 gRPC，發起註冊服務或訂閱服務的請求。服務端使用 Client 物件來記錄該客戶端使用 gRPC 連線釋出了哪些服務，又訂閱了哪些服務，並將該 Client 進行服務間同步。由於實際的使用習慣是服務到客戶端的對映，即服務下有哪些客戶端例項；因此 2.0 的服務端會透過構建索引和後設資料，快速生成類似 1.X 中的 Service 資訊，並將 Service 的資料透過  gRPC Stream 進行推送。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/5d733365e6ea482d9c1f9225d782b9aa.png)

## 2. Nacos2.0 配置管理升級通訊機制
配置管理之前用 Http1.1 的 Keep Alive 模式 30s 發一個心跳模擬長連結，協議難以理解，記憶體消耗大，推送效能弱，因此 2.0 透過 gRPC 徹底解決這些問題，記憶體消耗大量降低。

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

## 3. Nacos2.0 架構優勢
 Nacos2.0 大幅降低了資源消耗，提升吞吐效能，最佳化客戶端和服務端互動，對使用者更加友好；雖然可觀測性略微下降，但是整體價效比非常高。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/d362961039d744da9d1542024a7e04eb.png)

# Nacos2.0 效能提升
由於 Nacos 由服務發現和配置管理兩大模組構成，業務模型略有差異，因此我們下面分別介紹一下具體壓測指標。

## 1. Nacos2.0 服務發現的效能提升
服務發現場景我們主要關注客戶端數，服務數例項數，及服務訂閱者數在大規模場景下，服務端在同步，推送及穩定狀態時的效能表現。同時還關注在有大量服務在進行上下線時，系統的效能表現。

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

- **容量及穩定狀態測試**

該場景主要關注隨著服務規模和客戶端例項規模上漲，系統效能表現。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d74e23a0685745439e679d508adeaad2.png)

可以看到 2.0.0 版本在 10W 級客戶端規模下，能夠穩定的支撐，在達到穩定狀態後，CPU 的損耗非常低。雖然在最初的大量註冊階段，由於存在瞬時的大量註冊和推送，因此有一定的推送超時，但是會在重試後推送成功，不會影響資料一致性。

反觀 1.X 版本，在 10W、5W 級客戶端下，服務端完全處於 Full GC 狀態，推送完全失敗，叢集不可用；在 2W 客戶端規模下，雖然服務端執行狀態正常，但由於心跳處理不及時，大量服務在摘除和註冊階段反覆進行，因此達不到穩定狀態，CPU 一直很高。1.2W 客戶端規模下，可以穩定執行，但穩態時 CPU 消耗是更大規模下 2.0 的 3 倍以上。

- **頻繁變更測試**

該場景主要關注業務大規模釋出，服務頻繁推送條件下，不同版本的吞吐和失敗率。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/03814038323d4617b3ed9fbb4c6ffd39.png)

頻繁變更時，2.0 和 1.X 在達到穩定狀態後，均能穩定支撐，其中 2.0 由於不再有瞬時的推送風暴，因此推送失敗率歸 0，而 1.X 的 UDP 推送的不穩定性導致了有極小部分推送出現了超時，需要重試推送。

## 2. Nacos2.0 配置管理的效能提升
由於配置是少寫多讀場景，所以瓶頸主要在單臺監聽的客戶端數量以及配置的推送獲取上，因此配置管理的壓測效能主要集中於單臺服務端的連線容量以及大量推送的比較。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/31ad0ab3e81d41caaca112f1db52a69c.png)

- **Nacos2.0 連線容量測試**

該場景主要關注不同客戶端規模下的系統壓力。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/78072667f2014a488aae3acafcb64229.png)

Nacos2.0 最高單機能夠支撐 4.2w 個配置客戶端連線，在連線建立的階段，有大量訂閱請求需要處理，因此 CPU 消耗較高，但達到穩態後，CPU 的消耗會變得很低。幾乎沒有消耗。

反觀 Nacos1.X， 在客戶端 6000 時，穩定狀態的 CPU 一直很高，且 GC 頻繁，主要原因是長輪訓是透過 hold 請求來保持連線，每 30s 需要回一次 Response 並且重新發起連線和請求。需要做大量的上下文切換，同時還需要持有所有 Request 和 Response。當規模達到 1.2w 客戶端時，已經無法達到穩態，所以無法支撐這個量級的客戶端數。

- **Nacos2.0 頻繁推送測試**

該場景關注不同推送規模下的系統表現。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/7bed04f550a745779e1b75a05584aebf.png)

在頻繁變更的場景，兩個版本都處於 6000 個客戶端連線中。明顯可以發現 2.0 版本的效能損耗要遠低於 1.X 版本。在 3000tps 的推送場景下，最佳化程度約最佳化了 3 倍。

## 3. Nacos2.0 效能結論
**針對服務發現場景，Nacos2.0 能夠在 10W 級規模下，穩定執行；相比 Nacos1.X 版本的 1.2W 規模，提升約 10 倍**。

**針對配置管理場景，Nacos2.0 單機最高能夠支撐 4.2W 個客戶端連線；相比 Nacos1.X，提升了 7 倍。且推送時的效能明顯好於1.X**。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/9efec3af7ffe4b5b907c2d0a52ce185d.png)

# Nacos 生態及 2.X 後續規劃
隨著 Nacos 三年的發展，幾乎支援了所有的 RPC 框架和微服務生態，並且引領雲原生微服務生態發展。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/ebbd87b035e34c6cb06df916ea5d0fd5.png)

Nacos 是整個微服務生態中非常核心的元件，它可以無縫和 K8s 服務發現體系互通，透過 MCP/XDS 協議與 Istio 通訊，將 Nacos 服務下發 Sidecar；同樣也可以和 CoreDNS 聯合，將 Nacos 服務透過域名模式暴露給下游呼叫。

Nacos 目前已經和各類微服務 RPC 框架融合進行服務發現；另外可以協助高可用框架 Sentinel 進行各類管理規則的控制和下發。

如果只使用 RPC 框架，有時候並不足夠簡單，因為部分 RPC 框架比如 gRPC 和 Thrift，還需要自行啟動 Server 並告知 client 該呼叫哪個 IP。這時候就需要和應用框架進行融合，比如 SCA、Dapr 等；當然也可以透過 Envoy Sidecar 來進行流量控制，應用層的RPC就不需要知道服務 的 IP 列表了。

最後，Nacos 還可以和各類微服務閘道器打通，實現接入層的分發和微服務呼叫。

## 1. Nacos 生態在阿里的實踐
目前 Nacos 已經完成了自研、開源、商業化三位一體的建設，阿里內部的釘釘、考拉、餓了麼、優酷等業務域已經全部採用雲產品 MSE 中的 Nacos 服務，並且與阿里和雲原生的技術棧無縫整合。下面我們以釘釘為例簡單做一下介紹。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/63e8a53ad8bc4cdca14cef1e719c50e1.png)

Nacos 執行在[微服務引擎 MSE](https://cn.aliyun.com/product/aliware/mse?spm=nacos-website.topbar.0.0.0)（全託管的 Nacos 叢集）上，進行維護和多叢集管理；業務的各類 Dubbo3 或 HSF 服務在啟動時，透過 Dubbo3 自身註冊到 Nacos 叢集中；然後 Nacos 透過 MCP 協議將服務資訊同步到 Istio 和 Ingress-Envoy 閘道器。

使用者流量從北向進入集團的 VPC 網路中，先透過一個統一接入 Ingress-Tengine 閘道器，他可以將域名解析並路由到不同的機房、單元等。本週我們也同步更新了 [Tengine 2.3.3](https://github.com/alibaba/tengine/releases/tag/2.3.3) 版本，核心升級到 Nginx Core 1.18.0 ，支援 Dubbo 協議 ，支援 DTLSv1 和 DTLSv1.2，支援 Prometheus 格式，從而提升阿里雲微服務生態完整性、安全性、可觀測性。

透過統一接入層閘道器後，使用者請求會透過 Ingress-Envoy 微服務閘道器，轉發到對應的微服務中，並進行呼叫。如果需要呼叫到其他網路域的服務，會透過 Ingress-Envoy 微服務閘道器將流量匯入到對應的 VPC 網路中，從而打通不同安全域、網路域和業務域的服務。

微服務之間的相互呼叫，會透過 Envoy Sidecar 或傳統的微服務自訂閱的方式進行。最終，使用者請求在各個微服務的互相呼叫中，完成並返回給使用者。

## 2. Nacos 2.X 的規劃
Nacos2.X 將在 2.0 解決效能問題的基礎上，透過外掛化實現新的功能並改造大量舊功能，使得 Nacos 能夠更方便，更易於擴充。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/c9ca78dfea414789806419152b16b28a.png)

# 總結
Nacos2.0 作為一個跨代版本，徹底解決了 Nacos1.X 的效能問題，將效能提升了 10 倍。並且透過抽象和分層讓架構更加簡單，透過外掛化更好的擴充套件，讓 Nacos 能夠支援更多場景，融合更廣生態。相信 Nacos2.X 在後續版本迭代後，會更加易用，解決更多微服務問題，並向著 Mesh 化進行更深入地探索。

## 加入我們
歡迎大家在 **Nacos Github **上提交 issue 與 PR 進行討論和貢獻，或加入 Nacos 社群群參與社群討論。也趁此機會感謝參與 Nacos 貢獻的 200+小夥伴！感謝你們對中國開源事業的推動 ！

**Nacos Github**：[_https://github.com/alibaba/nacos_](https://github.com/alibaba/nacos)

除了參與開源，我們也歡迎更多有能力及有意願的同學加入阿里雲共建雲原生，詳情可檢視職位連結：
[_https://job.alibaba.com/zhaopin/position_detail.htm?trace=qrcode_share&positionCode=GP708029_](https://job.alibaba.com/zhaopin/position_detail.htm?trace=qrcode_share&positionCode=GP708029)

重磅官宣：Nacos2.0 釋出，效能提升 10 倍

相關文章