Spring Cloud之注册中心之Nacos负载均衡

发布于:2025-03-07 ⋅ 阅读:(21) ⋅ 点赞:(0)

目录

负载均衡

服务下线

权重配置

配置权重

解决办法

常见问题

同集群优先访问

给实例配置集群名称

开启Nacos负载均衡策略


负载均衡

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

服务下线
当某⼀个节点上接⼝的性能较差时, 我们可以第⼀时间对该节点进⾏下线.
操作步骤: 服务详情 -> 下线
点击下线后, 再次请求接⼝, 会发现该服务没有请求进来了。
再次单击上线, 该节点会继续收到请求。
下线之前

下线端口号为9091的服务进程之后:

权重配置

除了下线之外, 我们也可以配置这个节点的流量权重。

配置权重

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

下面修改端口号为9091的服务进程的权重为0.1

观察结果:
我们可以看到,三个服务实例接收到的请求次数几乎一样多,这是为什么呢?明明我们已经配置了权重且比例稍微比较大,按理说应该能看到现象。
是因为我们使用了LoadBalance,它本来就是负责负载均衡的,此时就不会使用Nacos的权重属性进行负载均衡。
我们可以参考一下文章:
解决办法
开启Nacos负载均衡策略
application.properties
spring.cloud.loadbalancer.nacos.enabled=true

application.yml 

spring:
  cloud:
    loadbalancer:
      nacos:
        enabled: true
观察结果:
由此我们可以看到,我们设置的权重生效了。
常见问题
修改权重时, 可能会报错:

报错信息为:

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把同⼀个机房内的实例, 划分为⼀个集群. 所以同集群优先访问, 在⼀定程度上也可以理解为同房优先访问.
微服务架构中, ⼀个服务通常有多个实例共同提供服务, 这些实例可以部署在不同的机器上, 这些机器可以分布在不同的机房, ⽐如product-service:
实例1: 分布在上海机房
实例2: 分布在上海机房
实例3: 分布在北京机房
实例4: 分布在北京机房
微服务访问时, 应尽量访问同机房的实例. 当本机房内实例不可⽤时, 才访问其他机房的实例。
⽐如order-service 在上海机房, product-service 在北京和上海机房都有实例, 那我们希望可以优先访问上海机房, 如果上海机房没有实例, 或者实例不可⽤, 再访问北京机房的实例. 通常情况下, 因为同⼀个机房的机器属于⼀个局域⽹, 局域⽹访问速度更快⼀点.
给实例配置集群名称
1. 配置集群名称
给order-service和端口号为9090的product-service配置 SH 集群名称。
spring:
  cloud:
    nacos:
      discovery:
        server-addr: 110.41.51.65:10020
        cluster-name: SH #集群名称: 上海集群

端口号为9091的product-service 和 端口号为9092的product-service配置 BJ 集群名称。

开启Nacos负载均衡策略
同权重配置
spring:
  cloud:
    nacos:
      loadbalancer:
        nacos:
          enabled: true
多次访问“http://127.0.0.1:8080/order/1”
观察结果:
我们前面配置order-service集群为 SH,配置端口号为9090的product-service集群为 SH,配置端口号为9091的product-service集群为 BJ,配置端口号为9092的product-service集群为 BJ。
上面的结果可以看到,请求都发送到了端口号为9090的product-service集群,与预期符合。