当前位置：首页 > news >正文

《Nacos终极指南：集群配置+负载均衡+健康检查+配置中心全解析，让微服务稳如老狗！》

news 来源：原创 2025/5/25 5:38:26

在生产环境比较恶劣的情况下，我们需要通过负载均衡对服务的流量分散到多个服务器中，避免单点故障，而Nacos支持多种负载均衡策略，包括权重，同机房，同地域，同环境等。

1.服务下线

当一个节点上接口的性能较差时，我们可以第一时间对该节点进行下线，等排查完故障后，我们在上线该节点

操作步骤：详情->下线

下线端口号为9091的接口后，当再进行访问订单服务后，发现通过IDEA日志发现该服务没有接收到请求

再次点击上线端口为9091的节点，接着多次访问订单服务，观察运行日志，发现端口号为9091的节点又可以重新接收请求

2.权重配置

2.1 权重配置

除了下线接口性能较差的节点之外，我们还可以配置这个节点的流量权重

操作步骤：找到对应的节点->编辑->在弹出的窗口修改权重值

2.2 开启Nacos的负载均衡策略

如果我们仅仅是在Nacos修改了权重配置，这样是不生效的。

因为Spring Cloud LoadBalance组件自身有负载均衡的配置方式，所以不支持Nacos的权重属性配置，我们需要开启Nacos的负载均衡策略，让权重配置生效

我们需要在服务消费者（订单服务）的配置文件中添加一下配置，如下图

修改完配置后记得重新启动服务，然后继续多次访问订单服务，此时观察日志发现端口号为9090的节点接收到的请求流量就会明显减少

2.3 常见问题

修改权重配置时，可能会出现下图的报错日志

原因：Nacos采用raft算法来计算Leader，并且会计算前一次启动的集群环境，当服务器的IP改变时会导致raft记录的集群地址失效，导致Leader出现问题（网络环境发生变化时，IP地址可能会发生变化）

解决方法：删除Nacos根目录下data文件中的protocol文件夹中的raft文件夹，如下图

3.同集群优先访问

Nacos把可以把同一个机房内的实例，划分为一个集群，所以同集群优先访问，在一定程度上也可以理解为同机房的实例优先访问

在微服务架构中，一个服务通常可以由多个实例共同提供服务，这些实例可以部署在不同的机器上，这些机器也可以分布在不同的机房，比如produc-service

实例1和实例2部署在上海机房，而实例3部署在北京机房

微服务访问时，应尽量访问同机房的实例，当本机房实例不可用时，才去访问其他机房的实例

比如order-service服务在上海机房，product-service在北京和上海都有实例，当使用订单服务时，希望优先访问上海机房，如果上海机房没有实力或者实例不可用，订单服务在去访问部署在上海机房的产品服务。

通常情况下，希望优先访问同一个机房间的服务，因为同一个机房属于一个局域网，局域网的访问速度更快一点

3.1 给实例配置集群名称

通过在添加一下配置来实现

注意：也要添加配置开启Nacos的负载均衡策略，如果之前添加过开启Nacos负载均衡策略的配置，这次就不用再次配置了

此时，就发现有一个product-service的实例是在名字为BJ的集群中的，而orders-service服务也是配置在BJ集群

此时，再去调用订单服务时，订单服务就会先优先访问与自己在同一个集群中的产品服务

此时，在将端口号为9091和9092的产品服务放在SH集群中

通过观察Nacos主页发现成功将端口号为9091和9092的产品服务放在SH集群中，当我们将部署在BJ集群的产品服务下线后，这时候再去调用订单服务时，此时订单服务访问的就是部署在SH集群中的产品服务

4.Nacos检查机制

Nacos作为注册中心，需要感知服务的健康状态，才能为服务消费者提供良好的服务，Nacos中提供了两种健康检查机制：

1.客户端主动上报机制：

1.服务注册方通过上传心跳的上报方式告知Nacos注册中心自己的健康状态，默认心跳的间隔为5秒

2.如果Nacos在15秒内没有接收到来自服务注册方的心跳，会将该服务的健康状态设置为不健康状态，如果Nacos没有接收心跳的时间间隔超过30秒，Nacos就会将该注册的服务删除。

2.服务端反向探测机制：

1.Nacos主动探知客户端的健康状态，默认间隔为20秒

2.健康检查失败后对应注册在Nacos的服务会被标记为不健康的状态，不会立即被删除

但是Nacos中的健康检查机制不能主动设置，健康检查机制是和Nacos的服务实例类型强相关的

4.1 Nacos服务类型实例

Nacos的服务实例（注册的服务）分为临时实例和非临时实例

临时实例：如果该注册的服务宕机超过一定时间，会从服务列表中删除，这是向Nacos注册服务时默认的实力类型

非临时实例：如果实例宕机，不会从服务列表中删除，也可以叫永久实例

