【云原生&微服务二】SpringCloud之Ribbon自定义负载均衡策略(含Ribbon核心API)「建议收藏」

【云原生&微服务二】SpringCloud之Ribbon自定义负载均衡策略(含Ribbon核心API)「建议收藏」1、SpringCloud之Ribbon自定义负载均衡策略,2、SpringCloud之Ribbon自定义服务实例心跳检查策略,3、ILoadBalancer、IRule、IPing介绍

大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

一、前置知识

在前一篇文章【云原生&微服务一】SpringCloud之Ribbon实现负载均衡详细案例(集成Eureka、Ribbon)我们讨论了SpringCloud如何集成Eureka和Ribbon,本文就在其基础上讨论一下如何自定义Ribbon的负载均衡策略、以及Ribbon的核心API。

二、Ribbon核心API

博主习惯性的在深入研究一门技术的时候去GitHub上看文档,然而Ribbon在GitHub上的文档(https://github.com/Netflix/ribbon)真的是没啥可看的;就给了一个demo和Release notes。

Ribbon有三个核心接口:ILoadBalancer、IRule、IPing,其中:

  1. ILoadBalancer是负载均衡器;
    在这里插入图片描述
  2. IRule 复杂负载均衡的规则,ILoadBalancer根据其选择一个可用的Server服务器;
    在这里插入图片描述
  3. IPing负责定时ping每个服务器,判断其是否存活。
    在这里插入图片描述

三、自定义负载均衡策略IRule

1、编写IRule实现类

MyRule重写IRule的choose(Object o)方法,每次都访问List<Server>中第一个服务实例;

import com.netflix.loadbalancer.ILoadBalancer;
import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.Server;

import java.util.List;

/** * 自定义负载均衡规则,只用第一个实例; * * @author Saint */
public class MyRule implements IRule { 
   

    private ILoadBalancer loadBalancer;

    @Override
    public Server choose(Object o) { 
   
        final List<Server> allServers = this.loadBalancer.getAllServers();
        return allServers.get(0);
    }

    @Override
    public void setLoadBalancer(ILoadBalancer iLoadBalancer) { 
   
        this.loadBalancer = iLoadBalancer;
    }

    @Override
    public ILoadBalancer getLoadBalancer() { 
   
        return loadBalancer;
    }
}

注意:一般很少需要自己定制负载均衡算法的,除非是类似hash分发的那种场景,可以自己写个自定义的Rule,比如说,每次都根据某个请求参数,分发到某台机器上去。不过在分布式系统中,尽量减少这种需要hash分发的情况。

下面我接着看如何把自定义的MyRule应用到指定的服务上 或 全部服务上。

2、编写Ribbon配置类

在Ribbon配置类中通过@Bean注解将自定义的IRule实现类MyRule注入到Spring容器中。

import com.netflix.loadbalancer.IRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/** * 自定义Ribbon配置 * * @author Saint */
@Configuration
public class MyRibbonConfiguration { 
   

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

3、应用到全部服务上(Ribbon全局配置)

Ribbon全局配置有两种方式:一种是依赖Spring的自动扫描、一种是依赖@RibbonClients注解。

1)Spring的自动扫描

所谓Spring的自动扫描,就是将自定义的Ribbon配置类放在Spring容器可以扫描到的包目录下即可。
在这里插入图片描述
如上图所示,程序的启动类RibbonFeignSampleConsumerApplication所在的目录为com.saint,Ribbon配置类MyRibbonConfiguration 所在的目录为com.saint.config;又因没有指定包扫描的路径,所以目录会扫描启动类所在的包com.saint,因此Spring可以自动扫描到MyRibbonConfiguration、进而扫描到MyRule。

注意:Ribbon的配置类一定不能Spring扫描到。因为Ribbon有自己的子上下文,Spring的父上下文如果和Ribbon的子上下文重叠,会有各种各样的问题。比如:Spring和SpringMVC父子上下文重叠会导致事务不生效。

所以不推荐使用这种方式。

2)@RibbonClients注解

