SpringCloud -- Nacos詳細介紹

5. Nacos

5.1 Nacos介紹

Nacos 可以理解為微服務的“電話簿 + 遙控器”。它是阿里巴巴開源的一個核心工具，主要解決微服務架構中的兩大問題：

5.1.1 服務注冊與發現（電話簿）

服務注冊：當某個微服務（比如“訂單服務”）啟動時，它會自動到 Nacos “登記”自己的位置（IP 和端口），就像在電話簿里存電話號碼2410。
服務發現：其他微服務（比如“支付服務”）需要調用“訂單服務”時，不用硬編碼對方的地址，直接問 Nacos：“訂單服務在哪？” Nacos 會返回健康的實例地址38。
健康檢查：Nacos 會定時“打電話”檢查服務是否活著，掛了就踢出列表，避免請求發到故障節點26。

5.1.2 動態配置管理（遙控器）

微服務通常有很多配置（如數據庫地址、開關參數）。傳統做法是改配置→重啟服務，而 Nacos 允許配置集中托管。
修改配置后，Nacos 會實時推送給所有相關服務，無需重啟，像用遙控器調設置一樣方便249。
支持多環境隔離（開發/生產配置分開）、版本回滾等企業級功能910。

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.2 Nacos快速入門

5.2.1 下載

https://github.com/alibaba/nacos/releases/download/2.2.3/nacos-server-2.2.3.zip

5.2.2 解壓加配置

解壓后修改配置文件里面的配置信息

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

修改項：

`nacos.core.auth.plugin.nacos.token.secret.key="VGhpc0lzTXlDdXN0b21TZWNyZXRLZXkwMTIzNDU2Nzg="`
nacos.core.auth.enabled=true
nacos.core.auth.server.identity.key="touper"
nacos.core.auth.server.identity.value="touper"

5.2.3 啟動和訪問

啟動

在 bin 目錄下進入命令行然后輸入指令：startup -m standalone

訪問

訪問地址：http://localhost:8848/nacos/

登錄賬號和密碼都是：nacos

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.2.4 服務注冊

服務注冊簡介

服務只要導入部分依賴和添加少許配置，啟動項目就會自動實現服務中心注冊

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

采用父子工程模式

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

父工程進行微服務依賴的版本管理

子工程需要這個依賴只要導入依賴不需要版本信息

<properties><maven.compiler.source>17</maven.compiler.source><maven.compiler.target>17</maven.compiler.target><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><!--版本管理--><spring-cloud.version>2022.0.0</spring-cloud.version><spring-cloud-alibaba.version>2022.0.0.0</spring-cloud-alibaba.version>
</properties>
<dependencyManagement><dependencies><!--Web起步依賴--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>3.0.2</version></dependency><!--SpringCloud依賴--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>${spring-cloud.version}</version><type>pom</type><scope>import</scope></dependency><!--alibaba 對 springCloud 做了擴展--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>${spring-cloud-alibaba.version}</version><type>pom</type><scope>import</scope></dependency></dependencies>
</dependencyManagement>

子工程導入依賴

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency><!--消費者服務還需要導入負載均衡依賴-->    
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>

子工程編寫配置

Spring:application:name: provider-service-rest #服務名cloud:nacos:discovery:server-addr: localhost:8848 #nacos端口password: nacos #認證密碼username: nacos #認證賬號

消費者要在 restTemplate 配置類上加上負載均衡注解

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.3 Nacos臨時實例和持久實例

5.3.1 臨時實例和持久實例的轉換

在 Nacos Client 進行實例注冊的時候，默認設置為臨時實例

1. 要實現臨時實例和持久實例之間的轉換首先要修改配置

spring:clound:nacos:discovery:ephemeral: false

2. 將原有實例銷毀

先將Nacos服務停掉
在 nacos 目錄下 \data\protocol\raft，刪除下面的文件夾
再次重啟 nacos 服務,發現臨時實例為 false，表示現在是持久實例

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.3.2 臨時實例和持久實例的區別

特性	持久實例	臨時實例
生命周期	手動注冊，手動注銷	手動注冊，自動注銷（心跳超時）
健康檢查	Nacos Server 主動探測	服務實例主動發送心跳
宕機處理	標記為不健康，但不刪除	自動刪除
適用場景	關鍵基礎設施（DB, Cache, MQ）	動態業務微服務實例
類比	長租租客（不退租記錄在）	酒店客人（不續卡自動退房）
核心優勢	信息持久化，手動控制力強	自動容錯清理，動態性好
主要缺點	需手動注銷，可能堆積無效節點	依賴心跳網絡，存在短暫不一致性

