近期博主在参与一个 Spring Cloud 搭建,版本为 Hoxton.SR12,服务注册发现组件为 Nacos 的老项目时,发现项目负载均衡组件 Ribbon 的负载均衡规则在某些场景下不够完美,比如新版本上线,需要重启服务。因此写了这边文章与大家分享。
在微服务架构中,负载均衡是实现高可用性、高性能和可伸缩性的关键组件,正确地选择和配置负载均衡规则对于整个系统的性能和稳定性都至关重要。Ribbon 是一个常见的负载均衡框架,在 Netflix 的微服务架构中发挥了重要作用。然而,在某些场景下,Ribbon 默认的负载均衡规则并不能满足我们的需求。
默认情况下 Ribbon 是通过定时任务每隔30秒去获取服务注册中心的服务列表,这样就会造成如果某个服务已经下线,但是 Ribbon 没有及时刷新服务列表,依然会去调用这个已经下线的服务,造成用户请求异常。因此,我们需要替换掉这些默认规则,使用更加灵活和强大的负载均衡规则,例如 NacosRule。本文将介绍在服务提供者为 Nacos的环境下,如何将 Ribbon 默认的负载均衡规则替换为 NacosRule 并进行相应的配置。
在微服务架构中,服务提供者通常会有多个实例,且这些实例的性能和运行状态可能会有所不同。为了让请求能够平均地分配给不同的实例,我们需要使用负载均衡算法。Ribbon 默认的负载均衡规则是轮询,即每个请求按顺序分配给不同的服务实例。这种方式对于服务提供者的实例性能和状态均匀分布的情况下适用,但是如果某个实例出现问题,例如响应时间过长或者宕机,仍然会受到一定比例的请求,这显然不是我们期望的结果。
NacosRule 是由 Nacos 的 spring-cloud-starter-alibaba-nacos-discovery
依赖中针对 Ribbon 提供的更为灵活和高效的负载均衡规则(在高版本已经移除 Ribbon 的相关配置)。官方对它的说明如下。
/**
* Supports preferentially calling the ribbon load balancing rules of the same cluster
* instance.
*
* @author itmuch.com
*/
public class NacosRule extends AbstractLoadBalancerRule {
}
用中文说就是支持优先调用同一集群实例的ribbon负载均衡规则。说人话就是它能够支持同一机房里的服务相互访问,避免跨机房调用。
跨机房访问会因为机房之间的物理距离太远,造成请求延时过高的问题。
NacosRule 的主要特点如下:
可以看到 NacosRule 在解决跨机房访问的延迟问题上,还解决了我们服务发布时,不能及时感知服务下线的问题。
我们可以通过在Ribbon客户端的配置中进行相应的设置,将默认的 Ribbon 负载均衡规则替换为 NacosRule。以下是示例代码:
@Configuration
public class RibbonConfiguration {
@Bean
public IRule ribbonRule() {
// 将Ribbon默认的轮询规则替换为NacosRule
return new NacosRule();
}
}
在这里,我们通过 @Configuration 注解定义了一个Java配置类,并在其中创建了一个名为 ribbonRule 的 Bean 对象,其类型为 IRule。我们通过返回 NacosRule 来替换 Ribbon 默认的负载均衡规则。这样,在调用服务时,Ribbon 就会使用 NacosRule 中的负载均衡算法来选择服务实例。
本文介绍了如何将 Ribbon 默认的负载均衡规则替换为 NacosRule,并进行相应的配置。大家也可以选择升级到 Spring Cloud 的高版本中,使用 spring-cloud-starter-loadbalancer
组件解决这个问题。
关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、高效开发工具等,您的关注将是我的更新动力!