當(dāng)客戶端出現(xiàn)異常，接收不到請(qǐng)求，那么服務(wù)端會(huì)直接跟客戶端斷開連接

當(dāng)恢復(fù)正常，由于有 Redo 操作，所以還是能拿到最新的實(shí)例信息的

細(xì)節(jié)

在 1.x 版本的時(shí)候，任何服務(wù)都是可以被訂閱的

但是在 2.x 版本中，只支持訂閱臨時(shí)服務(wù)，對(duì)于永久服務(wù)，已經(jīng)不支持訂閱了

數(shù)據(jù)一致性

由于 Nacos 是支持集群模式的，所以一定會(huì)涉及到分布式系統(tǒng)中不可避免的數(shù)據(jù)一致性問題

服務(wù)實(shí)例的責(zé)任機(jī)制

什么是服務(wù)實(shí)例的責(zé)任機(jī)制？

比如上面提到的服務(wù)注冊(cè)、心跳管理、監(jiān)控檢查機(jī)制，當(dāng)只有一個(gè) Nacos 服務(wù)時(shí)，那么自然而言這個(gè)服務(wù)會(huì)去檢查所有的服務(wù)實(shí)例的心跳時(shí)間，執(zhí)行所有服務(wù)實(shí)例的健康檢查任務(wù)

但是當(dāng)出現(xiàn) Nacos 服務(wù)出現(xiàn)集群時(shí)，為了平衡各 Nacos 服務(wù)的壓力，Nacos 會(huì)根據(jù)一定的規(guī)則讓每個(gè) Nacos 服務(wù)只管理一部分服務(wù)實(shí)例的

當(dāng)然每個(gè) Nacos 服務(wù)的注冊(cè)表還是全部的服務(wù)實(shí)例數(shù)據(jù)

這個(gè)管理機(jī)制我給他起了一個(gè)名字，就叫做責(zé)任機(jī)制，因?yàn)槲以?1.x 和 2.x 都提到了responsible這個(gè)單詞

本質(zhì)就是 Nacos 服務(wù)對(duì)哪些服務(wù)實(shí)例負(fù)有心跳監(jiān)測(cè)，健康檢查的責(zé)任。

BASE 理論（CAP妥協(xié)之后的產(chǎn)物）

• 基本可用（Basically Available）：系統(tǒng)出現(xiàn)故障還是能夠?qū)ν馓峁┓?wù)，不至于直接無法用了
• 軟狀態(tài)（Soft State）：允許各個(gè)節(jié)點(diǎn)的數(shù)據(jù)短暫的不一致
• 最終一致性，（Eventually Consistent）：雖然允許各個(gè)節(jié)點(diǎn)的數(shù)據(jù)不一致，但是在一定時(shí)間之后，各個(gè)節(jié)點(diǎn)的數(shù)據(jù)最終需要一致的

Nacos 的 AP 和 CP

Nacos 其實(shí)目前是同時(shí)支持 AP 和 CP 的

具體使用 AP 還是 CP 得取決于 Nacos 內(nèi)部的具體功能，并不是有的文章說的可以通過一個(gè)配置自由切換。

就以服務(wù)注冊(cè)舉例來說，對(duì)于臨時(shí)實(shí)例來說，Nacos 會(huì)優(yōu)先保證可用性，也就是 AP

對(duì)于永久實(shí)例，Nacos 會(huì)優(yōu)先保證數(shù)據(jù)的一致性，也就是 CP

Nacos 的 AP 實(shí)現(xiàn)

對(duì)于 AP 來說，Nacos 使用的是阿里自研的 Distro 協(xié)議

在這個(gè)協(xié)議中，每個(gè)服務(wù)端節(jié)點(diǎn)是一個(gè)平等的狀態(tài)，每個(gè)服務(wù)端節(jié)點(diǎn)正常情況下數(shù)據(jù)是一樣的，每個(gè)服務(wù)端節(jié)點(diǎn)都可以接收來自客戶端的讀寫請(qǐng)求

當(dāng)某個(gè)節(jié)點(diǎn)剛啟動(dòng)時(shí)，他會(huì)向集群中的某個(gè)節(jié)點(diǎn)發(fā)送請(qǐng)求，拉取所有的服務(wù)實(shí)例數(shù)據(jù)到自己的服務(wù)注冊(cè)表中

這樣其它客戶端就可以從這個(gè)服務(wù)節(jié)點(diǎn)中獲取到服務(wù)實(shí)例數(shù)據(jù)了