存在的核心意義：

持久實例： 為了保留信息。 確保關鍵服務的位置信息被持久記錄，即使服務暫時不可用，也方便運維查看、排查和手動干預。它犧牲了一定的自動化，換來了信息的持久性和強控制力。
臨時實例： 為了動態性和自愈能力。 適應現代應用快速變化、彈性伸縮的需求，自動處理實例故障，保證服務列表的實時性和可用性。它是構建高可用、可擴展微服務架構的基石。

簡單來說：想讓它“掛了也要留個名”（持久實例），還是“掛了就消失別礙事”（臨時實例）？ Nacos 通過這兩種類型，讓你能根據服務的不同性質和重要性，靈活地管理服務實例的生命周期和可見性。臨時實例是現代微服務的默認選擇，而持久實例則用于那些需要特殊關照的“基石”服務。

5.4 Nacos保護閾值

保護閾值是 Nacos 在健康實例比例過低時觸發的“保命機制”，通過臨時返回不健康實例，防止因少數健康實例被壓垮而導致服務完全崩潰。 這些不健康的實例主要起到分流的作用，防止所有請求都打到健康的實例上，到時健康的實例也被壓垮致使這個服務的所有實例癱瘓，服務無法使用

可以理解為：當健康的“士兵”太少時，指揮官（Nacos）會讓“輕傷員”也上戰場，避免防線徹底失守。🪖??

5.5 Nacos權重

權重是一種數值類型，通常取值范圍在0到100之間，表示服務器的負載情況。在權重相同的情況下，Nacos默認使用輪詢算法實現負載均衡，按照順序依次輪詢選擇服務實例。

在服務治理中，負載均衡是一個非常常見的場景。通過設置每個服務實例的權重，可以請求更合理、均衡地分配到每個實例上，從而實現負載均衡的目的。

1. 修改實例的權重

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

2. 在調用端的配置文件上加入

spring:cloud:loadbalancer:nacos:enabled: true

5.6 Nacos命名空間和分組

5.6.1 簡介

我們可以通過命名空間和分組來對不同服務做隔離操作（不同的項目在不同的命名空間下），服務之間訪問必須在一個命名空間一個組內。這樣實現服務隔離的效果。這些如果不設置都有默認值

5.6.2 設置命名空間處理

步驟1：先在 nacos 中創建一個命名空間

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

步驟2：在模塊中配置 yml 文件

spring:cloud:nacos:discovery:namespace: 1849a19c-ca38-4c3b-ba71-9fde8198e7ec

步驟3：在nacos中可以看到命名空間對服務的區分

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.6.3 設置組的處理

只要在配置文件中配置組名即可

spring:cloud:nacos:discovery:group: dev

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.7 Nacos集群管理

**在實際開發過程中，如果使用Nacos，為了確保高可用，一般都會對其進行集群的部署。**Nacos規定集群中，Nacos節點的數量需要大于等于3個節點，同時，單機模式下，naocs的數據默認保存在內嵌數據庫中derby，不方便觀察數據庫存儲的基本情況。而且如果集群中啟動多個默認配置下的nacos節點，數據存儲存在一致性問題。為了解決這個問題，nacos采用了集中式存儲的方式來支持集群化部署，目前只支持mysql的存儲

5.7.1 使用 Mysql 存儲 Nacos

步驟1：創建數據庫和表

創建2數據庫后然后執行在 nacos 目錄下 / conf / mysql-schema.sql 下的 Sql 腳本來創建表

步驟2：修改 application.properties 文件

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

步驟3：啟動 nacos 驗證

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

6.14.2 集群管理

我們這里使用一臺電腦來模擬集群效果

步驟1：先創建一個 cluster 目錄，復制三個 nacos 目錄，分別命名不同端口號

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

步驟2：根據 cluster.conf.example 模板進行創建一個 cluster.conf 文件

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

步驟3：修改 application.properties 將端口號修改到對應的值

步驟4：啟動 nacos，指令 startup，因為是集群啟動方式，所以不需要有-m standalone參數

步驟5：訪問 localhost:8858/nacos，或者 localhost:8868/nacos 或者 localhost:8878/nacos

