【一起学源码-微服务】Ribbon 源码四:进一步探究Ribbon的IRule和IPing

前言

前情回顾

上一讲深入的讲解了Ribbon的初始化过程及Ribbon与Eureka的整合代码,与Eureka整合的类就是DiscoveryEnableNIWSServerList,同时在DynamicServerListLoadBalancer中会调用PollingServerListUpdater 进行定时更新Eureka注册表信息到BaseLoadBalancer中,默认30s调度一次。

本讲目录

我们知道Ribbon主要是由3个组件组成的:

  1. ILoadBalancer
  2. IRule
  3. IPing

其中ILoadBalancer前面我们已经分析过了,接下来我们一起看看IRuleIPing中的具体实现。

目录如下:

  1. 负载均衡默认Server选择逻辑
  2. Ribbon实际执行http请求逻辑
  3. Ribbon中ping机制原理
  4. Ribbon中其他IRule负载算法初探

说明

原创不易,如若转载 请标明来源!

博客地址:一枝花算不算浪漫
微信公众号:壹枝花算不算浪漫

源码分析

负载均衡默认Server选择逻辑

还记得我们上一讲说过,在Ribbon初始化过程中,默认的IRuleZoneAvoidanceRule,这里我们可以通过debug看看,从RibbonLoadBalancerClient.getServer() 一路往下跟,这里直接看debug结果:

然后我们继续跟ZoneAvoidanceRule.choose() 方法:

public abstract class PredicateBasedRule extends ClientConfigEnabledRoundRobinRule {

    /**
     * Method that provides an instance of {@link AbstractServerPredicate} to be used by this class.
     *
     */
    public abstract AbstractServerPredicate getPredicate();

    /**
     * Get a server by calling {@link AbstractServerPredicate#chooseRandomlyAfterFiltering(java.util.List, Object)}.
     * The performance for this method is O(n) where n is number of servers to be filtered.
     */
    @Override
    public Server choose(Object key) {
        ILoadBalancer lb = getLoadBalancer();
        Optional<Server> server = getPredicate().chooseRoundRobinAfterFiltering(lb.getAllServers(), key);
        if (server.isPresent()) {
            return server.get();
        } else {
            return null;
        }
    }
}

这里是调用的ZoneAvoidanceRule的父类中的choose()方法,首先是拿到对应的ILoadBalancer,然后拿到对应的serverList数据,接着调用chooseRoundRobinAfterFiltering()方法,继续往后跟:

public abstract class AbstractServerPredicate implements Predicate<PredicateKey> {

    public Optional<Server> chooseRoundRobinAfterFiltering(List<Server> servers, Object loadBalancerKey) {
        List<Server> eligible = getEligibleServers(servers, loadBalancerKey);
        if (eligible.size() == 0) {
            return Optional.absent();
        }
        return Optional.of(eligible.get(incrementAndGetModulo(eligible.size())));
    }

    private int incrementAndGetModulo(int modulo) {
        for (;;) {
            int current = nextIndex.get();
            int next = (current + 1) % modulo;
            if (nextIndex.compareAndSet(current, next) && current < modulo)
                return current;
        }
    }
}

到了这里可以看到incrementAndGetModulo()方法就是处理serverList轮询的算法,这个和RoudRobinRule中采用的是一样的算法,这个算法大家可以品一品,我这里也会画个图来说明下:

看了图=中的例子估计大家都会明白了,这个算法就是依次轮询。这个算法写的很精简。

Ribbon实际执行http请求逻辑

我们上面知道,我们按照轮询的方式从serverList取到一个server后,那么怎么把之前原有的类似于:http://ServerA/sayHello/wangmeng中的ServerA给替换成请求的ip数据呢?

接着我们继续看RibbonLoadBalancerClient.execute()方法,这个里面request.apply()会做一个serverName的替换逻辑。

最后可以一步步跟到RibbonLoadBalancerClient.reconstructURI(),这个方法是把请求自带的getURI方法给替换了,我们最后查看context.reconstructURIWithServer() 方法,debug结果如图,这个里面会一步步把对应的请求url给拼接起来:

Ribbon中ping机制原理

我们知道 Ribbon还有一个重要的组件就是ping机制,通过上一讲Ribbon的初始化我们知道,默认的IPing实现类为:NIWSDiscoveryPing,我们可以查看其中的isAlive()方法:

public class NIWSDiscoveryPing extends AbstractLoadBalancerPing {

        BaseLoadBalancer lb = null; 

        public NIWSDiscoveryPing() {
        }

        public BaseLoadBalancer getLb() {
            return lb;
        }

        /**
         * Non IPing interface method - only set this if you care about the "newServers Feature"
         * @param lb
         */
        public void setLb(BaseLoadBalancer lb) {
            this.lb = lb;
        }

        public boolean isAlive(Server server) {
            boolean isAlive = true;
            if (server!=null && server instanceof DiscoveryEnabledServer){
                DiscoveryEnabledServer dServer = (DiscoveryEnabledServer)server;
                InstanceInfo instanceInfo = dServer.getInstanceInfo();
                if (instanceInfo!=null){
                    InstanceStatus status = instanceInfo.getStatus();
                    if (status!=null){
                        isAlive = status.equals(InstanceStatus.UP);
                    }
                }
            }
            return isAlive;
        }

        @Override
        public void initWithNiwsConfig(
                IClientConfig clientConfig) {
        }

}

这里就是获取到DiscoveryEnabledServer对应的注册信息是否为UP状态。那么 既然有个ping的方法,肯定会有方法进行调度的。

我们可以查看isAlive()调用即可以找到调度的地方。
BaseLoadBalancer构造函数中会调用setupPingTask()方法,进行调度:

protected int pingIntervalSeconds = 10;

void setupPingTask() {
    if (canSkipPing()) {
        return;
    }
    if (lbTimer != null) {
        lbTimer.cancel();
    }
    lbTimer = new ShutdownEnabledTimer("NFLoadBalancer-PingTimer-" + name,
            true);
    lbTimer.schedule(new PingTask(), 0, pingIntervalSeconds * 1000);
    forceQuickPing();
}

这里pingIntervalSecondsBaseLoadBalancer中定义的是10s,但是在initWithConfig()方法中,通过传入的时间覆盖了原本的10s,这里实际的默认时间是30s。如下代码:

我们也可以通过debug来看看:

可能大家好奇为什么要单独截图来说这个事,其实是因为网上好多博客讲解都是错的,都写的是ping默认调度时间为10s,想必他们都是没有真正debug过吧。

还是那句话,源码出真知。

Ribbon中其他IRule负载算法初探

  1. RoundRobinRule:系统内置的默认负载均衡规范,直接round robin轮询,从一堆server list中,不断的轮询选择出来一个server,每个server平摊到的这个请求,基本上是平均的

    这个算法,说白了是轮询,就是一台接着一台去请求,是按照顺序来的

  2. AvailabilityFilteringRule:这个rule就是会考察服务器的可用性

    如果3次连接失败,就会等待30秒后再次访问;如果不断失败,那么等待时间会不断变长
    如果某个服务器的并发请求太高了,那么会绕过去,不再访问

    这里先用round robin算法,轮询依次选择一台server,如果判断这个server是存活的可用的,如果这台server是不可以访问的,那么就用round robin算法再次选择下一台server,依次循环往复,10次。

  3. WeightedResponseTimeRule:带着权重的,每个服务器可以有权重,权重越高优先访问,如果某个服务器响应时间比较长,那么权重就会降低,减少访问
  4. ZoneAvoidanceRule:根据机房和服务器来进行负载均衡,说白了,就是机房的意思,看了源码就是知道了,这个就是所谓的spring cloud ribbon环境中的默认的Rule
  5. BestAvailableRule:忽略那些请求失败的服务器,然后尽量找并发比较低的服务器来请求

总结

到了这里 Ribbon相关的就结束了,对于Ribbon注册表拉取及更新逻辑这里也梳理下,这里如果Ribbon保存的注册表信息有宕机的情况,这里最多4分钟才能感知到,所以spring cloud还有一个服务熔断的机制,这个后面也会讲到。

申明

本文章首发自本人博客:https://www.cnblogs.com/wang-meng 和公众号:壹枝花算不算浪漫,如若转载请标明来源!

感兴趣的小伙伴可关注个人公众号:壹枝花算不算浪漫

原文地址:https://www.cnblogs.com/wang-meng/p/12166148.html

时间: 2024-10-04 02:29:21

【一起学源码-微服务】Ribbon 源码四:进一步探究Ribbon的IRule和IPing的相关文章

【一起学源码-微服务】Nexflix Eureka 源码十:服务下线及实例摘除,一个client下线到底多久才会被其他实例感知?

前言 前情回顾 上一讲我们讲了 client端向server端发送心跳检查,也是默认每30钟发送一次,server端接收后会更新注册表的一个时间戳属性,然后一次心跳(续约)也就完成了. 本讲目录 这一篇有两个知识点及一个疑问,这个疑问是在工作中真真实实遇到过的. 例如我有服务A.服务B,A.B都注册在同一个注册中心,当B下线后,A多久能感知到B已经下线了呢? 不知道大家有没有这个困惑,这篇文章最后会对此问题答疑,如果能够看到文章的结尾,或许你就知道答案了,当然答案也会在结尾揭晓. 目录如下: C

【一起学源码-微服务】Nexflix Eureka 源码十三:Eureka源码解读完结撒花篇~!

前言 想说的话 [一起学源码-微服务-Netflix Eureka]专栏到这里就已经全部结束了. 实话实说,从最开始Eureka Server和Eureka Client初始化的流程还是一脸闷逼,到现在Eureka各种操作都了然于心了. 本专栏从12.17开始写,一直到今天12.30(文章在平台是延后发布的),这将近半个月的时间确实收获很多.每天都会保持一定的时间学习,只要肯下功夫,没有学不会的东西. 2020年将继续保持学习的节奏,自己定的目标是把spring cloud几个重要的组件都学一遍

kbengine mmo源码(完整服务端源码+资源+完整客户端源码)

kbengine mmo源码(完整服务端源码+资源+完整客户端源码) PyConsole: display server information. PyConsole: Stop the server. Guiconsole: debug. Guiconsole: log. Demo: Ogre. Demo: Unity3d. demo视频:http://v.youku.com/v_show/id_XNjU5Nzc0MDQ4.html 下载地址: demo下载地址:http://sourcefo

springcloud 项目源码 微服务 分布式 Activiti6 工作流 vue.js html 跨域 前后分离

1.代码生成器: [正反双向](单表.主表.明细表.树形表,快速开发利器)freemaker模版技术 ,0个代码不用写,生成完整的一个模块,带页面.建表sql脚本.处理类.service等完整模块2.多数据源:(支持同时连接无数个数据库,可以不同的模块连接不同数的据库)支持N个数据源3.阿里数据库连接池druid,安全权限框架 shiro(菜单权限和按钮权限), 缓存框架 ehcache4.代码编辑器,在线模版编辑,仿开发工具编辑器5.调用摄像头拍照 自定义裁剪编辑头像,头像图片色度调节6.we

手游 mmo游戏源码(完整服务端源码+资源+完整客户端)

Demo: Ogre. Demo: Unity3d. PyConsole: display server information. PyConsole: Stop the server. Guiconsole: debug. Guiconsole: log. demo视频:http://v.youku.com/v_show/id_XNjU5Nzc0MDQ4.htmldemo下载地址:http://sourceforge.net/projects/kbengine/files/服务端源码:http

从 0 开始的微服务架构:(四)如何保障微服务架构下的数据一致性

虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去.各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构.就是没有一个做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从 0 开始,采用通俗易懂的语言去讲解微服务架构的系列.所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题"Re:从 0 开始

.Net Core 商城微服务项目系列(四):ELK

毫无疑问,项目里日志是必不可少的,在众多日志框架里ELK可以说是最好的选择之一,对于微服务项目来说也是一样. 之前写过关于ELK搭建的文章,所以这篇也就不再介绍了,本篇将会使用NLog搭配ElasticSearch和Kibana构建日志框架,本来是有Logstash的,但是接入Logstash后日志总是发送不成功,所以本篇将暂时不使用Logstash,等后面找到具体什么问题后再进行修改,最终整体的日志架构会是NLog+ELK+Kafka. 运行ELK有两种方式,一种是分别单独运行ElasticS

【一起学源码-微服务】Nexflix Eureka 源码九:服务续约源码分析

前言 前情回顾 上一讲 我们讲解了服务发现的相关逻辑,所谓服务发现 其实就是注册表抓取,服务实例默认每隔30s去注册中心抓取一下注册表增量数据,然后合并本地注册表数据,最后有个hash对比的操作. 本讲目录 今天主要是看下服务续约的逻辑,服务续约就是client端给server端发送心跳检测,告诉对方我还活着.现在很多分布式系统都会有心跳检查的机制,这里一起来学习下Eureka是怎么做心跳检查的. 目录如下: client端心跳检查调度任务 server端接收心跳检查,设置最后renew时间 这

【一起学源码-微服务】Nexflix Eureka 源码十一:EurekaServer自我保护机制竟然有这么多Bug?

前言 前情回顾 上一讲主要讲了服务下线,已经注册中心自动感知宕机的服务. 其实上一讲已经包含了很多EurekaServer自我保护的代码,其中还发现了1.7.x(1.9.x)包含的一些bug,但这些问题在master分支都已修复了. 服务下线会将服务实例从注册表中删除,然后放入到recentQueue中,下次其他EurekaClient来进行注册表抓取的时候就能感知到对应的哪些服务下线了. 自动感知服务实例宕机不会调用下线的逻辑,所以我们还抛出了一个问题,一个client宕机,其他的client