SpringCloud -- Nacos详细介绍

5. Nacos

5.1 Nacos介绍

Nacos 可以理解为微服务的“电话簿 + 遥控器”。它是阿里巴巴开源的一个核心工具，主要解决微服务架构中的两大问题：

5.1.1 服务注册与发现（电话簿）

服务注册：当某个微服务（比如“订单服务”）启动时，它会自动到 Nacos “登记”自己的位置（IP 和端口），就像在电话簿里存电话号码2410。
服务发现：其他微服务（比如“支付服务”）需要调用“订单服务”时，不用硬编码对方的地址，直接问 Nacos：“订单服务在哪？” Nacos 会返回健康的实例地址38。
健康检查：Nacos 会定时“打电话”检查服务是否活着，挂了就踢出列表，避免请求发到故障节点26。

5.1.2 动态配置管理（遥控器）

微服务通常有很多配置（如数据库地址、开关参数）。传统做法是改配置→重启服务，而 Nacos 允许配置集中托管。
修改配置后，Nacos 会实时推送给所有相关服务，无需重启，像用遥控器调设置一样方便249。
支持多环境隔离（开发/生产配置分开）、版本回滚等企业级功能910。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.2 Nacos快速入门

5.2.1 下载

https://github.com/alibaba/nacos/releases/download/2.2.3/nacos-server-2.2.3.zip

5.2.2 解压加配置

解压后修改配置文件里面的配置信息

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

修改项：

`nacos.core.auth.plugin.nacos.token.secret.key="VGhpc0lzTXlDdXN0b21TZWNyZXRLZXkwMTIzNDU2Nzg="`
nacos.core.auth.enabled=true
nacos.core.auth.server.identity.key="touper"
nacos.core.auth.server.identity.value="touper"

5.2.3 启动和访问

启动

在 bin 目录下进入命令行然后输入指令：startup -m standalone

访问

访问地址：http://localhost:8848/nacos/

登录账号和密码都是：nacos

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.2.4 服务注册

服务注册简介

服务只要导入部分依赖和添加少许配置，启动项目就会自动实现服务中心注册

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

采用父子工程模式

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

父工程进行微服务依赖的版本管理

子工程需要这个依赖只要导入依赖不需要版本信息

<properties><maven.compiler.source>17</maven.compiler.source><maven.compiler.target>17</maven.compiler.target><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><!--版本管理--><spring-cloud.version>2022.0.0</spring-cloud.version><spring-cloud-alibaba.version>2022.0.0.0</spring-cloud-alibaba.version>
</properties>
<dependencyManagement><dependencies><!--Web起步依赖--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>3.0.2</version></dependency><!--SpringCloud依赖--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>${spring-cloud.version}</version><type>pom</type><scope>import</scope></dependency><!--alibaba 对 springCloud 做了扩展--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>${spring-cloud-alibaba.version}</version><type>pom</type><scope>import</scope></dependency></dependencies>
</dependencyManagement>

子工程导入依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency><!--消费者服务还需要导入负载均衡依赖-->    
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>

子工程编写配置

Spring:application:name: provider-service-rest #服务名cloud:nacos:discovery:server-addr: localhost:8848 #nacos端口password: nacos #认证密码username: nacos #认证账号

消费者要在 restTemplate 配置类上加上负载均衡注解

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.3 Nacos临时实例和持久实例

5.3.1 临时实例和持久实例的转换

在 Nacos Client 进行实例注册的时候，默认设置为临时实例

1. 要实现临时实例和持久实例之间的转换首先要修改配置

spring:clound:nacos:discovery:ephemeral: false

2. 将原有实例销毁

先将Nacos服务停掉
在 nacos 目录下 \data\protocol\raft，删除下面的文件夹
再次重启 nacos 服务,发现临时实例为 false，表示现在是持久实例

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.3.2 临时实例和持久实例的区别

特性	持久实例	临时实例
生命周期	手动注册，手动注销	手动注册，自动注销（心跳超时）
健康检查	Nacos Server 主动探测	服务实例主动发送心跳
宕机处理	标记为不健康，但不删除	自动删除
适用场景	关键基础设施（DB, Cache, MQ）	动态业务微服务实例
类比	长租租客（不退租记录在）	酒店客人（不续卡自动退房）
核心优势	信息持久化，手动控制力强	自动容错清理，动态性好
主要缺点	需手动注销，可能堆积无效节点	依赖心跳网络，存在短暂不一致性