步驟6：使用 nginx 反向代理

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

注意1：

我們啟動 Nacos 部署所占用的端口實際上會有三個

會根據一定端口偏移量占用其他的端口，如 8848 偏移 1000 會占 9848。所以如果在一個服務器上，多端口模擬 nacos 集群，端口之間，不能緊相鄰，要有一定間距

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

注意2：

如果集群不是使用mysql進行數據存儲,啟動時，指令后需要加 -p embedded

5.8 CAP理論

5.8.1簡單介紹

CAP理論是分布式系統中最基礎的理論，即一個分布式系統最多只能同時滿足下面三種中的兩種

一致性(Consistency)、
可用性(Avaliability)
分區容錯性(Partition tolerance)

1. 一致性

對于客戶端每次讀操作，要么讀到的是最新的數據，要么讀取失敗。站在分布系統的角度，對客戶端的承諾，要么返回絕對一致的最新數據，要么返回一個錯誤，強調的是數據正確。一致性可以分為兩種情況

強數據一致性：數據在各個節點之間隨時保持完全一致，對數據的操作要么成功，要么失敗
最終數據一致性：數據在各個節點之間在時間閾值內同步成功，保持數據的最終一致性

2. 可用性

任何客戶端的請求，都要返回響應數據，不會出現響應錯誤。一定會返回數據，不會返回給錯誤，但不能保證數據最新，強調的是服務不出錯

3. 分區容錯性

由于分布式系統，通過網絡進行通信，網絡是不可靠的。當任意數量的消息丟失或延遲到達時，系統仍會繼續提供服務，不會出現宕機問題。要求一定會一直運行，不管內部出現何種數據同步問題，強調的是不宕機，不掛掉。

對于一個分布系統而言，P 是前提條件，是必須要保證的。只要有網絡交互，就一定會有延遲和數據丟失情況，我們必須接受，保證系統不能掛掉。對于 A 和 C 需要進行選擇，要么保證數據一致性，要么保證系統可用性。

當選擇C時，如果由于網絡分區而無法保證特定信息是最新的，則系統將返回錯誤或超時。

當選擇A時，系統將始終處理客戶端的查詢并嘗試返回最新的可用的數據，即使由于網絡分區而無法保證數據是最新的，也會返回一個可用數據。

5.9 Nacos支持模式

5.9.1 簡單介紹

Nacos 支持 CP+AP 模式，使用 nacos 可以根據配置識別為 CP模式或 AP模式，默認是AP模式。

如果注冊 nacos 的 client 節點 ephemeral=true，表示使用臨時實例，nacos集群對這個client節點效果就是AP，采用 distro 協議實現(是nacos對于臨時實例數據開發的一種一致性協議，其數據存儲在緩存中，并會在啟動時進行全量數據同步，并定期進行數據校驗)。
如果注冊 nacos 的 client 節點 ephemeral=false，表示使用持久實例，nacos 集群對這個 client 節點效果就是CP，采用 raft 協議實現。

5.9.2 .使用場景

對于一些數據一致性應該是首先被保證的業務場景（如銀行項目），會遵循 CP 原則。
對于一些數據一致性較差的的情況但是也不會造成災難性的結果，會遵循 AP 原則。

總之，服務注冊中心到底選用CP還是AP，是根據業務場景決定。如果要求數據一致性很高，且可以容忍一定時間的不可用，可以選用CP模型。如果可以容忍一定時間延遲的數據不一致性，但不能容忍系統不可用，要選用AP模型

5.10 Nacos配置中心

5.10.1 配置中心的簡介

🔧 為什么需要配置中心？——微服務的「集中控制室」

想象你管理著 10 個連鎖奶茶店（微服務），突然要更換牛奶供應商（修改配置）。傳統方式需要跑遍每個店修改配方（配置文件），而配置中心就像總部遙控系統——一鍵修改，所有門店立即生效！

🧩 傳統配置的四大痛點 vs Nacos 的解決方案

痛點場景	生活比喻	Nacos 如何解決
1. 配置文件分散難管理	分店配方各自存放，總部無法統一調整	? 集中化管理：所有配置存到云端「保險柜」，統一查看/修改
2. 多環境配置混亂	試喝版/正式版配方混在一起容易出錯	? 環境隔離：用不同「密碼箱」（命名空間）隔離開發/測試/生產環境配置
3. 改配置必須重啟服務	換原料就要關店裝修，損失客流量	? 熱更新：修改配方后自動推送，店鋪（服務）無需停業立即生效
4. 配置泄露無防護	配方被競爭對手輕易竊取	? 權限保險：給店員（開發者）分不同鑰匙（賬號權限），敏感配方（數據庫密碼）只有店長能查看

