Nacos 項目起源于阿里巴巴內部的五彩石項目，從 2008 年開始，就已經在內部孵化了。近年來受 Eureka、Consul 等項目的影響，Nacos 越來越受歡迎！

目前 Nacos 支持主流微服務開發(fā)語言&主流服務框架和配置管理框架，比如支持 Duboo、SpringCloud、SCA，還對接了一些云原生的組件比如 coreDNS 和 sentinel 等。

客戶端語言方面目前支持 Java，go python 等主流語言，最近剛發(fā)布正式版本的還支持 C# 和 C++。

最近 Nacos 更新動作頻頻，Nacos 2.X 版本迎來了首秀，在 1.X 的架構基礎上新增了對長連接模型的支持。通信層目前通過 grpc 實現(xiàn)了長連接 RPC 調用和推送能力，使用長鏈接的好處大幅度減少了 1.x 輪詢心跳頻繁導致 JVM Full GC。

1.X架構存在的問題

接下來看一下 Nacos1.X 架構所面臨的幾個比較重要的問題。

一句話總結，心跳多，無效查詢多，心跳續(xù)約感知變化慢，連接消耗大，資源空耗嚴重。

圖片

心跳數(shù)量多，導致 TPS 居高不下

通過心跳續(xù)約，當服務規(guī)模上升時，特別是類似 Dubbo 的接口級服務較多時，心跳及配置元數(shù)據(jù)的輪詢數(shù)量眾多，導致集群 TPS 很高，系統(tǒng)資源高度空耗。

通過心跳續(xù)約感知服務變化，時延長

心跳續(xù)約需要達到超時時間才會移除并通知訂閱者，默認為 15 s，時延較長，時效性差。若改短超時時間，當網(wǎng)絡抖動時，會頻繁觸發(fā)變更推送，對客戶端服務端都有更大損耗。

UDP 推送不可靠，導致 QPS 居高不下

由于 UDP 不可靠，因此客戶端測需要每隔一段時間進行對賬查詢，保證客戶端緩存的服務列表的狀態(tài)正確，當訂閱客戶端規(guī)模上升時，集群 QPS 很高，但大多數(shù)服務列表其實不會頻繁改變，造成無效查詢，從而存在資源空耗。

基于 HTTP 短連接模型，TIME_WAIT 狀態(tài)連接過多

HTTP 短連接模型，每次客戶端請求都會創(chuàng)建和銷毀 TCP 鏈接，TCP 協(xié)議銷毀的鏈接狀態(tài)是 WAIT_TIME，完全釋放還需要一定時間，當 TPS 和 QPS 較高時，服務端和客戶端可能有大量的 WAIT_TIME 狀態(tài)鏈接，從而會導致 connect time out 錯誤或者 Cannot assign requested address 的問題。

配置模塊的 30 秒長輪詢引起的頻繁 GC

配置模塊使用 HTTP 短連接阻塞模型來模擬長連接通信，但是由于并非真實的長連接模型，因此每 30 秒需要進行一次請求和數(shù)據(jù)的上下文切換，每一次切換都有引起造成一次內存浪費，從而導致服務端頻繁 GC。

Nacos 2.x 架構的優(yōu)缺點

前面簡要介紹了 Nacos 2.x 的架構和新模型的工作方式，接下來我們分析一下這樣的改動有哪些優(yōu)缺點。

圖片

優(yōu)點

客戶端不再需要定時發(fā)送實例心跳，只需要有一個維持連接可用 keepalive 消息即可。重復 TPS 可以大幅降低。
TCP 連接斷開可以被快速感知到，提升反應速度。
長連接的流式推送，比 UDP 更加可靠；nio 的機制具有更高的吞吐量，而且由于可靠推送，可以加長客戶端用于對賬服務列表的時間，甚至刪除相關的請求。重復的無效 QPS 可以大幅降低。
長連接避免頻繁連接開銷，可以大幅緩解 TIME_ WAIT 問題。
真實的長連接，解決配置模塊 GC 問題。
更細粒度的同步內容，減少服務節(jié)點間的通信壓力。

缺點

沒有銀彈的方案，新架構也會引入一些新問題

內部結構復雜度上升，管理連接狀態(tài)，連接的負載均衡需要管理。
數(shù)據(jù)由原來的無狀態(tài)，變?yōu)榕c連接綁定的有狀態(tài)數(shù)據(jù)，流程鏈路更長。
RPC 協(xié)議的觀測性不如 HTTP。即使 gRPC 基于 HTTP2.0 Stream 實現(xiàn)，仍然不如直接使用 HTTP 協(xié)議來的直觀。

性能提升

Nacos 2.x 服務發(fā)現(xiàn)性能測試都是針對重點功能，通過對 3 節(jié)點規(guī)模集群進行壓測，可以看到接口性能負載和容量，以及對比相同/類似場景下 Nacos1.X 版本的提升。

壓測時服務及實例容量達到百萬級，集群運行持續(xù)穩(wěn)定，達到預期；（該場景沒有計算頻繁變更導致的頻繁推送內容，僅單純計算容量上線，附帶推送的真實場景將在下輪壓測報告中給出）
注冊/注銷實例 TPS 達到 26000 以上，總體較 Nacos1.X 提升至少 2 倍，接口達到預期；
查詢實例 TPS 能夠達到 30000 以上，總體較 Nacos1.X 提升 3 倍左右，接口達到預期；

兼容性

配置中心

完全兼容 1.X 客戶端所有 API 接口方法
完全實現(xiàn) 2.X 客戶端所有 API 接口方法
完全兼容所有配置中心相關 openAPI

服務發(fā)現(xiàn)

由于服務發(fā)現(xiàn)的數(shù)據(jù)模型發(fā)生了比較重大的改變，因此以下功能暫時未支持。

查看當前集群 leader（將廢棄）
批量更新實例元數(shù)據(jù)(Beta，不支持)
批量刪除實例元數(shù)據(jù)(Beta，不支持)

控制臺

完全兼容配置中心相關頁面及功能
完全兼容權限控制相關頁面及功能
完全兼容命名空間相關頁面及功能
完全兼容集群管理相關頁面及功能
完全兼容服務發(fā)現(xiàn)相關頁面及功能

Spring Cloud Alibaba 適配

由于目前 Spring cloud alibaba 2.2.5 版本內置的 nacos-client 為 1.4.1，可通過指定 nacos-client 方式，提前使用 Nacos2.0 長連接功能。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>2.2.5.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>com.alibaba.nacos</groupId>
            <artifactId>nacos-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    <version>2.2.5.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>com.alibaba.nacos</groupId>
            <artifactId>nacos-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>2.0.0</version>
</dependency>

最后，期待大家搶先體驗，幫助發(fā)現(xiàn)修復 bug，改善社區(qū)，貢獻智慧，參與 Nacos 開源社區(qū)建設！Nacos 項目起源于阿里巴巴內部的五彩石項目，從 2008 年開始，就已經在內部孵化了。近年來受 Eureka、Consul 等項目的影響，Nacos 越來越受歡迎！

客戶端語言方面目前支持 Java，go python 等主流語言，最近剛發(fā)布正式版本的還支持 C# 和 C++。