在启动类所在目录的父目录(com.saint)中新建config文件夹(com.config),并将MyRibbonConfiguration类移动到其中,代码目录结构如下:
在这里插入图片描述
这样操作之后,Ribbon配置类讲不会被Spring扫描到。所以需要利用@RibbonClients注解做一些配置;

在com.saint.config目录下新增GreetingServiceRibbonConf类:

package com.saint.config;

import com.config.MyRibbonConfiguration;
import org.springframework.cloud.netflix.ribbon.RibbonClients;
import org.springframework.context.annotation.Configuration;

/** * @author Saint */
@Configuration
@RibbonClients(defaultConfiguration = MyRibbonConfiguration.class)
public class GreetingServiceRibbonConf { 
   
}

3、应用到指定服务上(Ribbon局部配置)

针对Ribbon局部配置,有两种方式:代码配置 和 属性配置,上面提到的@RibbonClients就属于代码配置的方式,区别在于Ribbon局部配置使用的是@RibbonClient注解;

1)代码配置 – @RibbonClient

将GreetingServiceRibbonConf类的内容修改如下:

package com.saint.config;

import com.config.MyRibbonConfiguration;
import org.springframework.cloud.netflix.ribbon.RibbonClient;
import org.springframework.context.annotation.Configuration;

/** * 自定义 调用greeting-service服务时 使用的配置 * * @author Saint */
@Configuration
@RibbonClient(name = "GREETING-SERVICE", configuration = MyRibbonConfiguration.class)
public class GreetingServiceRibbonConf { 
   
}

当然我们也可以不使用GreetingServiceRibbonConf作为一个配置类,直接将@RibbonClient(name = "GREETING-SERVICE", configuration = MyRibbonConfiguration.class)加在启动类中也是一样的。

2)属性配置 – application.yml

首先将GreetingServiceRibbonConf类中的内容全部注释掉:
在这里插入图片描述

然后在application.yml文件中添加如下内容:

# GREETING-SERVICE为要调用的微服务名
GREETING-SERVICE:
  ribbon:
    NFLoadBalancerRuleClassName: com.saint.config.MyRule

3)两种方式对比:

  • 代码配置:基于代码、更加灵活;但是线上修改得重新打包、发布,并且还有小坑(父子上下文问题)
  • 属性配置: 配置更加直观、优先级更高(相对代码配置)、线上修改无需重新打包、发布;但是极端场景下没有代码配置方式灵活。

注意:如果代码配置和属性配置两种方式混用,属性配置优先级更高。

4)细粒度配置-最佳实践:

  1. 尽量使用属性配置,属性方式实现不了的情况下再考虑代码配置。
  2. 同一个微服务内尽量保持单一性,使用同样的配置方式,避免两种方式混用,增加定位代码的复杂性。

4、使用浏览器进行调用服务消费者

结合博文:【云原生&微服务一】SpringCloud之Ribbon实现负载均衡详细案例(集成Eureka、Ribbon),我们已经依次启动了eureka-server、ribbon-feign-sample-8081、ribbon-feign-sample-8082、ribbon-feign-sample-consumer;三个服务、四个实例。

此处我们针对服务消费者ribbon-feign-sample-consumer做四次接口调用,分别为:

  1. http://localhost:9090/say/saint
  2. http://localhost:9090/say/saint2
  3. http://localhost:9090/say/saint3
  4. http://localhost:9090/say/saint4

在这里插入图片描述
然后我们去看ribbon-feign-sample-8081、ribbon-feign-sample-8082的控制台输出:

1> ribbon-feign-sample-8081控制台输出:
在这里插入图片描述

2> ribbon-feign-sample-8082控制台输出:
在这里插入图片描述

3> 结果说明:
我们可以发现,四个请求,ribbon-feign-sample-8082实例处理了所有的请求,我们自定义的IRule已经生效。

四、自定义服务实例是否存活判定策略IPing

和IRule的自定义方式一样,这里只提供自定义的IPing,具体配置方式和IRule一样。

1、自定义IPing

MyPing表示实例永不失活,因为其isAlive(Server server)永远返回TRUE。

package com.saint.config;

