Ribbon IPing机制源码探秘

这篇具有很好参考价值的文章主要介绍了Ribbon IPing机制源码探秘。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

🍊 Java学习:社区快速通道

🍊 深入浅出RocketMQ设计思想:深入浅出RocketMQ设计思想

🍊 绝对不一样的职场干货:大厂最佳实践经验指南


📆 最近更新:2023年7月2日


🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力!


IPing机制

Ribbon会主动判断服务节点的当前状态,决定是否可作为目标节点,只有当前可用的节点才会作为负载均衡器的目标节点。IPing有以下几个手段:

  • DummyPing:默认返回true,即认为所有节点都可用,这也是单独使用Ribbon时的默认模式
  • NIWSDiscoveryPing:借助Eureka服务发现机制获取节点状态,假如节点状态是UP则认为是可用状态
  • PingUrl:主动向服务节点发起一次http调用,如果对方有响应则认为节点可用
  • PingConstant:返回设置的常量值
  • NoOpPing:返回true

假如服务节点搭载的服务本身就承载超高并发的情况下,那这种主动出击的IPing策略必然会大大增加服务节点的访问压力。


Ribbon IPing是一个接口,可以通过实现该接口来自定义Ping机制。Ribbon IPing的实现类需要在配置文件或者代码中指定,例如:

#单个服务设置
[service-name]:
  ribbon:
    NFLoadBalancerPingClassName: com.netflix.loadbalancer.DummyPing

public class MicroRibbonConfig {
  @Bean
  public IPing microIPing() {
    return new DummyPing();
  }
}

@RibbonClient(name = "micro-service", configuration = MicroRibbonConfig.class)
public class RibbonClientConfig {
}

Ribbon IPing的作用是保证负载均衡器只选择可用的服务节点,提高系统的可靠性和性能。Ribbon IPing与Eureka结合使用时,可以实现自动化的服务发现和健康检查。


用时间换空间

在Ribbon这里,时间和空间经常要被换来换去,时间代表着接口响应时间(RT,Response Time),空间表示服务器的可用连接数。

在Ribbon里有两个和时间与空间密切相关的负载均衡策略,BestAvailableRule(简称BA)和WeightedResponseTimeRule。他们都会选择压力较小的服务节点,但这两个策略的方向不同。BA会根据服务节点过去一段时间的请求数,选择并发量最小的机器(选择空间);WRT则是根据响应时间的统计结果,选择响应时间最快的服务(选择时间)。

  • 连接数敏感模型: 对响应时间较短,或RT和业务复杂度是非线性相关关系的接口,采用基于可用连接数的负载均衡策略更加合适。
  • RT敏感模型: 对重量级接口,尤其是根据参数不同会导致系统资源使用率浮动较大的接口(RT与业务复杂度线性相关),建议采用基于响应时间的负载均衡策略。

总结一下就是轻量级接口选空间(BestAvailableRule)、重量级接口选时间(WeightedResponseTimeRule


Ribbon IPing机制源码探秘

IPing接口的定义如下:

public interface IPing {
    public boolean isAlive(Server server);
}

看一下它的几个实现类:

public class DummyPing extends AbstractLoadBalancerPing {

    public DummyPing() {
    }

    public boolean isAlive(Server server) {
        return true;
    }

    @Override
    public void initWithNiwsConfig(IClientConfig clientConfig) {
    }
}

什么都没发生,直接返回true


public class NoOpPing implements IPing {
    @Override
    public boolean isAlive(Server server) {
        return true;
    }
}

也是直接返回true


PingUrl的内容比较丰富,关注一下isAlive方法:

public boolean isAlive(Server server) {
    String urlStr = "";
    if (this.isSecure) {
        urlStr = "https://";
    } else {
        urlStr = "http://";
    }

    urlStr = urlStr + server.getId();
    urlStr = urlStr + this.getPingAppendString();
    boolean isAlive = false;
    HttpClient httpClient = new DefaultHttpClient();
    HttpUriRequest getRequest = new HttpGet(urlStr);
    String content = null;

    try {
        HttpResponse response = httpClient.execute(getRequest);
        content = EntityUtils.toString(response.getEntity());
        isAlive = response.getStatusLine().getStatusCode() == 200;
        if (this.getExpectedContent() != null) {
            LOGGER.debug("content:" + content);
            if (content == null) {
                isAlive = false;
            } else if (content.equals(this.getExpectedContent())) {
                isAlive = true;
            } else {
                isAlive = false;
            }
        }
    } catch (IOException var11) {
        var11.printStackTrace();
    } finally {
        getRequest.abort();
    }

    return isAlive;
}

如果是安全协议则使用https,不是安全的则使用http,拼接的时候先加上一个server.getId(),再加上一个this.getPingAppendString()


HttpClient httpClient = new DefaultHttpClient();
HttpUriRequest getRequest = new HttpGet(urlStr);

构造一个http请求来判断是否是up状态


if (this.getExpectedContent() != null)

如果有返回的期望值,则需要实际返回的数据等于期望值才证明是服务节点是up的


NIWSDiscoveryPing实现类:

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;
}