💡 Nacos 配置中心的本質價值

把散落各處的「服務配方」收進智能保險箱，實現：
? 集中管控 + 🌈 環境隔離 + ? 實時生效 + 🔒 安全防護

典型應用場景

秒級切換功能開關（如促銷活動上線）
緊急更換數據庫密碼（無需停服）
動態調整線程池參數（應對流量高峰）
安全管控敏感配置（財務系統訪問密鑰）

5.10.2 配置中心數據同步模式

🚀 Push模式（推送式）

工作方式：
客戶端與服務端建立 TCP長連接（如對講機常開通道），配置變更時服務端主動推送新數據到客戶端。
? 優勢：

實時性強（毫秒級生效）
客戶端邏輯簡單（只需接收處理）

? 挑戰：

長連接可能因網絡故障"假死"
需心跳機制保活（如每隔30秒發送"我在線"信號）

🔍 Pull模式（拉取式）

1?? 短輪詢（原始版）

工作方式：
客戶端定時（如每秒）向服務端主動請求配置（像不停打電話問"有更新嗎？"）。
?? 缺陷：

實時性差（最多延遲一個周期）
服務端壓力大（90%請求是無效查詢）
資源浪費（如10秒輪詢時，第11秒更新的配置需等9秒生效）

2?? 長輪詢（智能升級版）?

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

工作方式：

客戶端發起請求后，服務端不立即響應
兩種結束條件：
- 有變更：立即返回新數據（如等待3秒時第2秒發生變更）
- 超時無變更：空響應后客戶端重新發起（如等待30秒無變化）

? 優勢：

實時性接近Push（通常等待30秒內）
服務端壓力驟降（無變更時不頻繁響應）
容錯性強（適應網絡波動）

🔧 Nacos的實戰策略

配置中心通常會提供配置變更、配置推送、歷史版本管理、灰度發布等功能。通過這些功能，可以降低分布式系統中管理配置信息的成本，降低因為錯誤的配置信息變更帶來的服務可用性下降和發生故障的風險。

灰度發布：
像「新品試吃」——先讓1%用戶嘗新配置，驗證無問題再全量推送

5.10.3 nacos配置中心使用

主流的配置中心：

Spring cloud config、Apollo(攜程)、Disconf(百度)、Nacos(阿里)

步驟1：啟動 Nacos，然后在配置管理中創建一個配置

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

步驟2：在客戶端，導入配置中心依賴

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

步驟3：配置 application.yml 文件

spring:cloud:nacos:config:server-addr: localhost:8848password: nacosusername: nacosconfig:import: optional:nacos:provider-rest-8001.yml

步驟4：獲取配置中心配置

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.10.4 Nacos 配置的動態更新

我們不但可以在主程序通過 Enviroment 獲取配置信息，也可以通過 @Value 獲取，但是一開始不想主程序是動態實時更新的，需要加上 @RefreshScope 注解才能實現動態更新

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

RefreshScope 是 Spring Cloud 中的一個注解，主要用于實現配置中心的動態刷新功能。在微服務架構中，配置管理是一個重要的問題。通常，配置是在應用程序啟動時加載并緩存起來的。但是，在某些情況下，需要動態地修改配置，例如在運行時修改配置文件，或者使用配置中心來管理配置。為了解決這個問題，Spring Boot 提供了 @RefreshScope 注解。

5.10.5 支持 profile 粒度的配置

在配置中心，創建了兩個不同環境的配置，表示在不同環境下的配置文件

方式1：在程序的配置文件中，使用下面的配置方式，指定當前的環境

spring:profiles:active: prod

方式2：通過添加虛擬機選項

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

方式3：覆蓋配置屬性

5.10.6 支持命名空間和組的配置

我們可以給配置文件創建命名空間和組，在客戶端指定所屬的命名空間和分組，這樣是無法讀取其他命名空間和組的配置信息的。

外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳

5.10.7 多個配置讀取

優先級是后加載的會覆蓋先加載的

config:import:- optional:nacos:${spring.application.name}.${spring.cloud.nacos.config.file-extension}- optional:nacos:mysql-config.yml