1、不同環(huán)境相同配置問題-自定義Data ID配置

在實(shí)際的開發(fā)過程中，項(xiàng)目所用到的配置參數(shù)有的時(shí)候并不需要根據(jù)不同的環(huán)境進(jìn)行區(qū)分，生產(chǎn)、測(cè)試、開發(fā)環(huán)境所用到的參數(shù)值是相同的。怎么解決同一服務(wù)在多環(huán)境中，引用相同的配置的問題？Nacos Config也提供了相應(yīng)的解決方案：可以通過服務(wù)名+拓展名的方式，來實(shí)現(xiàn)同一個(gè)微服務(wù)下不同的環(huán)境，共享的配置文件。

在Nacos配置中心添加一個(gè)Data Id為nacos-config-client.yaml的通用配置文件：

在config-3377中添加Nacos配置中心的地址：

在Controller中添加對(duì)應(yīng)方法：

訪問http://localhost:3377/config/configCommon，可以看到已經(jīng)成功拿到對(duì)應(yīng)的配置：

可以看到，?nacos-config-client.yaml配置文件其實(shí)是沒有帶環(huán)境后綴在后面，也就是無論哪個(gè)環(huán)境都可以加載此配置文件。但是需要注意的是，也正是由于沒有帶環(huán)境后綴，所以這種通用的配置文件的優(yōu)先級(jí)是低于指定環(huán)境的配置文件。從啟動(dòng)的日志中就可以看到，優(yōu)先讀取帶環(huán)境的配置文件，再讀取無環(huán)境后綴的通用配置文件：

2、不同微服務(wù)之間如何共享配置及拓展配置

當(dāng)前這種配置方式是最基礎(chǔ)的配置方式，但是在實(shí)際開發(fā)中會(huì)涉及到多個(gè)微服務(wù)之間共享配置。比如說redis地址，服務(wù)注冊(cè)中心公共組件等等，那么這些組件是多個(gè)微服務(wù)共享的，所以可以使用Nacos Config提供的共享配置方式來配置共享的配置文件：

shared-configs

在Nacos配置中心添加一個(gè)Data Id為nacos-config-client.yaml的Redis配置文件：

原先配置文件的Data Id都是以服務(wù)名稱來明明，但是這個(gè)配置文件是被多個(gè)服務(wù)公用的，所以取哪一個(gè)服務(wù)名稱來命名都不合適，索性隨便自定義一個(gè)即可。

在config-3377中添加Nacos配置中心，并指定對(duì)應(yīng)的共享配置文件：

進(jìn)入源碼中可以看到，shared-comfigs是個(gè)列表，也就是說可以配置多個(gè)共享配置文件：

共享文件中要指定的幾個(gè)參數(shù)，源碼中也都寫的很清楚，直接復(fù)制照搬即可：

在Controller中添加對(duì)應(yīng)方法：

訪問http://localhost:3377/config/configShared，可以看到已經(jīng)成功拿到對(duì)應(yīng)的配置：

注意：多個(gè) Data Id 同時(shí)配置時(shí)，優(yōu)先級(jí)關(guān)系是 `spring.cloud.nacos.config.extension-configs[n].data-id` 其中 n 的值越大，優(yōu)先級(jí)越高。也就是說，shared-configs[1]的優(yōu)先級(jí)高于shared-configs[0]的優(yōu)先級(jí)。?

extension-configs

其實(shí)以上的實(shí)現(xiàn)還可以通過extension-configs方式來完成，其實(shí)作用基本一致，只不過語(yǔ)義上可以更好的區(qū)分。如果需要在一個(gè)微服務(wù)上配置多個(gè)配置文件，可以使用extension-configs，如果需要多個(gè)配置文件共享，可以使用shared-configs配置方式，當(dāng)然其實(shí)兩種方式所實(shí)現(xiàn)的效果和配置方法基本一致。所以通過自定義擴(kuò)展的 Data Id 配置，既可以解決多個(gè)應(yīng)用間配置共享的問題，又可以支持一個(gè)應(yīng)用有多個(gè)配置文件。

只需要在yml配置文件中將shared-configs改為extension-configs即可：

重啟服務(wù)后，再訪問http://localhost:3377/config/configShared，可以看到效果一致：

Spring Cloud Alibaba Nacos Config 目前提供了三種配置能力從 Nacos 拉取相關(guān)的配置。
- A: 通過 `spring.cloud.nacos.config.shared-configs[n].data-id` 支持多個(gè)共享 Data Id 的配置；
- B: 通過 `spring.cloud.nacos.config.extension-configs[n].data-id` 的方式支持多個(gè)擴(kuò)展 Data Id 的配置；
- C: 通過內(nèi)部相關(guān)規(guī)則(應(yīng)用名、應(yīng)用名+ Profile )自動(dòng)生成相關(guān)的 Data Id 配置；
當(dāng)三種方式共同使用時(shí)，它們的一個(gè)優(yōu)先級(jí)關(guān)系是：A < B < C

