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来尽量避免平票情况.
心跳机制
待续。。。
参考资料：