存在的核心意义：

持久实例： 为了保留信息。 确保关键服务的位置信息被持久记录，即使服务暂时不可用，也方便运维查看、排查和手动干预。它牺牲了一定的自动化，换来了信息的持久性和强控制力。
临时实例： 为了动态性和自愈能力。 适应现代应用快速变化、弹性伸缩的需求，自动处理实例故障，保证服务列表的实时性和可用性。它是构建高可用、可扩展微服务架构的基石。

简单来说：想让它“挂了也要留个名”（持久实例），还是“挂了就消失别碍事”（临时实例）？ Nacos 通过这两种类型，让你能根据服务的不同性质和重要性，灵活地管理服务实例的生命周期和可见性。临时实例是现代微服务的默认选择，而持久实例则用于那些需要特殊关照的“基石”服务。

5.4 Nacos保护阈值

保护阈值是 Nacos 在健康实例比例过低时触发的“保命机制”，通过临时返回不健康实例，防止因少数健康实例被压垮而导致服务完全崩溃。 这些不健康的实例主要起到分流的作用，防止所有请求都打到健康的实例上，到时健康的实例也被压垮致使这个服务的所有实例瘫痪，服务无法使用

可以理解为：当健康的“士兵”太少时，指挥官（Nacos）会让“轻伤员”也上战场，避免防线彻底失守。🪖⚔️

5.5 Nacos权重

权重是一种数值类型，通常取值范围在0到100之间，表示服务器的负载情况。在权重相同的情况下，Nacos默认使用轮询算法实现负载均衡，按照顺序依次轮询选择服务实例。

在服务治理中，负载均衡是一个非常常见的场景。通过设置每个服务实例的权重，可以请求更合理、均衡地分配到每个实例上，从而实现负载均衡的目的。

1. 修改实例的权重

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2. 在调用端的配置文件上加入

spring:cloud:loadbalancer:nacos:enabled: true

5.6 Nacos命名空间和分组

5.6.1 简介

我们可以通过命名空间和分组来对不同服务做隔离操作（不同的项目在不同的命名空间下），服务之间访问必须在一个命名空间一个组内。这样实现服务隔离的效果。这些如果不设置都有默认值

5.6.2 设置命名空间处理

步骤1：先在 nacos 中创建一个命名空间

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

步骤2：在模块中配置 yml 文件

spring:cloud:nacos:discovery:namespace: 1849a19c-ca38-4c3b-ba71-9fde8198e7ec

步骤3：在nacos中可以看到命名空间对服务的区分

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.6.3 设置组的处理

只要在配置文件中配置组名即可

spring:cloud:nacos:discovery:group: dev

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.7 Nacos集群管理

**在实际开发过程中，如果使用Nacos，为了确保高可用，一般都会对其进行集群的部署。**Nacos规定集群中，Nacos节点的数量需要大于等于3个节点，同时，单机模式下，naocs的数据默认保存在内嵌数据库中derby，不方便观察数据库存储的基本情况。而且如果集群中启动多个默认配置下的nacos节点，数据存储存在一致性问题。为了解决这个问题，nacos采用了集中式存储的方式来支持集群化部署，目前只支持mysql的存储

5.7.1 使用 Mysql 存储 Nacos

步骤1：创建数据库和表

创建2数据库后然后执行在 nacos 目录下 / conf / mysql-schema.sql 下的 Sql 脚本来创建表

步骤2：修改 application.properties 文件

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

步骤3：启动 nacos 验证

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

6.14.2 集群管理

我们这里使用一台电脑来模拟集群效果

步骤1：先创建一个 cluster 目录，复制三个 nacos 目录，分别命名不同端口号

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

步骤2：根据 cluster.conf.example 模板进行创建一个 cluster.conf 文件

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

步骤3：修改 application.properties 将端口号修改到对应的值

步骤4：启动 nacos，指令 startup，因为是集群启动方式，所以不需要有-m standalone参数

步骤5：访问 localhost:8858/nacos，或者 localhost:8868/nacos 或者 localhost:8878/nacos

