重磅官宣：Nacos2.0發(fā)布，性能提升10倍

作者 | 席翁

繼 Nacos 1.0 發(fā)布以來，Nacos 迅速被成千上萬家企業(yè)采用，并構建起強大的生態(tài)。但是隨著用戶深入使用，逐漸暴露一些性能問題，因此我們啟動了 Nacos 2.0 的隔代產(chǎn)品設計，時隔半年我們終于將其全部實現(xiàn)，實測性能提升 10 倍，相信能滿足所有用戶的性能需求。下面由我代表社區(qū)為大家介紹一下這款跨代產(chǎn)品。

Nacos 簡介

Nacos 是一個更易于構建云原生應用的動態(tài)服務發(fā)現(xiàn)、配置管理和服務管理平臺。它孵化于阿里巴巴，成長于十年雙十一的洪峰考驗，沉淀了簡單易用、穩(wěn)定可靠、性能卓越的核心競爭力。

Nacos 2.0 架構

全新 2.0 架構不僅將性能大幅提升 10 倍，而且內(nèi)核進行了分層抽象，并且實現(xiàn)插件擴展機制。

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

• 通信層統(tǒng)一到 gRPC 協(xié)議，同時完善了客戶端和服務端的流量控制和負載均衡能力，提升的整體吞吐。

• 將存儲和一致性模型做了充分抽象分層，架構更簡單清晰，代碼更加健壯，性能更加強悍。

• 設計了可拓展的接口，提升了集成能力，如讓用戶擴展實現(xiàn)各自的安全機制。

1. Nacos2.0 服務發(fā)現(xiàn)升級一致性模型

Nacos2.0 架構下的服務發(fā)現(xiàn)，客戶端通過 gRPC，發(fā)起注冊服務或訂閱服務的請求。服務端使用 Client 對象來記錄該客戶端使用 gRPC 連接發(fā)布了哪些服務，又訂閱了哪些服務，并將該 Client 進行服務間同步。由于實際的使用習慣是服務到客戶端的映射，即服務下有哪些客戶端實例；因此 2.0 的服務端會通過構建索引和元數(shù)據(jù)，快速生成類似 1.X 中的 Service 信息，并將 Service 的數(shù)據(jù)通過  gRPC Stream 進行推送。

2. Nacos2.0 配置管理升級通信機制

配置管理之前用 Http1.1 的 Keep Alive 模式 30s 發(fā)一個心跳模擬長鏈接，協(xié)議難以理解，內(nèi)存消耗大，推送性能弱，因此 2.0 通過 gRPC 徹底解決這些問題，內(nèi)存消耗大量降低。

3. Nacos2.0 架構優(yōu)勢

 Nacos2.0 大幅降低了資源消耗，提升吞吐性能，優(yōu)化客戶端和服務端交互，對用戶更加友好；雖然可觀測性略微下降，但是整體性價比非常高。

由于 Nacos 由服務發(fā)現(xiàn)和配置管理兩大模塊構成，業(yè)務模型略有差異，因此我們下面分別介紹一下具體壓測指標。

1. Nacos2.0 服務發(fā)現(xiàn)的性能提升

服務發(fā)現(xiàn)場景我們主要關注客戶端數(shù)，服務數(shù)實例數(shù)，及服務訂閱者數(shù)在大規(guī)模場景下，服務端在同步，推送及穩(wěn)定狀態(tài)時的性能表現(xiàn)。同時還關注在有大量服務在進行上下線時，系統(tǒng)的性能表現(xiàn)。

• 容量及穩(wěn)定狀態(tài)測試

該場景主要關注隨著服務規(guī)模和客戶端實例規(guī)模上漲，系統(tǒng)性能表現(xiàn)。

可以看到 2.0.0 版本在 10W 級客戶端規(guī)模下，能夠穩(wěn)定的支撐，在達到穩(wěn)定狀態(tài)后，CPU 的損耗非常低。雖然在最初的大量注冊階段，由于存在瞬時的大量注冊和推送，因此有一定的推送超時，但是會在重試后推送成功，不會影響數(shù)據(jù)一致性。

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

• 頻繁變更測試

該場景主要關注業(yè)務大規(guī)模發(fā)布，服務頻繁推送條件下，不同版本的吞吐和失敗率。

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

2. Nacos2.0 配置管理的性能提升

由于配置是少寫多讀場景，所以瓶頸主要在單臺監(jiān)聽的客戶端數(shù)量以及配置的推送獲取上，因此配置管理的壓測性能主要集中于單臺服務端的連接容量以及大量推送的比較。

• Nacos2.0 連接容量測試

該場景主要關注不同客戶端規(guī)模下的系統(tǒng)壓力。

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

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

• Nacos2.0 頻繁推送測試

該場景關注不同推送規(guī)模下的系統(tǒng)表現(xiàn)。

在頻繁變更的場景，兩個版本都處于 6000 個客戶端連接中。明顯可以發(fā)現(xiàn) 2.0 版本的性能損耗要遠低于 1.X 版本。在 3000tps 的推送場景下，優(yōu)化程度約優(yōu)化了 3 倍。

3. Nacos2.0 性能結論

針對服務發(fā)現(xiàn)場景，Nacos2.0 能夠在 10W 級規(guī)模下，穩(wěn)定運行；相比 Nacos1.X 版本的 1.2W 規(guī)模，提升約 10 倍。

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

Nacos 生態(tài)及 2.X 后續(xù)規(guī)劃

隨著 Nacos 三年的發(fā)展，幾乎支持了所有的 RPC 框架和微服務生態(tài)，并且引領云原生微服務生態(tài)發(fā)展。

Nacos 是整個微服務生態(tài)中非常核心的組件，它可以無縫和 K8s 服務發(fā)現(xiàn)體系互通，通過 MCP/XDS 協(xié)議與 Istio 通信，將 Nacos 服務下發(fā) Sidecar；同樣也可以和 CoreDNS 聯(lián)合，將 Nacos 服務通過域名模式暴露給下游調(diào)用。

Nacos 目前已經(jīng)和各類微服務 RPC 框架融合進行服務發(fā)現(xiàn)；另外可以協(xié)助高可用框架 Sentinel 進行各類管理規(guī)則的控制和下發(fā)。

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

最后，Nacos 還可以和各類微服務網(wǎng)關打通，實現(xiàn)接入層的分發(fā)和微服務調(diào)用。

1. Nacos 生態(tài)在阿里的實踐

目前 Nacos 已經(jīng)完成了自研、開源、商業(yè)化三位一體的建設，阿里內(nèi)部的釘釘、考拉、餓了么、優(yōu)酷等業(yè)務域已經(jīng)全部采用云產(chǎn)品 MSE 中的 Nacos 服務，并且與阿里和云原生的技術棧無縫整合。下面我們以釘釘為例簡單做一下介紹。

Nacos 運行在微服務引擎 MSE（全托管的 Nacos 集群）上，進行維護和多集群管理；業(yè)務的各類 Dubbo3 或 HSF 服務在啟動時，通過 Dubbo3 自身注冊到 Nacos 集群中；然后 Nacos 通過 MCP 協(xié)議將服務信息同步到 Istio 和 Ingress-Envoy 網(wǎng)關。

用戶流量從北向進入集團的 VPC 網(wǎng)絡中，先通過一個統(tǒng)一接入 Ingress-Tengine 網(wǎng)關，他可以將域名解析并路由到不同的機房、單元等。本周我們也同步更新了Tengine 2.3.3 版本，內(nèi)核升級到 Nginx Core 1.18.0 ，支持 Dubbo 協(xié)議 ，支持 DTLSv1 和 DTLSv1.2，支持 Prometheus 格式，從而提升阿里云微服務生態(tài)完整性、安全性、可觀測性。

通過統(tǒng)一接入層網(wǎng)關后，用戶請求會通過 Ingress-Envoy 微服務網(wǎng)關，轉發(fā)到對應的微服務中，并進行調(diào)用。如果需要調(diào)用到其他網(wǎng)絡域的服務，會通過 Ingress-Envoy 微服務網(wǎng)關將流量導入到對應的 VPC 網(wǎng)絡中，從而打通不同安全域、網(wǎng)絡域和業(yè)務域的服務。

微服務之間的相互調(diào)用，會通過 Envoy Sidecar 或傳統(tǒng)的微服務自訂閱的方式進行。最終，用戶請求在各個微服務的互相調(diào)用中，完成并返回給用戶。

2. Nacos 2.X 的規(guī)劃

Nacos2.X 將在 2.0 解決性能問題的基礎上，通過插件化實現(xiàn)新的功能并改造大量舊功能，使得 Nacos 能夠更方便，更易于拓展。

總結

Nacos2.0 作為一個跨代版本，徹底解決了 Nacos1.X 的性能問題，將性能提升了 10 倍。并且通過抽象和分層讓架構更加簡單，通過插件化更好的擴展，讓 Nacos 能夠支持更多場景，融合更廣生態(tài)。相信 Nacos2.X 在后續(xù)版本迭代后，會更加易用，解決更多微服務問題，并向著 Mesh 化進行更深入地探索。