Nacos
Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。
Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平台。 Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務范式、雲原生范式) 的服務基礎設施。
以上摘自nacos官網之官方介紹
詳細請上官網查看，附鏈接：https://nacos.io/zh-cn/index.html
概念&分析
我們都知道 Nacos Config Server 是Nacos實現統一配置管理的核心服務，那么當服務上的配置發生變化時，需要讓相關的應用程序感知配置的變化進而實現應用的變化，這就需要客戶端針對感興趣的配置實現監聽，從而做出相應的更改。那么Nacos客戶端是如何實現配置變更的實時更新呢？
一般來說，客戶端和服務端之間的數據交互無非兩種方式：Pull 和 Push。
- Pull 表示客戶端從服務端主動拉取數據。
- Push 表示服務端主動把數據推送給客戶端。
這兩種方式沒有什么優劣之分，只是看哪種方式更適合於當前的場景。大多數會支持 Push 和 Pull 兩種模式，用戶可以在不同的特定場景下選擇不同的方式來獲取數據。
對於 Push 模式來說，服務端需要維持與客戶端的長連接，如果客戶端的數量比較多，那么服務端需要耗費大量的內存資源來保存每個連接，並且為了檢測長連接的有效性，還需要心跳機制來維持每個連接的狀態。
在 Pull 模式下，客戶端需要定時從服務端拉取一次數據，由於定時任務會存在一定的時間間隔，所以不能保證數據的實時性。並且在服務端配置長時間不更新的情況下，客戶端的定時任務會做一些無效的 Pull。
當然，如果你的應用本身就需要實時通信或者本身需要長連接（一直保持連接，如 socket 連接）來支撐業務，那么 Push 無疑是最優選的模式。但如果僅部分功能或者業務需要實現實時更新就沒必要為這來建立長連接實現，對此小編建議采用 Nacos 的這種方式即使用 Pull 模式來實現此需求。
Nacos 下的方式
Nacos 采用的是 Pull 模式，但並不是簡單的 Pull，而是一種長輪訓機制，它結合 Push 和 Pull 兩者的優勢。客戶端采用長輪訓的方式定時發起 Pull 請求，去檢查服務端配置信息是否發生了變更，如果發生了變更，則客戶端會根據變更的數據獲得最新的配置。所謂的長輪訓，是客戶端發起輪訓請求之后，服務端如果有配置發生變更，就直接返回，如圖所示。
參考文檔
如果客戶端發起 Pull 請求后，發現服務端的配置和客戶端的配置是保持一致的，那么服務端會先 “Hold” 住這個請求，也就是服務端拿到這個連接之后在指定的時間段內一直不返回結果，直到這段時間內配置發生變化，服務端會把原來 “Hold” 住的請求進行返回。Nacos 服務端收到請求之后，先檢查配置是否發生了變更，如果沒有，則設置一個定時任務，延期 29.5s 執行，並且把當前的客戶端長輪訓加入 allSubs 隊列。這個時候有兩種方式觸發該鏈接結果的返回：
- 第一種是在等待 29.5s 后觸發自動檢查機制，這個時候不管配置有沒有發生變化，都會把結果返回客戶端。而 29.5s 就是這個長連接保持的時間。
- 第二種是在 29.5s 內任意一個時刻，通過 Nacos Dashboard 或者 API 的方式對配置進行了修改，這會觸發一個事件機制，監聽該事件的任務會遍歷 allSubs 隊列，找到發生變更的配置項對應的 ClientLongPolling 任務，將變更的數據通過該任務的連接進行返回，就完成一次 “推送” 操作。
這樣既能夠保證客戶端實時感知配置的變化，也降低了服務端的壓力。其中，這個長連接的回話超時時間默認是 30s。
總結
我們在自己的項目中不乏會遇到類似的應用場景，當我們在 Pull 和 Push 之間難以抉擇時，不妨使用 Nacos 的設計方式來實現，既能實現我們所需要的功能需求，又能降低客戶端和服務端的壓力，同時該方式實現起來也沒有什么技術難度，開發簡單，何樂而不用呢。
小編推薦在相同的應用場景下使用此方式，不推薦使用復雜度較高的長連接通信，這樣做對於項目來說其實是得不償失。
歡迎評論
TopSkyhua