Nacos 學習記錄 - 使用
一、基礎概念
1、命名空間
用於進行租戶粒度的配置隔離。不同的命名空間下，可以存在相同的 Group 或 Data ID 的配置。
Namespace 的常用場景之一是不同環境的配置的區分隔離，例如開發測試環境和生產環境的資源（如配置、服務）隔離等。
2、配置集 ID - Data ID
Nacos 中的某個配置集的 ID。配置集 ID 是組織划分配置的維度之一。
Data ID 通常用於組織划分系統的配置集。一個系統或者應用可以包含多個配置集，每個配置集都可以被一個有意義的名稱標識。
Data ID 通常采用類 Java 包（如 com.taobao.tc.refund.log.level）的命名規則保證全局唯一性。此命名規則非強制。
3、配置分組 - Group
Nacos 中的一組配置集，是組織配置的維度之一。通過一個有意義的字符串（如 Buy 或 Trade ）對配置集進行分組，從而區分 Data ID 相同的配置集。
當您在 Nacos 上創建一個配置時，如果未填寫配置分組的名稱，則配置分組的名稱默認采用 DEFAULT_GROUP 。
配置分組的常見場景：不同的應用或組件使用了相同的配置類型，如 database_url 配置和 MQ_topic 配置。
4、配置快照
Nacos 的客戶端 SDK 會在本地生成配置的快照。當客戶端無法連接到 Nacos Server 時，可以使用配置快照顯示系統的整體容災能力。
配置快照類似於 Git 中的本地 commit，也類似於緩存，會在適當的時機更新，但是並沒有緩存過期（expiration）的概念。
二、注冊中心
三、配置中心
首先，在 nacos 服務端新建配置
1、配置文件命名規則
dataId 的完整格式如下：
${prefix}-${spring.profiles.active}.${file-extension}
說明：
prefix： 默認為 spring.application.name 的值，也可以通過配置項 spring.cloud.nacos.config.prefix來配置。
spring.profiles.active： 即為當前環境對應的 profile。 注意：當 spring.profiles.active 為空時，對應的連接符 - 也將不存在，dataId 的拼接格式變成 ${prefix}.${file-extension}
file-exetension： 為配置內容的數據格式，可以通過配置項 spring.cloud.nacos.config.file-extension 來配置。目前只支持 properties 和 yaml 類型
2、內容
配置跟配置文件擴展名對應類型的配置內容。
例如：
.properties 文件
.yml 文件
其次，在 spring-cloud 項目中配置 bootstrap.yml 文件
注意：
1、項目中不要配置 application.yml，application-dev.yml，application.properties，application-dev.properties 配置文件；
2、file-extension 項要與 nacos 中對應的配置文件的擴展名一致。
3、@RefreshScope 實時刷新
@RefreshScope注解能幫助我們做局部的參數刷新，但侵入性較強，需要開發階段提前預知可能的刷新點，並且該注解底層是依賴於cglib進行代理的。
配置 bootstrap.yml 文件如下：
server: port: 9001 spring: application: name: user-service profiles: active: dev --- #開發環境配置 spring: profiles: dev cloud: nacos: discovery: server-addr: xx.xxx.xx.xxx:8848 ip: xx.xxx.xx.xxx # ${prefix}-${spring.profile.active}.${file-extension} config: server-addr: xx.xxx.xx.xxx:8848 file-extension: yml enabled: true
問題：
一、Nacos微服務注冊地址為內網IP的解決辦法
解決辦法：配置固定IP 和 端口號
spring.cloud.nacos.discovery.ip = 本機公網IP
spring.cloud.nacos.discovery.port = 服務端口
二、配置緩存
待續。。。
集群選舉
一致性算法：Nacos集群采用 raft 算法來實現
選舉說明：
在Raft中，節點有三種角色：
- Leader：負責接收客戶端的請求
- Candidate：用於選舉Leader的一種角色(競選狀態)
- Follower：負責響應來自Leader或者Candidate的請求
選舉分為兩個節點
- 服務啟動的時候
- leader掛了的時候
所有節點啟動的時候，都是follower狀態。 如果在一段時間內如果沒有收到leader的心跳（可能是沒有leader，也可能是leader掛了），那么follower會變成Candidate。然后發起選舉，選舉之前，會增加 term，這個 term 和 zookeeper 中的 epoch 的道理是一樣的。
follower會投自己一票，並且給其他節點發送票據vote，等到其他節點回復在這個過程中，可能出現幾種情況
- 收到過半的票數通過，則成為leader
- 被告知其他節點已經成為leader，則自己切換為follower
- 一段時間內沒有收到過半的投票，則重新發起選舉
約束條件在任一term中，單個節點最多只能投一票
選舉的幾種情況 :
第一種情況，贏得選舉之后，leader會給所有節點發送消息，避免其他節點觸發新的選舉
第二種情況，比如有三個節點A B C。A B同時發起選舉，而A的選舉消息先到達C，C給A投了一票，當B的消息到達C時，已經不能滿足上面提到的約束條件，即C不會給B投票，而A和B顯然都不會給對方投票。A勝出之后，會給B,C發心跳消息，節點B發現節點A的term不低於自己的term，知道有已經有Leader了，於是轉換成follower
第三種情況， 沒有任何節點獲得majority投票，可能是平票的情況。加入總共有四個節點（A/B/C/D），Node C、Node D同時成為了candidate，但Node A投了NodeD一票，NodeB投了Node C一票，這就出現了平票 split vote的情況。這個時候大家都在等啊等，直到超時后重新發起選舉。如果出現平票的情況，那么就延長了系統不可用的時間,因此raft引入了 randomizedelection timeouts來盡量避免平票情況.
心跳機制
待續。。。
參考資料：
Spring Cloud Alibaba Nacos（心跳與選舉）