只有server的类型是DiscoveryEnabledServer才将其转换成自己需要的类型,然后获得instanceInfo

这里InstanceStatus依靠eureka的服务发现从服务注册中心拉取到的,服务发现并不能即使反映所有服务器的状态变化,因为是客户端发起的,所以有延迟。文章来源地址https://www.toymoban.com/news/detail-514563.html

到了这里,关于Ribbon IPing机制源码探秘的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 通过一次线上问题,讲下Ribbon重试机制

    前段时间,产品经理在线上验证产品功能的时候,发现某个功能不符合需求预期,后来测试验证发现是服务端的一个接口大概率偶现超时,前端做了兜底处理,所以对线上用户么有太大影响。 由于服务端的接口偶现超时,并且网关设置了30s超时熔断,所以前端请求就直接报错

    2024年02月15日
    浏览(60)
  • “深入解析JVM内部机制:探秘Java虚拟机的奥秘“

    标题:深入解析JVM内部机制:探秘Java虚拟机的奥秘 摘要:本文将深入解析JVM(Java虚拟机)的内部机制,从字节码执行到垃圾回收,逐步揭示Java程序运行的奥秘。通过理论分析和示例代码,读者将对JVM的工作原理有更深入的了解。 正文: 一、Java虚拟机简介 Java虚拟机(JVM)

    2024年02月12日
    浏览(42)
  • 【网络安全】网络防护之旅 - Java安全机制探秘与数字证书引爆网络防线

    🌈个人主页: Sarapines Programmer 🔥 系列专栏: 《网络安全之道 | 数字征程》 ⏰墨香寄清辞:千里传信如电光,密码奥妙似仙方。 挑战黑暗剑拔弩张,网络战场誓守长。 目录 😈1. 初识网络安全 😈2. Java安全机制和数字证书的管理 🕵️‍♂️2.1 研究目的 🕵️‍♂️2.2 研

    2024年02月04日
    浏览(52)
  • Ribbon源码深度解析

    ① 目前,我看的Ribbon的源码版本是spring-cloud-netflix-ribbon-2.2.6.RELEASE,但是网上没有找到该版本源代码,只能查看jar下编译后的代码,方法的跳转和搜索不太方便…,以上是题外话,继续:首先可以找到META-INF/spring.factories文件,查看该文件中配置了哪些自动装配类,刚好只有一

    2024年02月19日
    浏览(25)
  • Ribbon 源码分析

    断点 LoadBalancerInterceptor LoadBalancerInterceptor 实现了 ClientHttpRequestInterceptor 接口,重写了其中的 intercept 方法,用来拦截请求; 获取原始的 uri 和 服务名,调用 LoadBalancerClient 中的 execute 方法; 追踪 LoadBalancer 的实现 RibbonLoadBalancerClient 这里根据上面传入的服务名字作为服务的

    2024年02月12日
    浏览(30)
  • Ribbon源码

    但只用认识一点点 之前我们学习Ribbon的简单使用时,都是集成了Eureka-client或者Feign等组件,甚至在使用时感受不到ribbon的存在,顶多提一嘴他的负载均衡接口。而本文要专注于讲解微服务体系下,Ribbon部分的基本原理。 ribbon项目目前已经进入On Maintenance维护状态,大家可以学

    2024年02月14日
    浏览(31)
  • Eureka 服务注册源码探秘——图解、源码级解析

    🍊 Java学习:社区快速通道 🍊 深入浅出RocketMQ设计思想:深入浅出RocketMQ设计思想 🍊 绝对不一样的职场干货:大厂最佳实践经验指南 📆 最近更新:2023年5月2日 🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力! 服务注册是为了解决各个微服务的 “你是谁” 这个问题,即

    2024年02月03日
    浏览(33)
  • Eureka 心跳和服务续约源码探秘——图解、源码级解析

    🍊 Java学习:社区快速通道 🍊 深入浅出RocketMQ设计思想:深入浅出RocketMQ设计思想 🍊 绝对不一样的职场干货:大厂最佳实践经验指南 📆 最近更新:2023年5月25日 🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力! 分布式系统是由多个计算机节点构成的系统,这些节点之间通

    2024年02月06日
    浏览(37)
  • Ribbon 负载均衡策略 —— 图解、源码级解析

    🍊 Java学习:社区快速通道 🍊 深入浅出RocketMQ设计思想:深入浅出RocketMQ设计思想 🍊 绝对不一样的职场干货:大厂最佳实践经验指南 📆 最近更新:2023年6月4日 🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力! 通过本文你可以学习到: 常见的7种负载均衡策略思想 自旋锁

    2024年02月07日
    浏览(37)
  • [源码分析]-Ribbon(1): 7种负载均衡算法

    Ribbon是客户端负载均衡算法。 IRule是负载均衡算法的顶层接口,定义了三个方法。 其所有的实现类都是抽象类AbstractLoadBalancerRule的子类。AbstractLoadBalancerRule定义了lb字段。 策略实现类RoundRobinRule。 就是用个自增计数器,然后对所有server进行取模。但是这里对计数器有个较好的

    2024年02月13日
    浏览(35)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包