Ribbon负载均衡原理、负载均衡策略以及懒加载

目录

负载均衡流程

问题分析

执行流程

底层源码分析

进入LoadBalancerInterceptor

进入ClientHttpRequestInterceptor

重新回到LoadBalancerInterceptor

负载均衡策略

通过定义IRule实现可以修改负载均衡规则

代码方式

配置文件方式

饥饿加载

总结

---

负载均衡流程

问题分析

order-service向user-service发送的请求是 http://userservice/user/1，但我们发现浏览器运行根本跑不起来

就会引发一个思考，说明此地址在到达userservice之前会有一个中间件进行处理，它就是Ribbon负载均衡

执行流程

1. order-service向Ribbon负载均衡发起请求 http://userservice/user/1
2. Ribbon负载均衡向eureka-server拉取userservice
3. eureka-server返回服务给Ribbon负载均衡
4. Ribbon负载均衡发送真实请求进行轮询

底层源码分析

进入LoadBalancerInterceptor

public class LoadBalancerInterceptor implements ClientHttpRequestInterceptor {
    private LoadBalancerClient loadBalancer;
    private LoadBalancerRequestFactory requestFactory;
    ·······
}

发现LoadBalancerInterceptor实现了ClientHttpRequestInterceptor接口

进入ClientHttpRequestInterceptor

@FunctionalInterface
public interface ClientHttpRequestInterceptor {
    ClientHttpResponse intercept(HttpRequest var1, byte[] var2, ClientHttpRequestExecution var3) throws IOException;
}

发现这是一个客户端请求拦截器

重新回到LoadBalancerInterceptor

发现LoadBalancerInterceptor实现了ClientHttpRequestInterceptor接口，说明在LoadBalancerInterceptor一定实现了ClientHttpRequestInterceptor类中的intercept方法

    public ClientHttpResponse intercept(final HttpRequest request, final byte[] body, final ClientHttpRequestExecution execution) throws IOException {
        URI originalUri = request.getURI();
        String serviceName = originalUri.getHost();
        Assert.state(serviceName != null, "Request URI does not contain a valid hostname: " + originalUri);
        return (ClientHttpResponse)this.loadBalancer.execute(serviceName, this.requestFactory.createRequest(request, body, execution));
    }

在这个方法中可以发现实现流程

• request.getURI()获取了我们输入的路径
• originalUri.getHost()获取了服务器的名称以及端口号
• 将以上信息交给了loadBalancer

loadBalancer是Ribbon负载均衡客户端

• 会把serviceId交给getLoadBalancer()方法
• 在instance里面会有两个serverlist，就是我们的两个服务器地址

• 规则会根据IRule接口拿到其中一个serverlist并调用

负载均衡策略

Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则

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

通过定义IRule实现可以修改负载均衡规则

代码方式

在order-service中的OrderApplication类中，定义一个新的IRule

    @Bean
    public IRule randomRule(){
        return new RandomRule();
    }

配置文件方式

在order-service的application.yml文件中，添加新的配置

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时

ribbon:
  eager-load:
    enabled: true #开启饥饿加载

总结

• Ribbon负载均衡规则
  • 规则接口是IRule
  • 默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询
• 负载均衡自定义方式
  • 代码方式：配置灵活，但修改时需要重新打包发布
  • 配置方式：直观，方便，无需重新打包发布，但是无法做全局配置
• 饥饿加载
  • 开启饥饿加载
  • 指定饥饿加载的微服务名称