簡介： 繼 Nacos 1.0 發布以來，Nacos 迅速被成千上萬家企業采用，並構建起強大的生態。但是隨着用戶深入使用，逐漸暴露一些性能問題，因此我們啟動了 Nacos 2.0 的隔代產品設計，時隔半年我們終於將其全部實現，實測性能提升 10 倍，相信能滿足所有用戶的性能需求。下面由我代表社區為大家介紹一下這款跨代產品。
作者 | 席翁
來源 | 阿里巴巴雲原生公眾號
繼 Nacos 1.0 發布以來，Nacos 迅速被成千上萬家企業采用，並構建起強大的生態。但是隨着用戶深入使用，逐漸暴露一些性能問題，因此我們啟動了 Nacos 2.0 的隔代產品設計，時隔半年我們終於將其全部實現，實測性能提升 10 倍，相信能滿足所有用戶的性能需求。下面由我代表社區為大家介紹一下這款跨代產品。
Nacos 簡介
Nacos 是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平台。它孵化於阿里巴巴，成長於十年雙十一的洪峰考驗，沉淀了簡單易用、穩定可靠、性能卓越的核心競爭力。
Nacos 2.0 架構
全新 2.0 架構不僅將性能大幅提升 10 倍，而且內核進行了分層抽象，並且實現插件擴展機制。
Nacos 2.0 架構層次如下圖，它相比Nacos1.X的最主要變化是：
- 通信層統一到 gRPC 協議，同時完善了客戶端和服務端的流量控制和負載均衡能力，提升的整體吞吐。
- 將存儲和一致性模型做了充分抽象分層，架構更簡單清晰，代碼更加健壯，性能更加強悍。
- 設計了可拓展的接口，提升了集成能力，如讓用戶擴展實現各自的安全機制。
1. Nacos2.0 服務發現升級一致性模型
Nacos2.0 架構下的服務發現，客戶端通過 gRPC，發起注冊服務或訂閱服務的請求。服務端使用 Client 對象來記錄該客戶端使用 gRPC 連接發布了哪些服務，又訂閱了哪些服務，並將該 Client 進行服務間同步。由於實際的使用習慣是服務到客戶端的映射，即服務下有哪些客戶端實例；因此 2.0 的服務端會通過構建索引和元數據，快速生成類似 1.X 中的 Service 信息，並將 Service 的數據通過 gRPC Stream 進行推送。
2. Nacos2.0 配置管理升級通信機制
配置管理之前用 Http1.1 的 Keep Alive 模式 30s 發一個心跳模擬長鏈接，協議難以理解，內存消耗大，推送性能弱，因此 2.0 通過 gRPC 徹底解決這些問題，內存消耗大量降低。
3. Nacos2.0 架構優勢
Nacos2.0 大幅降低了資源消耗，提升吞吐性能，優化客戶端和服務端交互，對用戶更加友好；雖然可觀測性略微下降，但是整體性價比非常高。
Nacos2.0 性能提升
由於 Nacos 由服務發現和配置管理兩大模塊構成，業務模型略有差異，因此我們下面分別介紹一下具體壓測指標。
1. Nacos2.0 服務發現的性能提升
服務發現場景我們主要關注客戶端數，服務數實例數，及服務訂閱者數在大規模場景下，服務端在同步，推送及穩定狀態時的性能表現。同時還關注在有大量服務在進行上下線時，系統的性能表現。
- 容量及穩定狀態測試
該場景主要關注隨着服務規模和客戶端實例規模上漲，系統性能表現。
可以看到 2.0.0 版本在 10W 級客戶端規模下，能夠穩定的支撐，在達到穩定狀態后，CPU 的損耗非常低。雖然在最初的大量注冊階段，由於存在瞬時的大量注冊和推送，因此有一定的推送超時，但是會在重試后推送成功，不會影響數據一致性。
反觀 1.X 版本，在 10W、5W 級客戶端下，服務端完全處於 Full GC 狀態，推送完全失敗，集群不可用；在 2W 客戶端規模下，雖然服務端運行狀態正常，但由於心跳處理不及時，大量服務在摘除和注冊階段反復進行，因此達不到穩定狀態，CPU 一直很高。1.2W 客戶端規模下，可以穩定運行，但穩態時 CPU 消耗是更大規模下 2.0 的 3 倍以上。
- 頻繁變更測試
該場景主要關注業務大規模發布，服務頻繁推送條件下，不同版本的吞吐和失敗率。
頻繁變更時，2.0 和 1.X 在達到穩定狀態后，均能穩定支撐，其中 2.0 由於不再有瞬時的推送風暴，因此推送失敗率歸 0，而 1.X 的 UDP 推送的不穩定性導致了有極小部分推送出現了超時，需要重試推送。
2. Nacos2.0 配置管理的性能提升
由於配置是少寫多讀場景，所以瓶頸主要在單台監聽的客戶端數量以及配置的推送獲取上，因此配置管理的壓測性能主要集中於單台服務端的連接容量以及大量推送的比較。
- Nacos2.0 連接容量測試
該場景主要關注不同客戶端規模下的系統壓力。
Nacos2.0 最高單機能夠支撐 4.2w 個配置客戶端連接，在連接建立的階段，有大量訂閱請求需要處理，因此 CPU 消耗較高，但達到穩態后，CPU 的消耗會變得很低。幾乎沒有消耗。
反觀 Nacos1.X， 在客戶端 6000 時，穩定狀態的 CPU 一直很高，且 GC 頻繁，主要原因是長輪訓是通過 hold 請求來保持連接，每 30s 需要回一次 Response 並且重新發起連接和請求。需要做大量的上下文切換，同時還需要持有所有 Request 和 Response。當規模達到 1.2w 客戶端時，已經無法達到穩態，所以無法支撐這個量級的客戶端數。
- Nacos2.0 頻繁推送測試
該場景關注不同推送規模下的系統表現。
在頻繁變更的場景，兩個版本都處於 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。
Nacos 生態及 2.X 后續規划
隨着 Nacos 三年的發展，幾乎支持了所有的 RPC 框架和微服務生態，並且引領雲原生微服務生態發展。
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 服務，並且與阿里和雲原生的技術棧無縫整合。下面我們以釘釘為例簡單做一下介紹。
Nacos 運行在微服務引擎 MSE（全托管的 Nacos 集群）上，進行維護和多集群管理；業務的各類 Dubbo3 或 HSF 服務在啟動時，通過 Dubbo3 自身注冊到 Nacos 集群中；然后 Nacos 通過 MCP 協議將服務信息同步到 Istio 和 Ingress-Envoy 網關。
用戶流量從北向進入集團的 VPC 網絡中，先通過一個統一接入 Ingress-Tengine 網關，他可以將域名解析並路由到不同的機房、單元等。本周我們也同步更新了 Tengine 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 能夠更方便，更易於拓展。
總結
Nacos2.0 作為一個跨代版本，徹底解決了 Nacos1.X 的性能問題，將性能提升了 10 倍。並且通過抽象和分層讓架構更加簡單，通過插件化更好的擴展，讓 Nacos 能夠支持更多場景，融合更廣生態。相信 Nacos2.X 在后續版本迭代后，會更加易用，解決更多微服務問題，並向着 Mesh 化進行更深入地探索。