作者 | 席翁
來源 |
阿裡巴巴雲原生公衆号繼 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 化進行更深入地探索。
加入我們
歡迎大家在 Nacos Github 上送出 issue 與 PR 進行讨論和貢獻，或加入 Nacos 社群群參與社群讨論。也趁此機會感謝參與 Nacos 貢獻的 200+小夥伴！感謝你們對中國開源事業的推動 ！
Nacos Github：
https://github.com/alibaba/nacos除了參與開源，我們也歡迎更多有能力及有意願的同學加入阿裡雲共建雲原生，詳情可檢視職位連結：
https://job.alibaba.com/zhaopin/position_detail.htm?trace=qrcode_share&positionCode=GP708029