當(dāng)某個(gè)服務(wù)端節(jié)點(diǎn)接收到注冊(cè)臨時(shí)服務(wù)實(shí)例的請(qǐng)求，不僅僅會(huì)將這個(gè)服務(wù)實(shí)例存到自身的服務(wù)注冊(cè)表，同時(shí)也會(huì)向其它所有服務(wù)節(jié)點(diǎn)發(fā)送請(qǐng)求，將這個(gè)服務(wù)數(shù)據(jù)同步到其它所有節(jié)點(diǎn)

所以此時(shí)從任意一個(gè)節(jié)點(diǎn)都是可以獲取到所有的服務(wù)實(shí)例數(shù)據(jù)的。

即使數(shù)據(jù)同步的過程發(fā)生異常，服務(wù)實(shí)例也成功注冊(cè)到一個(gè) Nacos 服務(wù)中，對(duì)外部而言，整個(gè) Nacos 集群是可用的，也就達(dá)到了 AP 的效果

同時(shí)為了滿足 BASE 理論，Nacos 也有下面兩種機(jī)制保證最終節(jié)點(diǎn)間數(shù)據(jù)最終是一致的：

失敗重試機(jī)制

• 數(shù)據(jù)同步給其它節(jié)點(diǎn)失敗時(shí)，會(huì)每隔 3s 重試一次，直到成功

定時(shí)對(duì)比機(jī)制

• 每個(gè) Nacos 服務(wù)節(jié)點(diǎn)會(huì)定時(shí)向所有的其它服務(wù)節(jié)點(diǎn)發(fā)送一些認(rèn)證的請(qǐng)求
• 這個(gè)請(qǐng)求會(huì)告訴每個(gè)服務(wù)節(jié)點(diǎn)自己負(fù)責(zé)的服務(wù)實(shí)例的對(duì)應(yīng)的版本號(hào)，這個(gè)版本號(hào)隨著服務(wù)實(shí)例的變動(dòng)就會(huì)變動(dòng)
• 如果其它服務(wù)節(jié)點(diǎn)的數(shù)據(jù)的版本號(hào)跟自己的對(duì)不上，那就說明其它服務(wù)節(jié)點(diǎn)的數(shù)據(jù)不是最新的
• 此時(shí)這個(gè) Nacos 服務(wù)節(jié)點(diǎn)就會(huì)將自己負(fù)責(zé)的服務(wù)實(shí)例數(shù)據(jù)發(fā)給不是最新數(shù)據(jù)的節(jié)點(diǎn)，這樣就保證了每個(gè)節(jié)點(diǎn)的數(shù)據(jù)是一樣的了。

Nacos 的 CP 實(shí)現(xiàn)

Nacos 的 CP 實(shí)現(xiàn)是基于 Raft 算法來實(shí)現(xiàn)的

在 1.x 版本早期，Nacos 是自己手動(dòng)實(shí)現(xiàn) Raft 算法

在 2.x 版本，Nacos 移除了手動(dòng)實(shí)現(xiàn) Raft 算法，轉(zhuǎn)而擁抱基于螞蟻開源的 JRaft 框架

在 Raft 算法，每個(gè)節(jié)點(diǎn)主要有三個(gè)狀態(tài)

• Leader，負(fù)責(zé)所有的讀寫請(qǐng)求，一個(gè)集群只有一個(gè)
• Follower，從節(jié)點(diǎn)，主要是負(fù)責(zé)復(fù)制 Leader 的數(shù)據(jù)，保證數(shù)據(jù)的一致性
• Candidate，候選節(jié)點(diǎn)，最終會(huì)變成 Leader 或者 Follower

集群啟動(dòng)時(shí)都是節(jié)點(diǎn) Follower，經(jīng)過一段時(shí)間會(huì)轉(zhuǎn)換成 Candidate 狀態(tài)，再經(jīng)過一系列復(fù)雜的選擇算法，選出一個(gè) Leader

當(dāng)有寫請(qǐng)求時(shí)，如果請(qǐng)求的節(jié)點(diǎn)不是 Leader 節(jié)點(diǎn)時(shí)，會(huì)將請(qǐng)求轉(zhuǎn)給 Leader 節(jié)點(diǎn)，由 Leader 節(jié)點(diǎn)處理寫請(qǐng)求

比如，有個(gè)客戶端連到的上圖中的Nacos服務(wù)2節(jié)點(diǎn)，之后向Nacos服務(wù)2注冊(cè)服務(wù)

