重磅官宣：Nacos2-0 發佈，性能提升 10 倍

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

Nacos 簡介

Nacos 2.0 架構

 

Nacos2.0 服務發現升級一致性模型

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

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

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

Nacos2.0 架構優勢

Nacos2.0 性能提升

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

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 推送的不穩定性導致了有極小部分推送出現了超時，需要重試推送。

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

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

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

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

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

在頻繁變更的場景，兩個版本都處於 6000 個客戶端連接中。明顯可以發現 2.0 版本的性能損耗要遠低於 1.X 版本。在 3000tps 的推送場景下，優化程度約優化了 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 還可以和各類微服務網關打通，實現接入層的分發和微服務調用。

Nacos 生態在阿里的實踐

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

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 或傳統的微服務自訂閱的方式進行。最終，用戶請求在各個微服務的互相調用中，完成並返回給用戶。

Nacos 2.X 的規劃

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

總結

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

**Nacos Github ：**https://github.com/alibaba/nacos

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/dBVo6w0sjUORd6Axpj3zTg

猜你喜歡