Spring Cloud之注册中心之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集群，与预期符合。
