负载均衡
负载均衡一般分为服务端负载均衡和客户端负载均衡
- 服务端负载均衡:
指在服务器端进行负载均衡的策略。在这种策略下,负载均衡器位于服务器端(如 Nginx),当客户端发起服务调用时,根据服务器的负载情况,将请求分发到不同的服务器上,以实现请求的均衡分配。
负载均衡器可以根据特定的算法(如轮询、权重等)来选择合适的服务器。这种方式可以有效地提高系统的可用性和扩展性,但也会增加服务器端的压力。
- 客户端负载均衡:
指在客户端进行负载均衡的策略。在这种策略下,负载均衡器位于客户端(如Loadbalancer、Ribbon),每个发起服务调用的客户端都有完整的目标服务地址列表,根据配置的负载均衡策略(如随机选择、加权轮询等),由客户端自己决定向哪台服务器发起调用。
客户端负载均衡可以减轻服务器端的压力,提高系统的性能和吞吐量。然而,客户端负载均衡依赖于客户端的实现,需要对客户端进行相应的配置和管理。
Ribbon
Spring Cloud Ribbon 是 NetFlix 开源的一个基于 HTTP 和 TCP 的客户端负载均衡器。
Ribbon 可以和 Eureka、Consul 等服务发现组件集成,通过向服务注册中心查询可用的服务列表,并通过一定的负载均衡算法(如轮训、随机等)选择目标服务实例。
Ribbon 已经进入维护模式,并且 Ribbon 2 并不与 Ribbon 1 相互兼容;
Ribbon 负载均衡策略有以下七种:
- 轮询(RoundRobinRule)
按照一定的顺序依次调用服务实例。例如有 ServerA、ServerB、ServerC 3个服务,按照 ABC 顺序依次调用服务。(按部就班)
默认超过 10 次获取到的 Server 都不可用,会返回一个空的 Server。
- 权重(WeightedResponseTimeRule)
根据每个服务提供者的响应时间分配一个权重,响应时间越长,权重越小,被选中的可能性也就越低。(能者多劳)
实现原理:刚开始使用轮询策略则开启一个计时器,每一段时间收集一次所有服务提供者的平均响应时间,然后再给每个服务提供者附上一个权重,权重越高的服务被选中的概率也就越大。
- 随机(RandomRule)
从服务提供者列表随机选择一个服务实例调用。(随性而为)
如果随机到的 Server 为 null 或者不可用的话,会 while 不停的循环选取。
- 最小连接数(BestAvailableRule)
也称为最小并发数策略,首先遍历服务提供者列表,然后选择连接数最小的一个服务实例 。如果有相同的最小连接数,那么会调用轮询策略进行选取。(让最闲的来)
此策略会过滤掉故障服务,基于过去30分钟的统计结果选取当前并发量最小的服务节点,即最“闲”的节点作为目标地址。
- 重试(RetryRule)
按照轮询策略来获取服务,如果获取的服务实例为 null 或已经失效,则在指定时间内不断地进行重试来获取服务,如果超过指定时间依然没有获取到服务实例,则返回 null。(卷土重来)
- 可用性敏感(AvailabilityFilteringRule)
扩展了轮询策略,会先通过默认的轮询选取一个 Server,再去判断该 Server 是否超时可用,当前连接数是否超限,都成功再返回。
- 区域敏感(ZoneAvoidanceRule)——默认策略
扩展了轮询策略,除了过滤超时和链接数过多的 Server,还会过滤掉不符合要求的 Zone 区域里面的所有节点, 在一个区域/机房内的服务实例中轮询。先过滤再轮询
修改 Ribbon 默认负载均衡策略方法如下:
在 application.yaml 配置文件中加入以下配置:
# 针对的被调用方微服务名称,不加就是全局生效
cloud-provider-8001:
ribbon:
# 设置为 最小连接数策略
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.BestAvailableRule
LoadBalancer
Spring Cloud LoadBalancer 是 Spring Cloud 团队在 Spring Cloud 2020 版本后引入的一个新的负载均衡组件。
LoadBalancer 提供了一个抽象的负载均衡接口,可以与多种负载均衡实现(如 Ribbon、Nacos、Consul等)进行匹配。
LoadBalancer 提供了两种负载均衡策略:
- 轮询(RoundRobinLoadBalancer)
- 随机(RandomLoadBalancer)
LoadBalancer 默认策略为轮询。
修改 LoadBalancer 默认负载均衡策略方法如下:
首先创建随机策略的配置类 LoadBalancerConfig,具体如下:
public class LoadBalancerConfig {
/**
* 将官方提供的 RandomLoadBalancer 注册为 Bean
*/
@Bean
public ReactorLoadBalancer<ServiceInstance> randomLoadBalancer(Environment environment, LoadBalancerClientFactory loadBalancerClientFactory) {
String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
return new RandomLoadBalancer(loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
}
}
然后使用 @LoadBalancerClient 注解配置对应服务的负载均衡策略,具体如下:
@Configuration
@LoadBalancerClient(value = "cloud-provider-8001", configuration = LoadBalancerConfig.class)
public class BeanConfig {
@Bean
// 负载均衡
@LoadBalanced
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
}
@LoadBalancerClient 注解也可以加在启动类上方,name 属性为调用的微服务的名称,configuration 属性为上面我们定义的随机负载均衡策略类。
我们可以通过以下方法进行验证负载均衡策略是否发生了改变,首先新建一个 provider-8002 模块,除了端口号不同之外,其他都一样。然后分别在 provider-8001 和 provider-8002 的控制类中加入如下接口:
@Value("${server.port}")
private String port;
@GetMapping("/get/port")
public String getPort() {
return port;
}
然后在 openfeign-consumer80 模块中的 IOpenFeignService 接口服务中加入对应接口,调用远端服务。分别启动 provider-8001 和 provider-8002,这时在 Eureka 界面可以看到 cloud-provider-8001 有两个实例。文章来源:https://www.toymoban.com/news/detail-798579.html
使用 Postman 调用接口,查看返回的端口号,可以发现,没有加上面配置之前,效果为 8001 和 8002 交替出现,加了之后,则为随机出现,如果觉得效果不太明显,可以多加两个 provider-8003、provider-8004。文章来源地址https://www.toymoban.com/news/detail-798579.html
到了这里,关于负载均衡 LoadBalancer的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!