[Spring Cloud] Nacos核心功能详解：从负载均衡到配置中心的全链路实践

在微服务架构中，Nacos 作为阿里巴巴开源的服务发现与配置管理平台，已成为Spring Cloud生态的核心组件之一。它不仅能实现服务的注册与发现、健康检查，还能统一管理分布式系统的配置信息，解决"配置分散、动态更新难"等痛点。本文将结合大纲内容，从负载均衡、健康检查、环境隔离、配置中心四大维度，拆解Nacos的核心功能与实践逻辑。

负载均衡

复制多个配置

并配置端口

1.服务下线(上线)

可以在详情页面手动下线

下线后,再次请求接口http://127.0.0.1:9096/order/1 会发现该服务无法请求

再次点击上线,该服务又恢复请求

2.权重配置(非严格)

如果不支持修改权重需要进行一下配置

Nacos服务实例权重不影响流量分配的原因-微服务引擎-阿里云

html 复制代码

Spring:
    cloud:
    loadbalancer:
      nacos:
        enabled: true      # 启用Nacos权重支持
      ribbon:
        enabled: false     # 禁用Ribbon（Spring Cloud 2022+默认禁用）

如果效果不明显,可以将差距拉大

3.同集群优先访问

配置集群名称

复制项目的配置

-Dspring.cloud.nacos.discovery.cluster-name=BJ

-Dspring.cloud.nacos.discovery.cluster-name=SH

真实项目的配置

java 复制代码

spring:
  cloud:
    nacos:
      discovery:
        cluster-name: SH #集群名称: 上海集群

将 9092 端口单独设置为 BJ 集群 , 多次访问http://127.0.0.1:9096/order/1 可以发现只有和 order-service(SH 集群) 集群相同时才会被访问到 ; 此时将 9091 和 9095 下线 , 9092 重新收到请求

健康检查

nacos 作为注册中心 , 需要感知服务的健康状态 , 才能为服务调用方提供良好服务

nacos 提供两种健康检查机制

Nacos 服务实例类型

默认服务类型为临时实例

复制代码

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false# 设置为⾮临时实例

重新启动服务发现报错

原因 : nacos 本身不支持修改服务类型 , 需要删除配置信息

解决方法

① 找出并杀死 nacos 进程 ps -ef|grep nacos 找到进程 ID ; kill -15 ID 杀死进程

② 删掉/data/protocol/raft 信息(本机同理)

cd protocol

rm -rf raft/

③ 重启服务

cd ../.. cd /bin 回到 /bin 目录

bash startup.sh -m standalone 单机模式启动

④ 删除本机 /craf 文件并重新启动服务(idea)

设置成功之后 , 如果停掉 idea 服务 , 也不会下线

nacos 环境隔离

开发环境,测试环境,预发布环境,发布环境

通常 , 这几个环境之间是不能互相通信的 , nacos 提供了 namespace(命名空间来实现环境隔离) , 不同的 namespace 的服务不可见

在 nacos 工作台创建两个环境

对 order-service 配置命名空间

html 复制代码

spring:
  cloud:
    nacos:
      discovery:
        namespace:  #服务管理命名空间 自动生成或者指定的空间

再进行远程调用 , 访问 http://127.0.0.1:9096/order/1 , 失败

只有将 product-service 也添加到命名空间才能成功访问

Nacos 配置中心

用来解决以下问题 :

配置中心是对这些配置项进行统一管理 . 通过配置中心 , 可以查看,修改,删除配置 , 无需再组个修改 , 提高效率 , 降低风险

① 添加配置

此前 服务管理的命名空间 不等同于 配置管理的命名空间

分别再 public 和 dev 环境下创建配置

nacos.config: public

nacos.config: dev

② 引入相关依赖

引入 Nacos config 依赖

html 复制代码

<!-- SpringCloud 2020.*之后版本需要引⼊bootstrap-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

③ 修改配置文件 (此处省略)

由于此前出现过因配置文件产生的报错 , 所以把 application.yml 更名为 bootstrap.yml

由于微服务启动后 , 需要获取 nacos 配置 , application.yml 和 bootstrap.yml 文件会合并 , 并且在微服务中 , bootstrap.yml 会先与 application.yml 加载

添加 application.yml

html 复制代码

spring: 
  application: 
    name: product-service 
cloud: 
  nacos: 
    config: 
      server-addr:           # 此处使用你的地址

④ 编写程序(便于观察配置管理)

注意编写的包名与配置管理的名称一致

java 复制代码

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RequestMapping("/config")
@RestController
@RefreshScope  //热更新
public class NacosController {

 @Value("${nacos.config}") #从配置文件中读取配置
 private String nacosConfig;

 @RequestMapping("/get")
 public String get() {
    return nacosConfig;
 }
}

@RefreshScope //热更新可以实时获取到服务中心最新的配置(不需要重启服务)

@Value("${nacos.config}") 需要和

保持一致

启动服务可能会出现报错 , 这是配置中心的格式不匹配等问题 , 检查一下刚发布的配置服务是否正确(配置格式和配置内容不符合)

访问http://127.0.0.1:9095/config/get

默认读取到了 public 中的配置管理

配置中心详解

1.设置配置管理的命名空间

和配置环境的命名空间类似

配置对应的命名空间的 ID

复制代码

spring:
  cloud:
    nacos:
      config:
        namespace: fe19f572-f4b8-423f-a783-def2beba9ca4 #命名空间

重新访问 http://127.0.0.1:9095/config/get

如果没有变化需要查看两个环境的配置内容是否正确(可能配置的相同)

2.Data ID

复制代码

spring:
  profiles:
    active: dev  					#上面提到的 file-entension
  cloud:
    nacos:
      config:
        file-extension: yaml    #改变数据格式为yaml

测试三个文件的优先级

product-service-dev.yml > product-service-dev.yaml > product-service

再次访问http://127.0.0.1:9095/config/get

3 个配置文件的作用

最高优先级： product-service-dev.yaml**(或** .yml**)**

- 作用：这是当前激活环境（dev）的专属配置。它里面的配置会覆盖下面所有同名配置。
- 场景：开发环境的数据库地址、测试用的 API Key、本地调试的端口等。
- 关键点 ：你的应用日志显示它在找这个文件，但因为你 Nacos 里存的是 .properties，所以它没找到内容，导致"看起来没生效"。

中等优先级： product-service.yaml**(或** .yml**)**

- 作用：这是服务的全局公共配置，不区分环境。
- 场景：所有环境都一样的配置，比如服务名、通用的线程池大小、默认的超时时间等。
- 注意：如果 dev 环境里没有某个配置项，系统会自动来这里找。

最低优先级： product-service**(无后缀)**

- 作用：这是最基础的兜底配置，通常用于存放一些不会变的、最核心的元数据。
- 场景：极少使用，一般只在非常特殊的情况下作为最后的保险。
- 现实情况 ：绝大多数项目根本不会创建这个文件，因为 product-service.yaml 已经足够作为全局配置了。

部署服务

修改配置文件中的密码

添加数据库

打包并上传到服务器

启动服务

后台启动 order-service
复制代码
nohup java -jar order-service.jar >logs/order.log &
后台启动 product-service
复制代码
nohup java -jar product-service.jar >logs/product-9090.log &
指定端口启动 product-service (9091)
复制代码
nohup java -jar product-service.jar --server.port=9091 >logs/product-9091.log &