springCloud之Ribbon从使用到精通

1.ribbon是什么?

1.1 两种负载均衡方案{

集中:即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件,软件 F5,nginx)
由该设施负责把访问请求通过某种策略转发至服务的提供方(服务端负载均衡)
在这里插入图片描述
集成到服务中:将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选择出一个合适的服务器(客户端负载均衡)
在这里插入图片描述}

1.2 ribbon简介

Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等。简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随即连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

2.ribbon如何应用到spirngCloud项目中?

1.配置jar,需要在父项目gradle.build中引入负载均衡和springCloud的整合jar
在这里插入图片描述
2.我们只需要修改配置文件就可以实现ribbon组件的应用了(如果不配置他会使用默认的配置)
(1)配置方式,对所有的微服务起作用.(配置自己的yml文件)
点击进入naocs–>进入配置管理–>选择xscyl-dev空间–>进入xscyl-common.yml给所有的项目添加配置.
在这里插入图片描述
(2)对单独的微服务起作用.
点击进入nacos–>进入配置管理–>选择xscyl-dev空间–>进入xscy-product.yml
在这里插入图片描述
3.我们启动一个gateWay作为负载均衡消费者,启动两个用户实例去负载访问用户服务者
在这里插入图片描述
在这里插入图片描述
至此我们可以确认ribbon已经去到默认作用了,所以我们可以进行详细的配置了.

3.ribbon组件/配置重要参数讲解?

3.1riibbon的组件(重要接口)

IRule–>NFLoadBalancerRuleClassName: Should implement IRule(负载均衡算法)
功能:根据特定算法中从服务列表中选取一个要访问的服务 常用IRule实现有以下几种:
RoundRobinRule
轮询规则,默认规则。同时也是更高级rules的回退策略
AvailabilityFilteringRule
这个负载均衡器规则,会先过滤掉以下服务:
a. 由于多次访问故障而处于断路器跳闸状态,并发的连接数量超过阈值
然后对剩余的服务列表按照RoundRobinRule策略进行访问
WeightedResponseTimeRule
根据平均响应时间计算所有服务的权重,响应时间越快,服务权重越重、被选中的概率越高。刚启动时,如果统计信息不足,则使用RoundRobinRule策略,等统计信息足够,会切换到WeightedResponseTimeRule。
RetryRule
先按照RoundRobinRule的策略获取服务,如果获取服务失败,则在指定时间内会进行重试,获取可用的服务
BestAvailableRule
此负载均衡器会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务
RandomRule:随机策略
ServerListUpdater
功能:被DynamicServerListLoadBalancer用于动态的更新服务列表。 常用的实现类:
PollingServerListUpdater–>?有问题
默认的实现策略。此对象会启动一个定时线程池,定时执行更新策略
IClientConfig 功能:定义各种配置信息,用来初始化ribbon客户端和负载均衡器 DefaultClientConfigImpl
IPing(暂不介绍)—>NFLoadBalancerPingClassName: Should implement IPing(服务可用性检查)
功能在后台运行的一个组件,用于检查服务列表是否都活 NIWSDiscoveryPing,不执行真正的ping。如果Discovery Client认为是在线,则程序认为本次心跳成功,服务活着 ,PingUrl 此组件会使用HttpClient调用服务的一个URL,如果调用成功,则认为本次心跳成功,表示此服务活着。
NoOpPing ,永远返回true,即认为服务永远活着,DummyPing 默认实现,默认返回true,即认为服务永远活着
ServerList(暂不介绍),—>NIWSServerListClassName: Should implement ServerList(服务列表获取)
功能:存储服务列表。分为静态和动态。如果是动态的,后台有个线程会定时刷新和过滤服务列表,常用ServerList 实现有以下几种:
ConfigurationBasedServerList
DomainExtractingServerList
代理类,根据ServerList的值实现具体的逻辑
ServerListFilter(暂不介绍)—>NIWSServerListFilterClassName: Should implement ServerList­Filter(服务列表的过滤)
该接口允许过滤配置或动态获取的具有所需特性的服务器列表。ServerListFilter是DynamicServerListLoadBalancer用于过滤从ServerList实现返回的服务器的组件。
常用ServerListFilter 实现有以下几种:
ZoneAffinityServerListFilter(暂不介绍)
过滤掉所有的不和客户端在相同zone的服务,如果和客户端相同的zone不存在,才不过滤不同zone有服务。
启用此配置使用以下配置
.ribbon.EnableZoneAffinity=true
ZonePreferenceServerListFilter
ZoneAffinityServerListFilter的子类。和ZoneAffinityServerListFilter相似,但是比较的zone是发布环境里面的zone。过滤掉所有和客户端环境里的配置的zone的不同的服务,如果和客户端相同的zone不存在,才不进行过滤。
ServerListSubsetFilter
ZoneAffinityServerListFilter的子类。此过滤器确保客户端仅看到由ServerList实现返回的整个服务器的固定子集。 它还可以定期用新服务器替代可用性差的子集中的服务器。