3、Nacos動(dòng)態(tài)刷新原理

什么是動(dòng)態(tài)監(jiān)聽

所謂動(dòng)態(tài)監(jiān)聽，簡(jiǎn)單理解就是指Nacos會(huì)自動(dòng)找到那些服務(wù)已經(jīng)注冊(cè)，而對(duì)比來說靜態(tài)監(jiān)聽，就是指需要有指定配置指定的服務(wù)。其實(shí)在這里就要說一下客戶端和服務(wù)端的交互方式，無非就是推和拉：
- Push：表示服務(wù)端主動(dòng)將數(shù)據(jù)變更信息推送給客戶端
?? ?- 服務(wù)需要維持客戶端的長(zhǎng)連接，因?yàn)樾枰谰唧w推送的客戶端
?? ?- 客戶端耗費(fèi)內(nèi)存高，因?yàn)樾枰４嫠锌蛻舳说倪B接，并且需要檢測(cè)連接有效性（心跳機(jī)制）
- Pull：表示客戶端主動(dòng)去服務(wù)端拉取數(shù)據(jù)
?? ?- 需要定時(shí)拉取數(shù)據(jù)
?? ?- 缺點(diǎn)：時(shí)效性，數(shù)據(jù)實(shí)時(shí)性，無效請(qǐng)求

動(dòng)態(tài)刷新機(jī)制

Nacos動(dòng)態(tài)刷新機(jī)制，采用推和拉的優(yōu)點(diǎn)，避免缺點(diǎn)。Nacos做配置中心的時(shí)候，配置數(shù)據(jù)的交互模式是有服務(wù)端push推送的，還是客戶端pull拉取的？Nacos客戶端發(fā)送一個(gè)請(qǐng)求連接到服務(wù)端，然后服務(wù)端中會(huì)有一個(gè)29.5+0.5s的一個(gè)hold期，然后服務(wù)端會(huì)將此次請(qǐng)求放入到allSubs隊(duì)列中等待，觸發(fā)服務(wù)端返回結(jié)果的情況只有兩種，第一種是時(shí)間等待了29.5秒，配置未發(fā)生改變，則返回未發(fā)生改變的配置；第二種是操作Nacos Dashboard或者API對(duì)配置文件發(fā)生一次變更，此時(shí)會(huì)觸發(fā)配置變更的事件，發(fā)送一條LocalDataEvent消息，此時(shí)服務(wù)端監(jiān)聽到消息，然后遍歷allSubs隊(duì)列，根據(jù)對(duì)應(yīng)的groupId找到配置變更的這條ClientLongPolling任務(wù)，并且通過連接返回給客戶端。

Nacos動(dòng)態(tài)刷新避免了服務(wù)端對(duì)客戶端進(jìn)行push操作時(shí)需要保持雙方的心跳連接，同樣也避免了客戶端對(duì)服務(wù)端進(jìn)行pull操作時(shí)數(shù)據(jù)的時(shí)效性問題，不必頻繁去拉去服務(wù)端的數(shù)據(jù)。通過上面原理的初步了解，顯而易見，答案是：客戶端主動(dòng)拉取的，通長(zhǎng)輪詢的方式（Long Polling）的方式來獲取配置數(shù)據(jù)。

短輪詢

不管服務(wù)端的配置是否發(fā)生變化，不停發(fā)起請(qǐng)求去獲取配置，比如支付訂單場(chǎng)景中前端不斷輪詢訂單支付的狀態(tài)，這樣的壞處顯而易見，由于配置并不會(huì)頻繁發(fā)生變更，如果是一直發(fā)請(qǐng)求，一定會(huì)對(duì)服務(wù)端造成很大的壓力。還會(huì)造成數(shù)據(jù)推送的延遲，比如每10秒請(qǐng)求一次配置，如果在第11秒的時(shí)候配置更新，那么推送將會(huì)延遲9秒，等待下一次請(qǐng)求這就是短輪詢，為了解決短輪詢的問題，有了長(zhǎng)輪詢的方案。

長(zhǎng)輪詢

長(zhǎng)輪詢不是什么新技術(shù)，它其實(shí)就是由服務(wù)端控制響應(yīng)客戶端請(qǐng)求結(jié)果的返回時(shí)間，來減少客戶端無效請(qǐng)求的一種優(yōu)化手段。其實(shí)對(duì)于客戶端來說，長(zhǎng)輪詢的使用并沒有本質(zhì)上的區(qū)別，客戶端發(fā)起請(qǐng)求后，服務(wù)端不會(huì)立即返回請(qǐng)求結(jié)果，而是將請(qǐng)求hold掛起一段時(shí)間，如果此時(shí)間段內(nèi)配置數(shù)據(jù)發(fā)生變更，則立即響應(yīng)客戶端，若一直無變更則等到指定超時(shí)時(shí)間后響應(yīng)給客戶端結(jié)果，客戶端重新發(fā)起長(zhǎng)鏈接。

