重磅官宣：Nacos2.0發佈，性能提高10倍

簡介： ​Nacos2.0 做爲一個跨代版本，完全解決了 Nacos1.X 的性能問題，將性能提高了 10 倍。

做者：席翁

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

Nacos 簡介

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

Nacos 2.0 架構

全新2.0 架構不只將性能大幅提高10倍，並且內核進行了分層抽象，而且實現插件擴展機制。

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

• 通訊層統一到gRPC協議，同時完善了客戶端和服務端的流量控制和負載均衡能力，提高的總體吞吐。
• 將存儲和一致性模型作了充分抽象分層，架構更簡單清晰，代碼更加健壯，性能更增強悍。
• 設計了可拓展的接口，提高了集成能力，如讓用戶擴展實現各自的安全機制。

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

Nacos2架構下的服務發現，客戶端經過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大幅下降了資源消耗，提高吞吐性能，優化客戶端和服務端交互，對用戶更加友好；雖然可觀測性略微降低，可是總體性價比很是高。

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 鏈接容量測試

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

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倍。

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

Nacos 2.X的規劃

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

總結

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

原文連接本文爲阿里雲原創內容，未經容許不得轉載。