import com.netflix.loadbalancer.IPing;
import com.netflix.loadbalancer.Server;

/** * 自定义IPing,判断每个服务是否还存活 * @author Saint */
public class MyPing implements IPing { 
   
    @Override
    public boolean isAlive(Server server) { 
   
        return true;
    }
}

2、修改Ribbon配置类

package com.config;

import com.netflix.loadbalancer.IPing;
import com.netflix.loadbalancer.IRule;
import com.saint.config.MyPing;
import com.saint.config.MyRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/** * 自定义Ribbon配置 * * @author Saint */
@Configuration
public class MyRibbonConfiguration { 
   

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

    @Bean
    public IPing getPing() { 
   
        return new MyPing();
    }

}

五、性能优化-饥饿加载

Ribbon默认是懒加载微服务,所以第一次调用特别慢,我们可以修改饥饿加载。

ribbon:
  eager-load:
    # 开启饥饿加载
    enabled: true
    # 开启饥饿加载的微服务列表,多个以,分隔
    clients: user-center,xxx
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/182333.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • Java生成随机数组_java生成唯一数字

    Java生成随机数组_java生成唯一数字java生成uuid介绍:UUID(通用唯一标识符)表示一个128位长的唯一值。它也被普遍称为GUID(全球唯一标识符)。UUID的标准表示形式由十六进制数字组成:533a4559-e55c-18b3-8456-555563322002并具有36个字符,其中包括四个连字符’-‘。Java中的java.util.UUID类表示一个不变的UUID。我们可以使用UUID类来生成…

    2022年9月22日
    2
  • 查看xp是否激活

    查看xp是否激活

    2021年8月5日
    51
  • SQL SERVER 的压缩功能

    SQL SERVER 的压缩功能请关注个人小站:http://sqlhis.com/SQLSERVER2008及以上提供数据库表压缩功能1.压缩分类和比率压缩分为行(ROW)压缩和页(PAGE)压缩,页压缩的压缩比率更

    2022年8月1日
    4
  • Docker安装elasticsearch、kibana和logstash,实现ELK[通俗易懂]

    Docker安装elasticsearch、kibana和logstash,实现ELK[通俗易懂]一、dockerpullelasticsearch:7.8.0dockerrun-d–nameelasticsearch\-p9200:9200-p9300:9300\-e”ES_JAVA_OPTS=-Xms512m-Xmx512m”\-e”discovery.type=single-node”\elasticsearch:7.8.0http://192.168.51.187:9200/dockerpullkibana:7.8…

    2022年5月11日
    44
  • 如何防止135端口入侵「建议收藏」

    如何防止135端口入侵「建议收藏」
    新学期到了,许多学生都要配机,新电脑的安全防卫做好了吗?能不能拒绝成为黑客的肉鸡?令人遗憾的是,很多新手都不知道或者忽视了对敏感端口的屏蔽。例如135端口,一旦黑客利用135端口进入你的电脑,就能成功地控制你的机子。我们应该如何防范通过135端口入侵呢?下面我们就为大家来揭开谜底。

      小知识:每台互联网中的计算机系统,都会同时打开多个网络端口,端口就像出入房间的门一样。因为房间的门用于方便人们的进出,而端口则为不同的网路服务提供数据交换。正如房间的门可以放进小tou一样

    2025年7月8日
    3
  • 高斯,拉普拉斯分布

    高斯,拉普拉斯分布一般来说我们可以使用正则化来避免过度拟合 但是实际上什么是正则化 什么是通用技术 以及它们有何不同 正规化是我们对学习算法所做的任何修改 旨在减少其泛化误差 而不是其训练误差 换句话说 通过防止算法过度拟合训练数据集 可以将正则化用于训练对看不见的数据更好地泛化的模型 那么 如何修改逻辑回归算法以减少泛化误差呢 我发现的常见方法是高斯 拉普拉斯 L1 和 L2 高斯还是 L2 拉普拉斯还是 L1 这有什么不同吗 可以证明 L2 和高斯或 L1 和拉普拉斯正则化对算法具有同等影响 获得正则化效果的方法有两种

    2025年6月21日
    2

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号