4、Nacos一致性協(xié)議：Distro協(xié)議

Distro協(xié)議是Nacos社區(qū)自研的一種AP分布式協(xié)議，是面向臨時(shí)實(shí)例設(shè)計(jì)的一種分布式協(xié)議，其保證在某些Nacos節(jié)點(diǎn)宕機(jī)后，整個(gè)臨時(shí)實(shí)例處理系統(tǒng)依舊可以正常工作。作為一種有狀態(tài)的中間件應(yīng)用內(nèi)嵌協(xié)議，Distro保證了各個(gè)Nacos節(jié)點(diǎn)對(duì)于注冊(cè)請(qǐng)求的統(tǒng)一協(xié)調(diào)和儲(chǔ)存。

Distro協(xié)議的主要設(shè)計(jì)思想

- Nacos 每個(gè)節(jié)點(diǎn)是平等的都可以處理寫請(qǐng)求，同時(shí)把新數(shù)據(jù)同步到其他節(jié)點(diǎn)；
- 每個(gè)節(jié)點(diǎn)只負(fù)責(zé)部分?jǐn)?shù)據(jù)，定時(shí)發(fā)送自己負(fù)責(zé)數(shù)據(jù)的校驗(yàn)值到其它節(jié)點(diǎn)來保持?jǐn)?shù)據(jù)一致性；
- 每個(gè)節(jié)點(diǎn)獨(dú)立處理讀請(qǐng)求，及時(shí)從本地發(fā)出響應(yīng)；

Nacos為什么需要一致性協(xié)議

- Nacos 在開源支持就定下了?個(gè)目標(biāo)，盡可能的減少用戶部署以及運(yùn)維成本，做到用戶只需要?個(gè)程序包，就可以快速以單機(jī)模式啟動(dòng) Nacos 或者以集群模式啟動(dòng) Nacos。而Nacos 是?個(gè)需要存儲(chǔ)數(shù)據(jù)的?個(gè)組件，為了實(shí)現(xiàn)這個(gè)目標(biāo)，就需要在 Nacos 內(nèi)部實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)。單機(jī)下其實(shí)問題不大，簡(jiǎn)單的內(nèi)嵌關(guān)系型數(shù)據(jù)庫(kù)即可；但是集群模式下，就需要考慮如何保障各個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)?致性以及數(shù)據(jù)同步，而要解決這個(gè)問題，就不得不引入共識(shí)算法，通過算法來保障各個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)的?致性；
- Distro 協(xié)議是阿里巴巴自研的?個(gè)最終?致性協(xié)議，而最終?致性協(xié)議有很多，比如Gossip（流行病協(xié)議）、Eureka 內(nèi)的數(shù)據(jù)同步算法。而 Distro 算法是集 Gossip 以及 Eureka 協(xié)議的優(yōu)點(diǎn)并加以優(yōu)化而出來的。對(duì)于原生的 Gossip，由于隨機(jī)選取發(fā)送消息的節(jié)點(diǎn)，也就不可避免的存在消息重復(fù)發(fā)送給同?節(jié)點(diǎn)的情況，增加了網(wǎng)絡(luò)的傳輸?shù)膲毫?，也給消息節(jié)點(diǎn)帶來額外的處理負(fù)載。而Distro算法引入了權(quán)威 Server 的概念，每個(gè)節(jié)點(diǎn)負(fù)責(zé)?部分?jǐn)?shù)據(jù)以及將自己的數(shù)據(jù)同步給其它節(jié)點(diǎn)，有效的降低了消息冗余的問題；

Distro協(xié)議具體執(zhí)行邏輯

數(shù)據(jù)初始化

新加入的 Distro 節(jié)點(diǎn)會(huì)進(jìn)行全量數(shù)據(jù)拉取。具體操作是輪詢所有的 Distro 節(jié)點(diǎn)，通過向其它的機(jī)器發(fā)送請(qǐng)求拉取全量數(shù)據(jù)。在全量拉取操作完成之后，Nacos 的每臺(tái)機(jī)器上都維護(hù)了當(dāng)前的所有注冊(cè)上來的非持久化實(shí)例數(shù)據(jù)。

數(shù)據(jù)校驗(yàn)

