『壹』 Nacos-參數配置
Nacos中的參數有很多，如：命名空間、分組名、服務名、保護閥值、服務路由類型、臨時實例等，那這些參數都是什麼意思?又該如何設置？
在Nacos中通過命名空間（Namespace）+分組（Group）+服務名（Name）可以定位到一個唯一的服務實例。
命名空間（Namespace）:Nacos服務中最頂層、也是包含范圍最廣的概念，用於強制隔離類似環境或者租戶等場景。Nacos的服務也需要使用命名空間來進行隔離。 命名空間在Nacos控制台的一級目錄里可以找到，如下所示：
在服務列表中也能看到命名空間的身影，如下所示：
命名空間默認為public，在項目開發中，如果不指定命名空間，那麼會使用默認值public。 官方推薦使用運行環境來定義命名空間 ，如生產版本可使用public，開發版可定義為private。在項目開發中，可通過配置"spring.cloud.nacos.discovery.namespace"老定義命名空間，如下所示：
命名空間在使用前，必須先在控制台新建命名空間 ，如下所示：
如果在控制台沒有新建命名空間，直接在項目中使用的話，是不能將服務成功注冊到Nacos中的，如下在項目中配置一個未新建的dev命名空間，如下所示：
然後啟動項目，會發現，在Nacos控制台的服務列表中一直刷新不到任何服務實例
分組名（Group）：Nacos中次於命名空間的一種隔離概念，區別於命名空間的強制隔離屬性，分組屬於一個弱隔離概念，主要用於邏輯區分一些服務使用場景或不同應用的同名服務，用常用的情況主要是同一個服務的測試分組和生產分組、或者將應用名作為分組以防止不同應用提供的服務重名。 分組名在Nacos控制台的服務列表中可以看到，如下所示：
分組名默認為DEFAULT_GROUP，在項目中可通過"spring.cloud.nacos.discovery.group"來設置，如下所示：
此項可省略，省略時的默認值為DEFAULT_GROUP。 分組名可以直接在項目中使用 ，無需像命名空間那樣，在使用前還要在控制台中新建，設定了分組名之後，刷新服務列表就可以看到新的分組名稱了，如下所示：
服務名（Name）:該服務實際的名字，一般用於描述該服務提供了某種功能或能力。 通常推薦使用由運行環境作為命名空間、應用名作為分組，服務功能作為服務名的組合來確保該服務的天然唯一性，當然使用者可以忽略命名空間和分組，僅使用服務名作為服務唯一標識，這就需要使用者在定義服務名的額外增加自己的規則來確保在使用中能夠唯一定位到該服務而不會發現到錯誤的服務上。服務名在項目中可以通過"spring.application.name"來指定，如下所示：
健康保護閾值（ProtectThresHold）：為了防止因過多實例故障，導致所有流量全部流入剩餘實例，繼而造成流量壓力將剩餘實例被壓垮形成雪崩效應。應將健康保護閾值定義為一個0到1之間的浮點數。當域名健康實例數占總服務實例數的比例小於該值時，無論實例是否健康，都會將這個實例返回給客戶端。這樣做雖然損失一部分流量，但是保證了集群中剩餘健康實例能正常工作。 簡單來說，保護閾值是一個0-1浮點數，保護閾值是允許群里中健康實例佔比的最小值，如果實際健康實例的佔比小於或等於設置的保護閾值時，就會觸發閾值保護，如下所示，設置保護閾值為0.75：
停掉唯一的健康實例，集群的健康實例佔比降成了0%，小於設置的保護閾值0.75，此時就會觸發閾值保護，如下所示：
服務路由類型的設置如下所示：
它是用來設置服務的路由策略的，默認值為none。如果 設置為label（標簽）模式，需要設置響應的標簽表達式來匹配實例選擇器（Selector）,通過實例選擇器可以完成自定義負載均衡策略， 比如我們可以自定義實例選擇器，實現就近訪問的負載均衡策略，這樣消費者在調用時，會優先調用離自己比較近的IP節點，從而實現更高效的服務調用。
權重（Weight）：實例的級別配置。權重為浮點數，范圍為0-10000。權重越大，分配給該實例的流量越大。 它是針對服務實例進行設置的，如下所示：
在Nacos中服務實例有二種類型：持久化實例和臨時實例（也叫非持久化實例）。 在控制台中"臨時實例"為true時，表示此服務為臨時實例，如下所示：
臨時實例和持久化實例的區別主要有一下兩點：
在項目開發中，可以通過設置
「spring.cloud.nacos.discovery.ephemeral」來指定服務的實例類型，默認為臨時實例，也就是默認「spring.cloud.nacos.discovery.ephemeral=true」。如果要設置持久化實例，需要設置「spring.cloud.nacos.discovery.ephemeral」設置為 false，如下圖所示：
服務的實例類型一旦確定之後，整個生命周期內不允許被修改，如果試圖修改實例類型會提示如下錯誤：
『貳』 nacos與k8s 服務注冊與發現
首先先說說比較常規的nacos的服務注冊與發現。
用spring cloud為例，ali集成了spring-cloud和nacos，因此加入以下依賴
然後我們配置nacos server的地址，並通過 Spring Cloud 原生註解 @EnableDiscoveryClient 開啟服務注冊發現功能，在 application.properties 中配置 Nacos server 的地址，啟動服務之後，服務會將自己的元數據注冊到nacos上，最主要的是服務名，ip，埠，namespace等。服務注冊成功後，服務將與注冊中心維持心跳，心跳機制可以保證當服務中的某個實例不健康之後，服務中心將該實例剔除，以保證服務正常提供服務。
當服務注冊上去之後，消費者就可以調用服務了，那麼消費者是怎麼發現服務的呢，消費者向注冊中心訂閱某個服務，並提交一個監聽器，當服務提供方實例發生變化，比如ip變了，消費者會收到通知，更新本地的服務列表，nacos client獲取到服務列表之後，通過負載均衡，spring一般都是結合ribbon，獲取一個可用的實例，得到它的ip和埠號，以及服務路由，然後進行調用。
由於客戶端將獲取到的服務實例保存在一個 map 中，而該 map 中的內容是由調度任務定時去更新的，存在一定的延時。
一般來說，在k8s中一個服務有多個實例，是通過pod去部署的，多個實例則有多個pod，每一個pod都會有自己的容器組ip，在集群內，直接通過這個容器ip和埠是可以訪問服務的，但是每次服務重啟，也就是pod銷毀重建的時候，ip也會改變。k8s並沒有一個注冊中心讓我們注冊實例的ip和埠到服務下面，並且其他服務通過這個注冊中心去發現服務。在k8s里是通過service去實現的。
這是一個service定義的例子， 這個 Service 將被指派一個 IP 地址（通常稱為 「Cluster IP」），上述的selector代表這個service代理的pod選擇器，也就是說具有這個app標簽的選擇器的一組pod，可以通過service這個統一的訪問入口去做服務發現。
比如說我們現在有一組pod叫base-opc-biz
查看它的service
信息包括 ：name，namespace，selector，labels等基礎信息
type 是ClusterIP,IP這個值 即是在集群內部，其他所有的pod都可以通過這個虛擬的ip來訪問service，service就會將這個請求負載均衡到後端的所有pod上去。
Port 是訪問service的埠
TargetPort 是代理的pod的埠
Endpoints 是當前service代理的所有pod的ip地址，當某個pod被銷毀重建的時候，這里的ip地址也會隨之變化
集群內其他pod訪問我們創建的service有三種方式：
1、 通過clusterIp+port直接去訪問
2、 同一個namespace直接訪問服務名，不同的 namespace 裡面，我們可以通過 service 名字加「.」kube-dns可以解決Service的發現問題，k8s將Service的名稱當做域名注冊到kube-dns中，通過Service的名稱就可以訪問其提供的服務。
Kubernetes 集群中部署了一套 DNS 服務，通過 kube-dns 的服務名暴露 DNS 服務。您可執行以下命令查看 kube-dns 的服務詳情。
kubectl get svc kube-dns -n kube-system
服務後端是兩個名為 coredns（下文會介紹 CoreDNS 解析原理） 的 Pod。您可執行以下命令查看 coredns 的 Pod 詳情。
kubectl get deployment coredns -n kube-system
3、 通過環境變數訪問，在同一個 namespace 里的 pod 啟動時，kubelet 會為每個活躍的 Service 添加一組環境變數，會把 service 的一些 IP 地址、埠，以及一些簡單的配置，通過環境變數的方式放到 K8s 的 pod 裡面。因此我們可以通過環境變數去直接訪問。
上面三種方式都是在k8s集群內部互相訪問的情況，對我們應用的某些部分，可能希望將 Service 暴露在一個外部 IP 地址上。 Kubernetes 支持兩種實現方式：NodePort 和 LoadBalancer。
我們看下我們原本的service 的yaml文件
把type改成NodePort 或者 LoadBalancer
然後重新創建service，再看看信息
發現有了EXTERNAL-IP，這個ip是一個公網的ip，因此我們就不只可以在集群上訪問我們的服務了。
『叄』 Spring Gateway 集成Nacos 實現動態路由配置
通過Spring Gateway 集成Nacos實現配置管理，並且實現動態路由管理。
一、創建test-gateway項目，POM文件如下：
二、創建項目配置文件bootstrap.yml
a、test_gateway_commons.yml內容如下：
三、創建網關配置類 GatewayConfig.java
四、創建動態路由服務DynamicRouteServiceImpl.java
五、創建通過Nacos讀取動態路由配置服務.java
六、配置動態路由配置文件gateway_dynamic_router，內容如下：
通過以上步驟就完成Spring Gateway 集成Nacos 實現動態路由配置功能。以後只要通過修改Nacos的配置文件就可以時間服務的動態上下線了。不需要再重啟網關了。
『肆』 Nacos配置成系統服務，開機自動啟動及注意事項
設置開機啟動
vim /lib/systemd/system/nacos.service
[Unit]
Description=nacos
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/nacos/bin/startup.sh
ExecReload=/usr/local/nacos/bin/shutdown.sh
ExecStop=/usr/local/nacos/bin/shutdown.sh
PrivateTmp=true
[Install]
WantedBy=multi-user.target
--------------------------------------------------------------------------------------
如果是單機模式這個語句需要修改為如下
ExecStart=/usr/local/nacos/bin/startup.sh -m standalone
保存後執行以下命令
systemctl daemon-reload
systemctl enable nacos.service
systemctl start nacos.service
如果報錯：
nacos.service: Service hold-off time over, scheling restart.
是service啟動文件沒有載入進來 需要重啟系統 reboot 就可以了
注意事項：
需要修改/usr/local/nacos/bin/startup.sh 中的一個參數
原：
修改後：
保存後就不會啟動是報錯了。
『伍』 使用路由網關統一訪問介面
Spring Cloud Gateway 是 Spring 官方基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的網關，Spring Cloud Gateway 旨在為微服務架構提供一種簡單而有效的統一的 API 路由管理方式。 Spring Cloud Gateway 作為 Spring Cloud 生態系中的網關，目標是替代 Netflix ZUUL ，其不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/埋點，和限流等。
客戶端向 Spring Cloud Gateway 發出請求。然後在 Gateway Handler Mapping 中找到與請求相匹配的路由，將其發送到 Gateway Web Handler。Handler 再通過指定的過濾器鏈來將請求發送到我們實際的服務執行業務邏輯，然後返回。
過濾器之間用虛線分開是因為過濾器可能會在發送代理請求之前（ pre ）或之後（ post ）執行業務邏輯。
主要增加了 org.springframework.cloud:spring-cloud-starter-gateway 依賴
注意：請仔細閱讀注釋
依次運行 Nacos 服務、 NacosProviderApplication 、 NacosConsumerApplication 、 NacosConsumerFeignApplication 、 GatewayApplication
打開瀏覽器訪問： http://localhost:9000/nacos-consumer/echo/app/name 瀏覽器顯示
打開瀏覽器訪問： http://localhost:9000/nacos-consumer-feign/echo/hi 瀏覽器顯示
注意：請求方式是 http://路由網關IP:路由網關Port/服務名/**
至此說明 Spring Cloud Gateway 的路由功能配置成功
『陸』 3. nacos服務發現
1. nacos服務發現原理
2. spring cloud服務協作流程
3.搭建nacos服務端
4. 搭建nacos服務發現客戶端
5. nacos服務發現的數據模型
有兩個微服務A和B, A調用B, 那麼A是如何調用B的呢?我們可以通過http請求,進行調用. 也可以使用rpc進行調用.
不管使用什麼方式, A需要知道B的地址和埠號. 那麼A是如何知道B的地址和埠好的呢? 如上圖:
1. B服務啟動的時候, 會注冊到服務發現中心, 告訴他,我的ip和埠號是什麼?這里應該也是介面調用,通知服務發現中心的.
2. A服務啟動的時候, 也會注冊的服務發現中心, 告訴他, 我的ip和埠號是什麼? 同時, 服務發現中心會告訴我, 當前已注冊的服務的ip和埠號. 這里通過一個介面請求和參數返回就可以實現.
3. 拿到了B服務的ip和port, 接下來就可以調用服務B了.
我們要基於spring cloud生態環境進行開發. 所以,先來了解spring cloud的服務寫作流程
前面注冊和發現就都不說了, 上面說過了, 這里多了兩個東西, 一個是Ribbon, 另一個是feign.
Ribbon是負載均衡器, Feign是遠程調用, 自動進行http請求.
客戶端Service A 要調用ServiceB的實例1和實例2. 那麼到底調用ServiceB的哪個實例呢? 使用Ribbon負載均衡, 要看使用什麼樣的演算法了, 可以使用輪詢演算法, 或者其他演算法, 如加權演算法
負載均衡有兩種: 服務端負載均衡, 客戶端負載均衡
在負載均衡中維護一個可用的服務實例清單, 當客戶端請求來臨時, 負載均衡伺服器按照某種配置好的規則(負載均衡演算法), 從可用服務實例清單中, 選取其一去處理客戶端請求, 這就是服務端負載均衡, 例如Nginx. 通過nginx進行負載均衡, 客戶端發送請求值Nginx, nginx通過負載均衡演算法, 在多個伺服器之間選擇一個進行訪問.
接下來, 我們要講的ribbon, 就屬於客戶端負載均衡, 在ribbon客戶端會有一個服務實例地址列表, 在發送請求前, 通過負載均衡演算法, 選擇一個服務實例, 然後進行訪問, 這是客戶端負載均衡. 即在客戶端進行負載均衡演算法分配.
服務的調用方, 我們就可以理解為是一個客戶端.
負載均衡演算法:
可通過下面的方式, 在spring boot配置中修改默認的負載均衡的策略
<pre style="color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 12px; margin: 5px 8px; padding: 5px;">account-service.ribbon.NFLoadBalanceRuleClassName=com.netflix.loadBalancer.RandomRule</pre>
其中: account-service: 是調用的服務的名稱. 後面的組成部分是固定的.
feign是服務端http介面的調用.
feign可以幫助我們更快捷, 優雅的調用httpApi. 原來我們在調用http請求的時候, 需要使用的是RestTemplate, 傳輸域名和埠號, 進行http調用. 使用feign後, 不用再使用RestTemplate模擬請求了, feign能夠通過服務名, 找到對應的介面. 不需要我們在拼接地址+埠了, 提供了簡單方便的操作.
使用方法:
2. 聲明feign客戶端
新建一個類, 聲明為FeignClient類型的介面. 指定調用的服務名. 然後將指定介面. 這樣在調用的時候, 就可以通過服務名, + 介面, 自動找到對應的項目介面了.
這里上一節已經搭建過了(地址: https://www.cnblogs.com/ITPower/articles/12630193.html ), 在服務的最後, 我們搭建了nacos的集群
因為對於服務發現來說, 有很多配置都是公用的, 因此, 我們搭建一個父工程, 將通用的配置都添加到裡面取.
創建一個maven工廠, 引入jar包即可. pom文件如下
在父工程下創建一個子工程. 我們要做一下三件事
指定服務埠號, nacos服務的地址
需要增加兩個引入. 一個啟用服務發現, 另一個是啟用feign
最終項目結構如下:
其中前3步驟和創建服務生產者是一樣的
在父工程下創建一個子工程. 我們要做一下三件事
指定服務埠號, nacos服務的地址
需要增加兩個引入. 1個啟用服務發現, 另一個是啟用feign
nacos生產上已經注冊發現了兩題服務
同時調用介面, 可以獲取到proctor返回的內容.
我們可以通過啟動多個服務的方式, 來測試服務的負載均衡策略.
1. 修改proctor的啟動埠號為動態埠號. 目的是方便啟動的時候動態配置埠號, 啟動集群
** 2. 修改配置, 添加動態埠號**
vm options配置中設置動態埠號為-Dport=56010, 56011. 點擊復制按鈕, 可以增加一個應用, 然後配置參數後, 啟動兩個應用.
3. 在nacos控制台查看啟動效果
我們看到, nacos的proctor 有兩台服務實例. 點擊詳情可查看具體的服務實例信息:
4. 調用consumer的介面, 訪問proctor, 默認採用輪詢的負載均衡演算法
http://localhost:56020/consumer
nacos的注冊發現是一種三層模型: 即 服務--集群--實例.如下圖:
nacos最外層是服務. 最里層是多台實例. 多個實例之間組成一個服務集群.
命名空間不僅適用於配置管理, 同樣適用於服務發現. namespace的常用場景之一是不同環境的配置隔離.如: 開發, 生成, 測試環境資源的隔離.
proctor啟動了兩個實例, 點擊詳情進去可以看到他是一個集群. 集群里有兩台實例.
5.2 服務.
在命名空間下, 有各個服務.比如我們上面定義的是在public命名空間下, 定義了兩個服務. 一個是proctor, 一個是consumer.
服務有 服務名 和 實例. ****遠程調用的時候, 需要指定服務名.
5.3 實例
實例是基於網路協議通訊, 所以必須要有一個ip:埠號
5.4 元信息
在及群里點擊某一個實例-->編輯, 可以看到如下頁面, 可以設置元信息
那麼元信息是什麼呢? 每台伺服器都可能會設置自己的個性化的信息. 這就是每台伺服器的元數據信息
5.5 實操---指定集群的命名空間為dev
只需要在配置中增加命名空間就可以了.
我們也可以修改集群的名字, 集群的默認名字是DEFAULT. 我們這里將其修改為default. 在控制台dev命名空間下, 可以看到啟動了服務customer.
『柒』 Spring Gateway集成nacos實現動態路由配置
本文主要介紹Spring Gateway通過集成nacos實現路由動態配置，達到不重啟API網關實現動態暴露內部微服務介面的目的。主要流程如下：
一、創建Maven項目test-gateway, pom文件如下：
二、創建啟動類Apllication.java，內容如下：
三、創建網關調用nacos配置類GatewayConfig.java
四、創建動態路由管理服務
1、創建動態路管理類DynamicRouteServiceImpl.java
2、創建通過nacos對路由動態管理類.java
1、test_gateway_commons.yml配置文件內容下：
2、JSON路由配置文件gateway_dynamic_router的內容如下：
通過以上步驟就實現了Spring Gateway集成nacos實現路由動態配置的功能。以後只要修改gateway_dynamic_router 文件就可以實現服務的微服務的介面暴露和下線功能。
demo代碼地址如下：https://gitee.com/sharepublicly/test-gateway
『捌』 【Nacos專題】Nacos 快速入門
Nacos 英文全稱 Dynamic Naming and Configuration Service，它是 Spring Cloud Alibaba 的核心組件之一，致力於微服務架構中的服務注冊與發現、配置管理。
Nacos 將注冊中心和配置中心整合在一起，提供了兩個核心功能，即服務注冊與發現和動態配置服務。
Nacos 支持基於 DNS 和 基於 RPC 的服務發現，服務提供者向 Nacos 服務端注冊服務後，服務消費者可以從 Nacos 服務端獲取注冊列表。
提供了一個簡潔易用的 UI，方便用戶管理所有環境的應用配置和服務配置，消除了配置變更時服務需重新部署的過程。還提供了包括 配置版本跟蹤 、 金絲雀發布 、 一鍵回滾配置 以及 客戶端配置更新狀態跟蹤 在內的一系列開箱即用的配置管理特性，大大降低配置變更帶來的風險。
Nacos 分為服務端和客戶端，服務端用來提供服務發現與注冊等功能，客戶端就是不同的應用和服務。
在 Nacos 的 Release Notes 可以看到每個版本的相關介紹。當前最新的穩定版本是 1.4.0。
Nacos 服務需要 Java 運行環境，因此，在啟動服務之前需要確保你的伺服器已經有了 Java 運行環境，並且配置好了 JAVA_HOME 。
參數說明：
-m：指定運行模式，standalone 表示單機模式
在 Nacos 配置文件中配置伺服器ip，默認的埠號為8848，默認的用戶名和密碼均為nacos，訪問 http://ip:8848/nacos/index.html 便能夠成功登Nacos管理後台。
(1) 引入依賴
在 SpringBoot 項目中引入 Nacos 客戶端依賴，pom.xml 添加如下內容：
(2) 修改配置
在 application.properties 配置文件中添加 Nacos 的基本配置 (也可以是 application.yml )
1）application.properties
2）application.yml
(3) @EnableDiscoveryClient 註解
在 SpringBoot 的啟動類上添加 @EnableDiscoveryClient 註解來開啟服務注冊。
Nacos Discovery 默認集成了 Netflix Ribbon，服務消費者可以使用 RestTemplate 或 OpenFeign 進行服務的調用。
(1) Nacos 啟動時報如下錯誤
問題原因：通過yum命令安裝的普通的openJDK沒有javac等工具，而且安裝完以後連環境變數都不需要配置，就能使用 java -version 驗證。
解決方案：重新安裝devel開發版openJDK，開發版的openJDK有javac工具，然後配置java環境變數即可。
(2) Nacos Provider 啟動報錯
問題原因：沒有配置 Nacos 服務端的地址，因此，當 Nacos Provider 啟動的時候，無法與注冊中心通信
解決方案：在配置文件中配置 Nacos 服務端地址，如下所示：
『玖』 nacos配置中心單擊模式改造為集群模式
nacos作為配置中心可以將配置項目的配置提取到外部，獨立管理，當nacos單機部署時，當nacos服務不正常時，項目便不可獲取到正確的配置信息。如果將nacos搭建成集群環境，只要不是集群的所有機器都有掛掉，都可以正常讀取配置，可以提高項目穩定性。
需要多台linux機器作為集群的環境
此外，需要linux機器包含maven環境、java環境
github地址： https://github.com/alibaba/nacos
新建cluster.conf文件，或者將cluster.conf.example重明明為cluster.conf
在此文件中添加集群地址和埠號
新建application.properties文件或者將application.properties.example重命名為application.properties
執行bin目錄下的startup.sh腳本
ps：sh startup.sh則默認以集群模式啟動，sh startup.sh -m standalone則是以單機模式啟動
啟動成功後，單獨訪問每台機器的地址(ip:8848/nacos/#/login)，用戶名密碼：nacos/nacos
如果都能正常訪問，則一切正常。
啟動項目，後台可以看到nacos連接的相關日誌
並且項目可以正常讀取到配置內容，則一切正常
如果使用jenkins部署項目，則需要需要修改jenkins的nacos相關配置，使之可以正確讀取到nacos集群的每一台機器
『拾』 springboot 2.4.13 無法從nacos獲取配置，但是可以注冊到nacos
springboot 2.4.13，集成了nacos，啟動後，nacos注冊中心有服務，但是，發現，配置沒有生效。於是，開啟了一段源碼查找的過程。
首先，是pom引入的nacos配置
然後，application.yml添加nacos配置
啟動後，發現注冊中心有服務，但是，服務的配置不是從nacos配置中心獲取的，而是本地的。
查找一下nacos源碼，找到nacos配置自動注入那塊兒：
然後發現，是這個NacosPropertySourceLocator實現的配置導入的
查詢源碼，可以發現，相關的配置，是通過這個方法，載入的，這個方法是總入口。
於是，嘗試加斷點，查看配置信息，看看為什麼沒有導入配置。然而，程序根本就沒有進入這個方法裡面！！！
根據介面實現，可以發現NacosPropertySourceLocator 是PropertySourceLocator的實現類，這個方法的調用執行，不是nacos自己去做的，而是通過spring去做的。
spring cloud 通過BootstrapApplicationListener，以監聽器的方式，通過監聽springboot啟動過程中的事件，通過onApplicationEvent方法處理事件，導入spring cloud相關配置。
通過加斷點，可以發現，這里的方法bootstrapEnabled()返回值是false，直接就不執行後續的載入了。
因此，需要保證bootstrapEnabled返回值是true。
查看PropertyUtils源碼，可以發現，需要配置項 spring.cloud.bootstrap.enabled=true 並且存在 org.springframework.cloud.bootstrap.marker.Marker 類的時候，spring cloud 才會去載入spring cloud的配置。
因此，pom中需要添加marker所在的組件依賴：
此時，需要在 bootstrap.yml 中添加spring cloud配置：
（至於為什麼是bootstrap.yml而不是application.yml，這又是另一個問題了）
有了上面的配置，程序啟動後，就能正常的從nacos配置中心獲取配置了。