Nacos服務(wù)2接收到請(qǐng)求之后，會(huì)判斷自己是不是 Leader 節(jié)點(diǎn)，發(fā)現(xiàn)自己不是

此時(shí)Nacos服務(wù)2就會(huì)向 Leader 節(jié)點(diǎn)發(fā)送請(qǐng)求，Leader 節(jié)點(diǎn)接收到請(qǐng)求之后，會(huì)處理服務(wù)注冊(cè)的過程

為什么說 Raft 是保證 CP 的呢？

主要是因?yàn)?Raft 在處理寫的時(shí)候有一個(gè)判斷過程

• 首先，Leader 在處理寫請(qǐng)求時(shí)，不會(huì)直接數(shù)據(jù)應(yīng)用到自己的系統(tǒng)，而是先向所有的 Follower 發(fā)送請(qǐng)求，讓他們先處理這個(gè)請(qǐng)求
• 當(dāng)超過半數(shù)的 Follower 成功處理了這個(gè)寫請(qǐng)求之后，Leader 才會(huì)寫數(shù)據(jù)，并返回給客戶端請(qǐng)求處理成功
• 如果超過一定時(shí)間未收到超過半數(shù)處理成功 Follower 的信號(hào)，此時(shí) Leader 認(rèn)為這次寫數(shù)據(jù)是失敗的，就不會(huì)處理寫請(qǐng)求，直接返回給客戶端請(qǐng)求失敗

小細(xì)節(jié)需要注意

Nacos 在處理查詢服務(wù)實(shí)例的請(qǐng)求直接時(shí)，并不會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給 Leader 節(jié)點(diǎn)處理，而是直接查當(dāng)前 Nacos 服務(wù)實(shí)例的注冊(cè)表

這其實(shí)就會(huì)引發(fā)一個(gè)問題

如果客戶端查詢的 Follower 節(jié)點(diǎn)沒有及時(shí)處理 Leader 同步過來的寫請(qǐng)求（過半響應(yīng)的節(jié)點(diǎn)中不包括這個(gè)節(jié)點(diǎn)），此時(shí)在這個(gè) Follower 其實(shí)是查不到最新的數(shù)據(jù)的，這就會(huì)導(dǎo)致數(shù)據(jù)的不一致

所以說，雖然 Raft 協(xié)議規(guī)定要求從 Leader 節(jié)點(diǎn)查最新的數(shù)據(jù)，但是 Nacos 至少在讀服務(wù)實(shí)例數(shù)據(jù)時(shí)并沒有遵守這個(gè)協(xié)議

當(dāng)然對(duì)于其它的一些數(shù)據(jù)的讀寫請(qǐng)求有的還是遵守了這個(gè)協(xié)議。

數(shù)據(jù)模型

在 Nacos 中，一個(gè)服務(wù)的確定是由三部分信息確定

• 命名空間（Namespace）：多租戶隔離用的，默認(rèn)是public
• 分組（Group）：這個(gè)其實(shí)可以用來做環(huán)境隔離，服務(wù)注冊(cè)時(shí)可以指定服務(wù)的分組，比如是測(cè)試環(huán)境或者是開發(fā)環(huán)境，默認(rèn)是DEFAULT_GROUP
• 服務(wù)名（ServiceName）：這個(gè)就不用多說了

在服務(wù)注冊(cè)和訂閱的時(shí)候，必須要指定上述三部分信息，如果不指定，Nacos 就會(huì)提供默認(rèn)的信息

不過，在 Nacos 中，在服務(wù)里面其實(shí)還是有一個(gè)集群的概念

在服務(wù)注冊(cè)的時(shí)候，可以指定這個(gè)服務(wù)實(shí)例在哪個(gè)集體的集群中，默認(rèn)是在DEFAULT集群下

在 SpringCloud 環(huán)境底下可以通過如下配置去設(shè)置

spring  
    cloud:    
        nacos:      
            discovery:        
                cluster-name: sanyoujavaCluster

配置中心

Spring Boot 應(yīng)用
    ↓
Spring Cloud Nacos Config
    ↓
ConfigService（客戶端核心類）
    ↓
LongPollingRunnable（長輪詢?nèi)蝿?wù)）
    ↓
HTTP 請(qǐng)求 /nacos/v1/cs/configs/listener
    ↓
Nacos Server 檢測(cè)配置變化
    ↓
返回新配置 → 客戶端觸發(fā) Listener → 事件驅(qū)動(dòng)更新 Bean