Nacos对临时实例采取的是客户端主动上报机制，对非临时实例采取服务端反向探测机制

4.2 配置永久实例

只需要给注册的服务类型添加一下配置即可

重新启动服务，观察Nacos服务列表

去IDEA停止服务，再去观察Nacos服务列表，发现即使停止服务，注册在Nacos中的服务也不会从服务列表中删除

4.3 常见问题

Nacos服务实例类型是不允许改变的，此时如果直接增加上面的配置，重新启动该服务，就会包下图的错误

原因：因为Nacos会记录每个实例的IP和端口号，当发现IP和端口号都没有发生变化时，Nacos不允许服务类型发生变化，比如从临时实例变为非临时实例，或者从非临时实例变成临时实例

解决方法：

1，先停掉Nacos

2，删除nacos目录下的/data/protocol中的raft文件夹，raft文件夹里面会保存应用实例的元数据信息，注意如果你访问的是云服器上的Nacos，就去删云服务器上的raft文件夹，如果是本机上的Nacos，就去删除本机上的raft文件夹，路径都是一样的

5. Nacos环境隔离

在开发中，一个服务会分为开发环境，测试环境和生产环境，我们希望开发环境的服务只能访问开发环境中的服务，不能跨环境访问

Nacos中提供了namespace（命名空间）来实现环境的隔离，不同的namespace的服务之间不可相互访问

先在Nacos创建几个环境，如下图

新增命名空间

在服务列表页面就可以看到三个环境了

配置namespace

namespace创建完成后，对服务进行配置，如下图

重新启动服务，发现两个服务都被部署在了test的环境下

进行测试：发现服务调用成功

测试不同环境下能否访问成功：

public环境下只有product-service服务

dev环境下只有order-service

此时去访问订单服务，会出现下图的报错

通过实验证明，在Nacos中，不同环境下的服务是不可相互调用的。

6.Nacos配置中心

除了注册中心和负载均衡之外，Nacos还是一个配置中心，具备配置管理的功能

为什么需要配置中心呢？

我们当前的代码有一个问题，就是我们的配置都是写在代码里面的，当我们需要对配置进行修改时，就要对代码的配置文件进行修改，然后重新打包和上线，且一个微服务中可能有成百个实例，挨个部署容易出错

配置中心就是对这些配置项进行统一管理，通过配置中心，可以集中查看，修改和删除配置，无需再逐个修改配置文件，提供效率的同时，也降低了出错的分险

6.1配置中心的工作流程

1.服务启动时，从配置中心读取配置项的内容，进行配置的初始化

2.当配置中心的配置项发生改变时，配置中心会通知微服务，实现配置的更新加载

6.2Nacos配置中心的快速上手

1.添加配置

在Nacos控制台中添加配置项

注意事项：配置管理的命名空间和服务列表的命名空间是隔离的，两个是分别设置的，默认都是public，也就是服务列表的命名空间≠配置管理的命名空间

新建配置项

2.获取配置

1.在对应项目中的pom文件中引入下面的依赖

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

2.增加bootstrap.propertities配置文件

微服务启动前，需要先获取Nacos中的配置，并于application.yml配置合并，在微服务启动前，Nacos要求必须使用bootstrap.properties配置文件来配置Nacos Server地址

3.编写controller层代码

@RefreshScope
@RestController
public class NacosController {@Value("${nacos.config}")private String config;@RequestMapping("/getConfig")public String getConfig(){return "从Nacos中获取配置信息nacos.config："+config;}}

4.测试接口

发现获取配置成功

此时，修改配置中心的配置，刷新发现此时也成功获取修改后的配置信息

3.常见问题

1.配置格式出现错误

此时访问接口时会出现下面的报错

此时如果重新启动服务则会出现下图的报错

2.未引入相关依赖

出现下图的报错

原因：bootstrap.properties是系统及的资源配置文件，用于程序执行更加早期配置信息读取，但是SpringCloud2020.*之后的版本把bootstrap禁用了，导致在读取文件时读取不到而报错，此时将bootstrap包重新导入进来进行了

6.3配置中心详解

1.设置命名空间

Nacos配置中心的命名空间和服务列表的命名空间是分别设置，默认都是public，Nacos命名空间的配置依然是在bootstrap.properties文件中进行配置

添加一下配置

重启服务，接着去获取Nacos配置中心的配置，此时就是从test环境下获取配置

2.Data Id详解

Data Id格式介绍

在Nacos Spring Cloud中，Data Id的完整格式如下：

${prefix}-${spring.profiles.active}.${file-extension}

信息介绍

1.prefix默认为spring.application.name的值

2.spring.profiles.active对应当前环境的profile，当spring.profiles.active为空时，对应的连接符-也将不存在，dataId的拼接格式变成${prefix}.${file-extension}

3.file-extension为配置内容的数据格式，现在只支持yaml和properties这两种格式