4

Ribbon负载均衡 (源码分析) - 不吃紫菜

 1 year ago
source link: https://www.cnblogs.com/buchizicai/p/17093490.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Ribbon负载均衡

SpringCloud已经删除了ribbon组件,所以需要手动导入依赖。(要学是因为很多项目业务已经使用了ribbon)

服务拉取的时候添加了@LoadBalanced注解,实现负载均衡

1.负载均衡原理

SpringCloud底层其实是利用了一个名为Ribbon的组件,来实现负载均衡功能的。

image

那么我们发出的请求明明是http://userservice/user/1,怎么变成了http://localhost:8081/user/1的呢?

2.源码跟踪

为什么我们只输入了service名称就可以访问了呢?之前还要获取ip和端口。

显然有人帮我们根据service名称,获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor,这个类会在对RestTemplate的请求进行拦截,然后从Eureka根据服务id获取服务列表,随后利用负载均衡算法得到真实的服务地址信息,替换服务id。

我们进行源码跟踪:

1)LoadBalancerIntercepor

image

可以看到这里的intercept方法,拦截了用户的HttpRequest请求,然后做了几件事:

  • request.getURI():获取请求uri,本例中就是 http://user-service/user/8
  • originalUri.getHost():获取uri路径的主机名,其实就是服务id,user-service
  • this.loadBalancer.execute():处理服务id,和用户请求。

这里的this.loadBalancerLoadBalancerClient类型,我们继续跟入。

2)LoadBalancerClient

继续跟入execute方法:

image

代码是这样的:

  • getLoadBalancer(serviceId):根据服务id获取ILoadBalancer,而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。
  • getServer(loadBalancer):利用内置的负载均衡算法,从服务列表中选择一个。本例中,可以看到获取了8082端口的服务放行后,再次访问并跟踪,发现获取的是8081:果然实现了负载均衡。
image

3)负载均衡策略IRule

在刚才的代码中,可以看到获取服务使通过一个getServer方法来做负载均衡:

image

我们继续跟入:

image

继续跟踪源码chooseServer方法,发现这么一段代码:

image

我们看看这个rule是谁:

image

这里的rule默认值是一个RoundRobinRule,看类的介绍:

image

这不就是轮询的意思嘛。

到这里,整个负载均衡的流程我们就清楚了。

SpringCloudRibbon的底层采用了一个拦截器,拦截了RestTemplate发出的请求,对地址做了修改。用一幅图来总结一下:

image

基本流程如下:【重点】

  • 拦截我们的RestTemplate请求http://userservice/user/1
  • RibbonLoadBalancerClient会从请求url中获取服务名称,也就是user-service
  • DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表
  • eureka返回列表,localhost:8081、localhost:8082
  • IRule利用内置负载均衡规则,从列表中选择一个,例如localhost:8081
  • RibbonLoadBalancerClient修改请求地址,用localhost:8081替代userservice,得到http://localhost:8081/user/1,发起真实请求

3.负载均衡策略

默认设置是IRule接口下的ZoneAvoidanceRule 类(根据就近区域Zone来轮询)

1)负载均衡策略

负载均衡的规则都定义在IRule接口中,而IRule有很多不同的实现类:

image

不同规则的含义如下:默认的实现就是ZoneAvoidanceRule,是一种轮询方案

内置负载均衡规则类 规则描述
RoundRobinRule 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule 对以下两种服务器进行忽略: (1)在默认情况下,这台服务器如果3次连接失败,这台服务器就会被设置为“短路”状态。短路状态将持续30秒,如果再次连接失败,短路的持续时间就会几何级地增加。 (2)并发数过高的服务器。如果一个服务器的并发连接数过高,配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限,可以由客户端的..ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule 为每一个服务器赋予一个权重值。服务器响应时间越长,这个服务器的权重就越小。这个规则会随机选择服务器,这个权重值会影响服务器的选择。
ZoneAvoidanceRule 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类,这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule 忽略那些短路的服务器,并选择并发数较低的服务器。
RandomRule 随机选择一个可用的服务器。
RetryRule 重试机制的选择逻辑

2)自定义负载均衡策略

注意,一般用默认的负载均衡规则,不做修改。

通过定义IRule实现可以修改负载均衡规则,有两种方式:(二选一即可)

  1. 代码方式:在order-service中的OrderApplication类中,定义一个新的IRule:

    优:配置灵活 劣:修改时需要重新打包

@Bean
public IRule randomRule(){
    return new RandomRule();
}
  1. 配置文件方式:在order-service的application.yml文件中,添加新的配置也可以修改规则:【推荐】

    优:直观,方便,修改后无需重新打包 劣:无法全局配置,需要对每个服务设置负责均衡规则

userservice: # 给某个微服务配置负载均衡规则,这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 

4.饥饿加载

推荐修改为饥饿加载,在消费者的yaml中设置

Ribbon默认是采用懒加载,即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。

而饥饿加载则会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:

ribbon:
  eager-load:
    enabled: true #开启饥饿加载
    clients:  #指定饥饿加载的服务名称
      - userservice
      - xxx

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK