Nacos服务管理

1.前言

在当前的分布式系统和微服务架构中，服务发现和管理变得至关重要。Nacos（NAme COntrol Service）作为一个开源的动态服务发现、配置管理和服务管理平台，为解决这些挑战提供了一站式的解决方案。其提供的负载均衡、分环境管理、权重配置、同集群优先访问和健康检测等功能，使得 Nacos 成为了构建高可用性、可扩展性和灵活性的分布式系统的不可或缺的工具。在本文中，我们将深入探讨 Nacos 的这些强大功能，以及它们为什么成为了微服务架构中的关键组件。

2. Nacos负载均衡

生产环境相对是比较恶劣的, 我们需要对服务的流量进行更加精细的控制. Nacos支持多种负载均衡策略, 包括权重, 同机房, 同地域, 同环境等

2.1 服务下线

当某一个节点上接口的性能较差时, 我们可以第一时间对该节点进行下线.

操作步骤: 服务详情 -> 下线

点击下线后, 再次请求接口, 会发现该服务没有请求进来了
再次单击上线, 该节点会继续收到请求.

2.2 权重配置

除了下线之外, 我们也可以配置这个节点的流量权重。比如一个节点的速度很慢，我可以对其的权重设置的小一点，来减轻该服务器的压力。

2.2.1 配置权重

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

每个节点默认权重为1, 修改为0.1

2.2.2 开启Nacos负载均衡策略

由于Spring Cloud LoadBalance组件自身有负载均衡配置方式, 所以不支持Nacos的权重属性配置，运行的是spring_cloud自带的负载均衡，需要在yml配置文件中开启nacos的负载均衡策略。我们需要开启Nacos的负载均衡策略, 让权重配置生效

参考链接:

如何解决MSE Nacos上修改服务实例的权重不生效问题_微服务引擎(MSE)-阿里云帮助中心 (aliyun.com)

spring:
cloud:
loadbalancer:
nacos:
enabled: true

这段代码配置了Spring Cloud中的负载均衡器（LoadBalancer）使用Nacos作为服务注册中心时的开启状态。当你的微服务需要在Spring Cloud环境下进行负载均衡，并且希望使用Nacos作为

服务注册中心时，可以通过设置 spring.cloud.loadbalancer.nacos.enabled为true来启用Nacos的负载均衡策略。

2.2.3 测试权重配置

启动服务, 访问多次接口, 观察结果, 会发现9091端口号的实例接收请求明显比另外两个实例少。

整体流量生效, 局部流量不是严格按照设置的比例进行分配的，就是只是只是概率问题，并不是绝对，比如你有一万个测试用例会按照 10 ： 1 进行访问，但你只有两个就很有可能是 1 ： 1，

2.2.4 常见的问题

修改权重的时候，可能会报错。

报错信息: caused: errCode: 500, errMsg: do metadata operation failed ;caused:

com.alibaba.nacos.consistency.exception.ConsistencyException: The Raft Group

[naming_instance_metadata] did not find the Leader node;caused: The Raft Group

[naming_instance_metadata] did not find the Leader node;

原因: Nacos 采用raft 算法来计算 Leader, 并且会记录前一次启动的集群地址, 当服务器 IP 改变时会导致 raft 记录的集群地址失效, 导致选 Leader 出现问题. (网络环境发生变化时, IP地址也会发生变化)

解决办法: 删除 Nacos 根目录下 data 文件夹下的 protocol 文件夹即可.

这个报错的原因：是Nacos采用Raft算法来选举Leader节点，并且会记录上一次启动时的集群地址。当服务器的IP地址发生变化时，会导致之前记录的集群地址失效，从而导致选举Leader节点时出现问题。

具体来说，Nacos在启动时会生成一个唯一标识符（通常是基于机器的IP地址和端口），用于在Raft协议中识别节点。如果服务器的IP地址发生了变化，之前生成的唯一标识符就无法与当前的IP地址匹配，导致Raft协议无法正确选举Leader节点。

解决这个问题的方法是删除Nacos根目录下data文件夹下的protocol文件夹。这样做会清除之前记录的集群地址信息，使得Nacos在下一次启动时重新生成新的唯一标识符，从而解决IP地址变化导致的问题。

总之，当Nacos服务器的IP地址发生变化时，需要手动清除旧的集群地址信息，以确保Raft算法能够正确选举Leader节点。

2.3 同集群优先访问

在同一集群内的服务通常具有更低的网络延迟，因为它们之间的数据传输不需要经过长距离的网络链路。通过优先访问同集群的服务，可以减少请求的网络往返时间，提升服务调用的响应速度。离得近，肯定速度要快，可以降低跨机房通信的频率，从而节省网络带宽和成本。

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

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

实例1: 分布在上海机房
实例2: 分布在上海机房
实例3: 分布在北京机房
实例4: 分布在北京机房

微服务访问时,应尽量访问同机房的实例，当本机房内实例不可用时，才访问其他机房的实例，比如order-service 在上海机房, product-service 在北京和上海机房都有实例, 那我们希望可以优先访问上海机房, 如果上海机房没有实例, 或者实例不可用, 再访问北京机房的实例. 通常情况下, 因为同一个机房的机器属于一个局域网, 局域网访问速度更快一点。

2.3.1 给实例配置集群名称

1. 为product-service配置集群名称，为模块配置集群名称。

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

spring: 这是Spring Boot配置的根级别。
cloud: 这指定了与Spring Cloud相关的配置。
nacos: 在cloud下面，你有nacos部分，其中包含了针对Nacos的设置。
discovery: 在nacos部分下，discovery用于与服务发现相关的配置。
server-addr: 这指定了用于服务发现的Nacos服务器的地址。在这里，它被设置为127.0.0.1:10020。
cluster-name: 这指定了集群名称。这里设置为SH，表示集群名称为"上海集群"。