3.2riibbon的重要参数(负载均衡功能和超时重试功能参数)

公共配置
在这里插入图片描述
独自配置
在这里插入图片描述
重试次数:MaxAutoRetries + MaxAutoRetriesNextServer + (MaxAutoRetries * MaxAutoRetriesNextServer )
同时配置采用的是***就近原则***

4.ribbon集成nacos遇到的问题?

4.1***超时访问问题***?

因为Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去创建相应的Client>导致访问服务的.
解决方案:
1.访问超时解决方案添加参数配置:

懒加载,启动时创建

Ribbon:
eager-load:
clients: 需要访问的服务名
enabled: true

4.1***ribbon不能实时的感知服务下线情况***?

因为我们更新ribbon本地缓存的服务列表默认是通过定时任务轮训来实现的,默认时时间是30秒轮训一次?导致服务下线并不能立刻感知.
解决方案:
1.方案一: 缩小定时刷新的时间(只要要时间间隔就无法实时感知,并且耗费服务器资源)
.ribbon.ServerListRefreshInterval:服务列表刷新频率基于定时任务拉取默认30s
ribbon:
ServerListRefreshInterval: 2000 全局配置(两秒)
2.方案二:方案二:注册监听器–监听nacos服务列表的变化,实时更新(问题网络震荡出现不会更新的情况){
参考类:com.netflix.loadbalancer.EurekaNotificationServerListUpdater的实现
3.方案3:两者结合即使用监听器同时有使用轮询的方式核心代码如下.{
/**
* 以定时任务的方式进行服务列表的更新
*/
@Override
public synchronized void start(final UpdateAction updateAction) {
if (isActive.compareAndSet(false, true)) {
final Runnable wrapperRunnable = new Runnable() {
@Override
public void run() {
if (!isActive.get()) {
if (scheduledFuture != null) {
scheduledFuture.cancel(true);
}
return;
}
try {
updateAction.doUpdate();
lastUpdated = System.currentTimeMillis();
} catch (Exception e) {
logger.warn(“Failed one update cycle”, e);
}
}
};
//
try {
// 如果并发执行也没有问题
for (String serviceName : serviceNames) {
naming.subscribe(serviceName, new EventListener() {
@Override
public void onEvent(Event event) {
System.out.println("%%%%%%%%%%");
getRefreshExecutor().execute(wrapperRunnable);
}
});
}
} catch (Exception e) {
logger.warn(“Failed one update cycle”, e);
}
scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
wrapperRunnable,
// 1秒
initialDelayMs,
// 30秒
refreshIntervalMs,
TimeUnit.MILLISECONDS
);
} else {
logger.info(“Already active, no-op”);
}
}

}

5.ribbion原理简单理解?

5.1 ribbon选择实例图解?

在这里插入图片描述

5.2 LoadBalancer 选择服务实例的流程

1.通过ServerList获取当前可用的服务实例列表;

2.通过ServerListFilter将步骤1 得到的服务列表进行一次过滤,
返回满足过滤器条件的服务实例列表;

3.应用Rule规则,结合服务实例的统计信息(连续连接失败计数,连接时间等),返回满足规则的
某一个服务实例;