步骤6：使用 nginx 反向代理

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

注意1：

我们启动 Nacos 部署所占用的端口实际上会有三个

会根据一定端口偏移量占用其他的端口，如 8848 偏移 1000 会占 9848。所以如果在一个服务器上，多端口模拟 nacos 集群，端口之间，不能紧相邻，要有一定间距

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

注意2：

如果集群不是使用mysql进行数据存储,启动时，指令后需要加 -p embedded

5.8 CAP理论

5.8.1简单介绍

CAP理论是分布式系统中最基础的理论，即一个分布式系统最多只能同时满足下面三种中的两种

一致性(Consistency)、
可用性(Avaliability)
分区容错性(Partition tolerance)

1. 一致性

对于客户端每次读操作，要么读到的是最新的数据，要么读取失败。站在分布系统的角度，对客户端的承诺，要么返回绝对一致的最新数据，要么返回一个错误，强调的是数据正确。一致性可以分为两种情况

强数据一致性：数据在各个节点之间随时保持完全一致，对数据的操作要么成功，要么失败
最终数据一致性：数据在各个节点之间在时间阈值内同步成功，保持数据的最终一致性

2. 可用性

任何客户端的请求，都要返回响应数据，不会出现响应错误。一定会返回数据，不会返回给错误，但不能保证数据最新，强调的是服务不出错

3. 分区容错性

由于分布式系统，通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会出现宕机问题。要求一定会一直运行，不管内部出现何种数据同步问题，强调的是不宕机，不挂掉。

对于一个分布系统而言，P 是前提条件，是必须要保证的。只要有网络交互，就一定会有延迟和数据丢失情况，我们必须接受，保证系统不能挂掉。对于 A 和 C 需要进行选择，要么保证数据一致性，要么保证系统可用性。

当选择C时，如果由于网络分区而无法保证特定信息是最新的，则系统将返回错误或超时。

当选择A时，系统将始终处理客户端的查询并尝试返回最新的可用的数据，即使由于网络分区而无法保证数据是最新的，也会返回一个可用数据。

5.9 Nacos支持模式

5.9.1 简单介绍

Nacos 支持 CP+AP 模式，使用 nacos 可以根据配置识别为 CP模式或 AP模式，默认是AP模式。

如果注册 nacos 的 client 节点 ephemeral=true，表示使用临时实例，nacos集群对这个client节点效果就是AP，采用 distro 协议实现(是nacos对于临时实例数据开发的一种一致性协议，其数据存储在缓存中，并会在启动时进行全量数据同步，并定期进行数据校验)。
如果注册 nacos 的 client 节点 ephemeral=false，表示使用持久实例，nacos 集群对这个 client 节点效果就是CP，采用 raft 协议实现。

5.9.2 .使用场景

对于一些数据一致性应该是首先被保证的业务场景（如银行项目），会遵循 CP 原则。
对于一些数据一致性较差的的情况但是也不会造成灾难性的结果，会遵循 AP 原则。

总之，服务注册中心到底选用CP还是AP，是根据业务场景决定。如果要求数据一致性很高，且可以容忍一定时间的不可用，可以选用CP模型。如果可以容忍一定时间延迟的数据不一致性，但不能容忍系统不可用，要选用AP模型

5.10 Nacos配置中心

5.10.1 配置中心的简介

🔧 为什么需要配置中心？——微服务的「集中控制室」

想象你管理着 10 个连锁奶茶店（微服务），突然要更换牛奶供应商（修改配置）。传统方式需要跑遍每个店修改配方（配置文件），而配置中心就像总部遥控系统——一键修改，所有门店立即生效！

🧩 传统配置的四大痛点 vs Nacos 的解决方案

痛点场景	生活比喻	Nacos 如何解决
1. 配置文件分散难管理	分店配方各自存放，总部无法统一调整	✅ 集中化管理：所有配置存到云端「保险柜」，统一查看/修改
2. 多环境配置混乱	试喝版/正式版配方混在一起容易出错	✅ 环境隔离：用不同「密码箱」（命名空间）隔离开发/测试/生产环境配置
3. 改配置必须重启服务	换原料就要关店装修，损失客流量	✅ 热更新：修改配方后自动推送，店铺（服务）无需停业立即生效
4. 配置泄露无防护	配方被竞争对手轻易窃取	✅ 权限保险：给店员（开发者）分不同钥匙（账号权限），敏感配方（数据库密码）只有店长能查看