Nacos 配置中心是支持配置項(xiàng)自動(dòng)刷新的，而其實(shí)現(xiàn)的原理是通過長輪詢+事件驅(qū)動(dòng)+本地回調(diào)機(jī)制的方式來實(shí)現(xiàn)的，具體來說：

• 客戶端向 Nacos 服務(wù)器發(fā)送一個(gè)帶有監(jiān)聽器(Listener)的請(qǐng)求，以獲取某個(gè)特定配置的值。
• Nacos 服務(wù)器接收到請(qǐng)求后，會(huì)檢查該配置是否發(fā)生了變化。如果沒有變化，則該請(qǐng)求將被阻塞，直到超時(shí)或配置發(fā)生變化。
• 當(dāng)配置發(fā)生變化時(shí)，Nacos 服務(wù)器會(huì)立即響應(yīng)，并將新的配置值返回給客戶端。
• 客戶端接收到新的配置值后，可以根據(jù)需要更新自身的配置。

長輪詢:服務(wù)器端接收到客戶端的請(qǐng)求之后，如果沒有數(shù)據(jù)更新，則連接保持一段時(shí)間，直到有數(shù)據(jù)或者超時(shí)才會(huì)返回。

gRPC 長連接是 Nacos 2.x 的推薦通信方式，性能更優(yōu)，但為保證兼容性、適配多語言客戶端和輕量場景，Nacos 仍然保留了 HTTP 長輪詢機(jī)制。兩者可以共存，動(dòng)態(tài)選擇，適配更廣泛的實(shí)際業(yè)務(wù)場景。

如何集成 Nacos Config 實(shí)現(xiàn)配置項(xiàng)動(dòng)態(tài)刷新？

使用 @NacosValue 注解注入配置

import com.alibaba.nacos.api.config.annotation.NacosValue;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;

@Component
public class NacosValueExample {

    @NacosValue(value = "${my.config.value}", autoRefreshed = true)
    private String configValue;

    @PostConstruct
    public void init() {
        System.out.println("讀取到配置：" + configValue);
    }

    public String getConfigValue() {
        return configValue;
    }
}

使用 @NacosConfigListener 手動(dòng)監(jiān)聽配置變更

import com.alibaba.nacos.api.config.annotation.NacosConfigListener;
import org.springframework.stereotype.Component;

@Component
public class NacosListenerExample {

    @NacosConfigListener(dataId = "my-config.yaml", groupId = "DEFAULT_GROUP")
    public void onChange(String newConfig) {
        System.out.println("配置發(fā)生變化，新內(nèi)容為：" + newConfig);
        // 你可以在這里解析 YAML 并手動(dòng)更新 Bean 或緩存
    }
}

使用 @ConfigurationProperties + @RefreshScope

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.stereotype.Component;

@Component
@RefreshScope
@ConfigurationProperties(prefix = "my.config")
public class ConfigPropertiesExample {

    private String value;

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

使用 bootstrap.yml 配置動(dòng)態(tài)讀取 Nacos 的配置

# bootstrap.yml
spring:
  application:
    name: nacos-demo  # 用作默認(rèn)的 dataId：nacos-demo.yaml
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml
        group: DEFAULT_GROUP
        namespace: public
        refresh-enabled: true     # 開啟全局自動(dòng)刷新
        extension-configs:
          - data-id: my-config.yaml
            group: DEFAULT_GROUP
            refresh: true        # 支持動(dòng)態(tài)刷新
配置項(xiàng)作用
server-addrNacos 服務(wù)地址
file-extension默認(rèn) dataId 后綴，比如 nacos-demo.yaml
refresh-enabled全局開啟動(dòng)態(tài)刷新
extension-configs可以加載多個(gè)額外配置文件
refresh: true為該配置開啟動(dòng)態(tài)刷新

Spring Boot 啟動(dòng)階段讀取 bootstrap.yml，初始化 Spring Cloud Nacos。

從配置中心讀取 dataId 對(duì)應(yīng)的配置（如 my-config.yaml），并注入到環(huán)境中。

如果設(shè)置了 refresh: true，則在配置變更時(shí)，Nacos 會(huì)通過監(jiān)聽機(jī)制自動(dòng)刷新對(duì)應(yīng)的 Bean。

• 如果你用的是 @RefreshScope 或 @NacosValue(autoRefreshed = true)，對(duì)應(yīng)字段會(huì)自動(dòng)更新。
• 也可以通過 /actuator/refresh 手動(dòng)刷新（Spring Cloud 原生方式）。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。