在 Distro 集群?jiǎn)?dòng)之后，各臺(tái)機(jī)器之間會(huì)定期的發(fā)送心跳。心跳信息主要為各個(gè)機(jī)器上的所有數(shù)據(jù)的元信息（之所以使用元信息，是因?yàn)樾枰ＷC網(wǎng)絡(luò)中數(shù)據(jù)傳輸?shù)牧考?jí)維持在?個(gè)較低水平）。這種數(shù)據(jù)校驗(yàn)會(huì)以心跳的形式進(jìn)行，即每臺(tái)機(jī)器在固定時(shí)間間隔會(huì)向其它機(jī)器發(fā)起?次數(shù)據(jù)校驗(yàn)請(qǐng)求。?旦在數(shù)據(jù)校驗(yàn)過程中，某臺(tái)機(jī)器發(fā)現(xiàn)其它機(jī)器上的數(shù)據(jù)與本地?cái)?shù)據(jù)不?致，則會(huì)發(fā)起?次全量拉取請(qǐng)求，將數(shù)據(jù)補(bǔ)齊。

寫操作

對(duì)于?個(gè)已經(jīng)啟動(dòng)完成的 Distro 集群，在?次客戶端發(fā)起寫操作的流程中，當(dāng)注冊(cè)非持久化的實(shí)例的寫請(qǐng)求打到某臺(tái) Nacos 服務(wù)器時(shí)，Distro 集群處理的流程包括幾個(gè)部分：
1、前置的 Filter 攔截請(qǐng)求，并根據(jù)請(qǐng)求中包含的 IP 和 port 信息計(jì)算其所屬的Distro 責(zé)任節(jié)點(diǎn)，并將該請(qǐng)求轉(zhuǎn)發(fā)到所屬的 Distro 責(zé)任節(jié)點(diǎn)上；
2、責(zé)任節(jié)點(diǎn)上的 Controller 將寫請(qǐng)求進(jìn)行解析；
3、Distro 協(xié)議定期執(zhí)行 Sync 任務(wù)，將本機(jī)所負(fù)責(zé)的所有的實(shí)例信息同步到其它節(jié)點(diǎn)上；

讀操作

由于每臺(tái)機(jī)器上都存放了全量數(shù)據(jù)，因此在每?次讀操作中，Distro 機(jī)器會(huì)直接從本地拉取數(shù)據(jù)，快速響應(yīng)。 這種機(jī)制保證了 Distro 協(xié)議可以作為?種 AP 協(xié)議，對(duì)于讀操作都進(jìn)行及時(shí)的響應(yīng)。在網(wǎng)絡(luò)分區(qū)的情況下，對(duì)于所有的讀操作也能夠正常返回；當(dāng)網(wǎng)絡(luò)恢復(fù)時(shí)，各個(gè) Distro 節(jié)點(diǎn)會(huì)把各數(shù)據(jù)分片的數(shù)據(jù)進(jìn)行合并恢復(fù)。

Distro 協(xié)議是 Nacos 對(duì)于臨時(shí)實(shí)例數(shù)據(jù)開發(fā)的?致性協(xié)議。其數(shù)據(jù)存儲(chǔ)在緩存中，并且會(huì)在啟動(dòng)時(shí)進(jìn)行全量數(shù)據(jù)同步，并定期進(jìn)行數(shù)據(jù)校驗(yàn)。在 Distro 協(xié)議的設(shè)計(jì)思想下，每個(gè) Distro 節(jié)點(diǎn)都可以接收到讀寫請(qǐng)求。所有的Distro協(xié)議的請(qǐng)求場(chǎng)景主要分為三種情況：
1、當(dāng)該節(jié)點(diǎn)接收到屬于該節(jié)點(diǎn)負(fù)責(zé)的實(shí)例的寫請(qǐng)求時(shí)，直接寫入；
2、當(dāng)該節(jié)點(diǎn)接收到不屬于該節(jié)點(diǎn)負(fù)責(zé)的實(shí)例的寫請(qǐng)求時(shí)，將在集群內(nèi)部路由，轉(zhuǎn)發(fā)給對(duì)應(yīng)的節(jié)點(diǎn)，從而完成讀寫；
3、當(dāng)該節(jié)點(diǎn)接收到任何讀請(qǐng)求時(shí)，都直接在本機(jī)查詢并返回（因?yàn)樗袑?shí)例都被同步到了每臺(tái)機(jī)器上）；
Distro 協(xié)議作為 Nacos的內(nèi)嵌臨時(shí)實(shí)例?致性協(xié)議，保證了在分布式環(huán)境下每個(gè)節(jié)點(diǎn)上面的服務(wù)信息的狀態(tài)都能夠及時(shí)地通知其它節(jié)點(diǎn)，可以維持?jǐn)?shù)十萬量級(jí)服務(wù)實(shí)例的存儲(chǔ)和最終一致性。文章來源地址http://www.zghlxwxcb.cn/news/detail-609949.html

到了這里，關(guān)于【手把手】教你玩轉(zhuǎn)SpringCloud Alibaba之Nacos Config深入的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！