💡 Nacos 配置中心的本质价值

把散落各处的「服务配方」收进智能保险箱，实现：
✨ 集中管控 + 🌈 环境隔离 + ⚡ 实时生效 + 🔒 安全防护

典型应用场景

秒级切换功能开关（如促销活动上线）
紧急更换数据库密码（无需停服）
动态调整线程池参数（应对流量高峰）
安全管控敏感配置（财务系统访问密钥）

5.10.2 配置中心数据同步模式

🚀 Push模式（推送式）

工作方式：
客户端与服务端建立 TCP长连接（如对讲机常开通道），配置变更时服务端主动推送新数据到客户端。
✅ 优势：

实时性强（毫秒级生效）
客户端逻辑简单（只需接收处理）

❌ 挑战：

长连接可能因网络故障"假死"
需心跳机制保活（如每隔30秒发送"我在线"信号）

🔍 Pull模式（拉取式）

1️⃣ 短轮询（原始版）

工作方式：
客户端定时（如每秒）向服务端主动请求配置（像不停打电话问"有更新吗？"）。
⚠️ 缺陷：

实时性差（最多延迟一个周期）
服务端压力大（90%请求是无效查询）
资源浪费（如10秒轮询时，第11秒更新的配置需等9秒生效）

2️⃣ 长轮询（智能升级版）⭐

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

工作方式：

客户端发起请求后，服务端不立即响应
两种结束条件：
- 有变更：立即返回新数据（如等待3秒时第2秒发生变更）
- 超时无变更：空响应后客户端重新发起（如等待30秒无变化）

✅ 优势：

实时性接近Push（通常等待30秒内）
服务端压力骤降（无变更时不频繁响应）
容错性强（适应网络波动）

🔧 Nacos的实战策略

配置中心通常会提供配置变更、配置推送、历史版本管理、灰度发布等功能。通过这些功能，可以降低分布式系统中管理配置信息的成本，降低因为错误的配置信息变更带来的服务可用性下降和发生故障的风险。

灰度发布：
像「新品试吃」——先让1%用户尝新配置，验证无问题再全量推送

5.10.3 nacos配置中心使用

主流的配置中心：

Spring cloud config、Apollo(携程)、Disconf(百度)、Nacos(阿里)

步骤1：启动 Nacos，然后在配置管理中创建一个配置

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

步骤2：在客户端，导入配置中心依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

步骤3：配置 application.yml 文件

spring:cloud:nacos:config:server-addr: localhost:8848password: nacosusername: nacosconfig:import: optional:nacos:provider-rest-8001.yml

步骤4：获取配置中心配置

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.10.4 Nacos 配置的动态更新

我们不但可以在主程序通过 Enviroment 获取配置信息，也可以通过 @Value 获取，但是一开始不想主程序是动态实时更新的，需要加上 @RefreshScope 注解才能实现动态更新

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

RefreshScope 是 Spring Cloud 中的一个注解，主要用于实现配置中心的动态刷新功能。在微服务架构中，配置管理是一个重要的问题。通常，配置是在应用程序启动时加载并缓存起来的。但是，在某些情况下，需要动态地修改配置，例如在运行时修改配置文件，或者使用配置中心来管理配置。为了解决这个问题，Spring Boot 提供了 @RefreshScope 注解。

5.10.5 支持 profile 粒度的配置

在配置中心，创建了两个不同环境的配置，表示在不同环境下的配置文件

方式1：在程序的配置文件中，使用下面的配置方式，指定当前的环境

spring:profiles:active: prod

方式2：通过添加虚拟机选项

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

方式3：覆盖配置属性

5.10.6 支持命名空间和组的配置

我们可以给配置文件创建命名空间和组，在客户端指定所属的命名空间和分组，这样是无法读取其他命名空间和组的配置信息的。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.10.7 多个配置读取

优先级是后加载的会覆盖先加载的

config:import:- optional:nacos:${spring.application.name}.${spring.cloud.nacos.config.file-extension}- optional:nacos:mysql-config.yml