4.ribbon会当LoadBalancer在选择合适的Server提供给应用后,应用会向该Server发送服务请求,则在请求的过程中,应用会根据请求的相应时间或者网络连接情况等进行统计;当应用后续从LoadBalancer选择合适的Server时,LoadBalancer 会根据每个服务的统计信息,结合Rule来判定哪个服务是最合适的
4.1补充–>(例如发生了当有某个服务存在多个实例时,在请求的过程中,负载均衡器会统计每次请求的情况(请求相应时间,是否发生网络异常等),当出现了请求出现累计重试时,负载均衡器会标识当前服务实例,设置当前服务实例的断路的时间区间,在此区间内,当请求过来时,负载均衡器会将此服务实例从可用服务实例列表中暂时剔除,优先选择其他服务实例)

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
尚硅谷Java视频教程_SpringCloud视频教程 本套视频从面试题,到SpringCloud各种核心组件,到最终的微服务架构总结,帮助大家快速入门、上手并精通微服务框架SpringCloud。 课程中对比了 Dubbo 和 SpringCloud,并深入讲授SpringCloud核心组件Eureka、Ribbon、Feign、Hystrix、HystrixDashboard、Zuul、Config。除此之外,还通过整合SpringMVC+SpringBoot+Mybatis构建一个可用的基于SpringCloud的微服务工程将上述技术组件逐步落地,让大家看得懂做得出学得会。 00、尚硅谷_SpringBoot_源码、课件 01.尚硅谷_SpringCloud_前提概述 02.尚硅谷_SpringCloud_大纲概览 03.尚硅谷_SpringCloud_从面试题开始 04.尚硅谷_SpringCloud_微服务是什么 05.尚硅谷_SpringCloud_微服务是什么2 06.尚硅谷_SpringCloud_微服务与微服务架构 07.尚硅谷_SpringCloud_微服务优缺点 08.尚硅谷_SpringCloud_微服务技术栈有哪些 09.尚硅谷_SpringCloud_为什么选择SpringCloud作为微服务架构 10.尚硅谷_SpringCloud_SpringCloud是什么 11.尚硅谷_SpringCloud_SpringCloud_VS_SpringBoot区别对比 12.尚硅谷_SpringCloud_SpringCloud_VS_Dubbo区别对比 13.尚硅谷_SpringCloud_SpringCloud功能域和官网资料介绍 14.尚硅谷_SpringCloud_SpringCloud国内使用情况 15.尚硅谷_SpringCloud_Rest微服务案例-总体概述 16.尚硅谷_SpringCloud_Rest微服务案例-父工程构建步骤 17.尚硅谷_SpringCloud_Rest微服务案例-API公共模块和部门Entity步骤 18.尚硅谷_SpringCloud_Rest微服务案例-部门服务提供者 19.尚硅谷_SpringCloud_Rest微服务案例-部门服务消费者 20.尚硅谷_SpringCloud_Eureka是什么 21.尚硅谷_SpringCloud_EurekaServer服务注册中心建立 22.尚硅谷_SpringCloud_将已有的部门微服务注册进Eureka服务中心 23.尚硅谷_SpringCloud_微服务完善_主机映射名称修改 24.尚硅谷_SpringCloud_微服务完善_主机IP信息提示 25.尚硅谷_SpringCloud_微服务完善_info内容构建 26.尚硅谷_SpringCloud_Eureka自我保护机制介绍 27.尚硅谷_SpringCloud_Eure服务发现 28.尚硅谷_SpringCloud_Eureka集群配置 29.尚硅谷_SpringCloud_Eureka比Zookeeper好在哪里 30.尚硅谷_SpringCloud_Ribbon是什么 31.尚硅谷_SpringCloud_Ribbon配置初步 32.尚硅谷_SpringCloud_Ribbon负载均衡 33.尚硅谷_SpringCloud_Ribbon核心组件IRule 34.尚硅谷_SpringCloud_自定义Ribbo的负载均衡策略(上) 35.尚硅谷_SpringCloud_自定义Ribbo的负载均衡策略(下) 36.尚硅谷_SpringCloud_Feign是什么 37.尚硅谷_SpringCloud_Feign工程构建 38.尚硅谷_SpringCloud_Hystrix断路器是什么 39.尚硅谷_SpringCloud_服务熔断 40.尚硅谷_SpringCloud_服务降级 41.尚硅谷_SpringCloud_服务降级熔断小总结 42.尚硅谷_SpringCloud_豪猪hystrixDashboard 43.尚硅谷_SpringCloud_如何查看hystrixDashboard 44.尚硅谷_SpringCloud_Zuul是什么 45.尚硅谷_SpringCloud_Zuul路由基本配置 46.尚硅谷_SpringCloud_Zuul路由访问映射规则 47.尚硅谷_SpringCloud_Config分布式配置中心是什么 48.尚硅谷_SpringCloud_Config服务端与Github通信 49.尚硅谷_SpringCloud_Config客户端通过Config服务端获得Github上的配置 50.尚硅谷_SpringCloud_Config

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值