springcloud 入门系列（四）ribbon-自定义负载均衡实现

​

上篇文章我们介绍了springcloud 的负载均衡组件ribbon,对其有了基本的认识。上篇我们留了个小任务，自定义负载均衡策略，话不多说，我们直接上代码：

 

配置自定义负载均衡bean。交由spring容器管理：

@Configuration
public class RibbonConfiguation {

    @Bean
    public IRule getRule(){
        return new MyRule();
    }
}

在springboot 引导类指定自定义负载均衡配置：

 

启动实例，进行请求，查看日志输出：

我们看到日志输出，一切正常，我们自定义的策略确实被启用了。

至此简易的ribbon负载均衡策略就实现了。

下面我们再来做个测试，我们把8081这台服务器停掉 ，我们看看会怎样：

我们看到一个有趣的现象，日志输出，显示8081 这台服务实例任然存活，但其实我们已经停掉了这台实例，这是为什么呢，原因其实在eureka上，我们之前的文章有提到过eureka 注册中心实现了我们分布式框架中CAP 的CP,而非AP. eureka客户端默认30s发送一次心跳给注册中心， Eureka服务器在接收到实例的最后一次发出的心跳后，默认需要等待90s后才能将服务剔除。当然这只是导致这个现象的一部分原因。最主要还是在我们负载均衡策略的实现，我们继续往下挖。

所以我们要确认获取到的server是否真的可用，需要有确认服务是否存活的机制。ribbon 提供了com.netflix.loadbalancer.IPing 接口,看下他都有哪些实现：

但其实真正实现的只要下面两个，其他的有的是抽象类，有的就是空实现，直接返回了ture：

下面我们来做测试：

再次启动实例进行访问：

发现niwsDiscoveryPing 任然返回ture，而pingUrl 则报错，连接失败。

查看niwsDiscoveryPing源码，有这么句注释：

niwsDiscoveryPing 并不会真的做“ping” 这个动作，而是依赖服务发现客户端组件，也就是eureka 客户端说该服务实例是活的就是活的（即服务是否存活由eureka 客户端说了算）。

查看Pingurl 源码实现：

 

PingUrl 会拼接url进行http访问来进行判别服务是否存活。但是我们看到该实现并没有捕获 ConnectionException,所以这边如果依赖Pingurl来实现的话还需要我们优化。

 本篇文章关于自定义负载均衡策略我们就讨论到这，相信大家对自定义负载均衡策略已经有了一定的了解，当实际当中如何实现负载均衡策略还是需要结合实际的应用场景来决定。