这个配置告诉Spring Cloud使用Nacos作为服务发现机制，并将其指向位于127.0.0.1:10020的Nacos服务器，集群名称为"上海集群"。

2. 重启服务, 观察Nacos控制台, SH集群下多了⼀个实例

复制product-service启动配置, 添加VM Option ，使用命令参数的形式，启动springboot容器并且指定配置内容。设置统一模块的不同配置内容启动。

设置启动端口为9091，机房为BJ。

-Dserver.port=9091 -Dspring.cloud.nacos.discovery.cluster-name=BJ

设置启动端口为9092，机房为BJ。

-Dserver.port=9092 -Dspring.cloud.nacos.discovery.cluster-name=BJ

查看结果启动成功

2.3.2 开启Nacos负载均衡策略

运行的是spring_cloud自带的负载均衡，需要在yml配置文件中开启nacos的负载均衡策略。

spring:
cloud:
loadbalancer:
nacos:
enabled: true

spring: 这是Spring Boot配置的根级别。
cloud: 这指定了与Spring Cloud相关的配置。
loadbalancer: 在cloud下面，您有loadbalancer部分，用于配置负载均衡器。
nacos: 在loadbalancer部分下，nacos用于指定Nacos作为负载均衡器的配置。
enabled: 这指定了Nacos负载均衡器的启用状态，设置为true表示启用。

这个配置告诉Spring Cloud将Nacos作为负载均衡器，并将其启用。

3. Nacos的健康检查

3.1 两种健康检查机制

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

Nacos 中提供了，两种健康检查机制：

客户端主动上报机制（用于临时实例（临时工））：
1. 客户端会向服务端(nacos)发送心跳包，默认心跳间隔是5秒。
2. nacos会在超过15秒未收到心跳后将实例设置为不健康的状态，超过30秒将会删除。
3. 举例：员工主动上报，员工每天主动汇报自己的工作状态。
服务器反向探测机制（永久实例（正式工））：
1. nacos主动探知客户端的状态，默认是20秒。
2. 健康检测失败后实例会被标记为不健康，不会立即删除。
3. 举例：领导每周向员工了解工作进度。

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

3.2 Nacos服务实例类型

Nacos的服务实例(注册的节点)分为临时实例和非临时实例.

临时实例: 如果实例宕机超过一定时间，会从服务列表剔除，默认类型.
非临时实例: 如果实例宕机，不会从服务列表剔除，也可以叫永久实例

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

配置一个服务实例为永久实例（默认是临时实例）

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

设置了Nacos服务发现中实例的生命周期为非临时实例。

spring: 这是Spring Boot配置的根级别。
cloud: 这指定了与Spring Cloud相关的配置。
nacos: 在cloud下面，您有nacos部分，其中包含了针对Nacos的设置。
discovery: 在nacos部分下，discovery用于与服务发现相关的配置。
ephemeral: 这个属性指定了Nacos中实例的生命周期。将其设置为false表示非临时实例，即实例将长期存在。

配置完，删除nacos 目录下 /data/protocol/raft 信息, 里面会保存应用实例的元数据信息.

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

时实例。

小问题：服务正常, Nacos健康检查失败，显示false

具体参考：如何解决Nacos持久化实例HTTP/TCP的健康检查不通过问题_微服务引擎(MSE)-阿里云帮助中心 (aliyun.com)

6.Nacos环境隔离

企业开发中, ⼀个服务会分为开发环境, 测试环境和生产环境.

开发环境：开发人员用于开发的服务器, 是最基础的环境. 一般目志级别设置较低, 可能会开启一些调试信息.
测试环境：测试人员⽤来进行测试的服务器, 是开发环境到生产环境的过渡环境.
生产环境：正式提供对外服务的环境, 通常关掉调试信息.
预发布环境（不对外开放）
发布环境（对外开放）

通常情况下, 这几个环境是不能互相通信的. Nacos提供了namespace(命名空间)来实现环境的隔离.

不同的namaspace的服务不可见.

6.1 创建Namespace

默认情况下，所有服务都在同⼀个namespace，名为public

点击左侧命名空间, 可以对namespace进行操作

6.2 配置namespace

namespace创建完成后, 对服务进行配置，设置分发的环境

常用场景之一是不同环境的注册的区分隔离，例如开发测试环境和生产环境的资源（如配置、服

务）隔离等。

sping:
 cloud:
   nacos:
     discovery:
	   namespace: 8a61ef37-2daa-402f-8b1d-5363629c5c87 #通过设置名命名空间来划分所属的环境

哪个模块的配置文件设置这个代码就是代表哪个代码会被分配到该ID的环境中。只有相同环境下才可以进行服务发现。

7. 总结

本文深入探讨了 Nacos（NAme COntrol Service）作为一个开源的动态服务发现、配置管理和服务管理平台的强大功能，以及为什么它成为了微服务架构中的关键组件。

Nacos负载均衡：
- Nacos支持多种负载均衡策略，包括权重、同机房、同地域、同环境等。
- 可以通过服务下线或配置节点的流量权重来实现负载均衡调控。
Nacos的健康检查：
- Nacos提供了两种健康检查机制：客户端主动上报和服务器端反向探测。
- 服务实例分为临时实例和非临时实例，对应不同的健康检查机制。
Nacos环境隔离：
- 使用namespace（命名空间）实现不同环境的服务隔离，确保各环境的服务不可见，从而实现环境间的隔离和管理。