Spring-Cloud之Ribbon原理剖析

我们知道Ribbon主要的工作就是进行负载均衡,帮助我们无需再关注微服务中集群的地址信息,因此在源码剖析中我们就主要关注这部分的内容。

内置的负载均衡规则

  • RoundRobinRule:直接轮询的方案;即每次从server list中依次选择。
  • AvailabilityfileringRule:根据服务器可用性来决定;比如某个服务器的并发请求过高,那么此时ribbon就会绕过不再访问;同时如果3次连接失败就会等待30秒后再次访问;如果不断失败,那么等待时间会不断变长,如果某个服务器的并发请求太高了,那么会绕过去,不再访问。
  • WeightedResponseTimeRule:根据权重来分配;每个服务器都可以有权重,权重高就优先访问,如果某个服务器响应时间比较长,那么权重就会降低,减少访问。
  • ZoneAvoidanceRule:根据区域和服务器来进行负载均衡,也就是根据机房来分配,里面再使用轮询的方式。默认的就是这个
  • BestAvailableRule:忽略连接失败的服务器,同时尽量找并发比较低的服务器来请求。
  • RandomRule:随机选择一个。
  • RetryRule:在轮询的方案上增加重试机制;即通过轮询的方式选择一个服务器请求,在失败的时候会重新再找一个重试。

可以通过ribbon.NFLoadBalancerRuleClassName: top.vchar.MyRule 来切换规则

RestTemplate 加上 @LoadBalanced

当我们在 RestTemplate 上添加 @LoadBalanced 注解后,在写接口地址的时候可以直接使用服务名代替真实的地址;在执行请求的过程中Ribbon会自动的将其替换为真实的地址。 加上 @LoadBalanced 注解就可以让 RestTemplate的请求交ribbon的原理如下:

  • 在ribbon的整合中有个LoadBalancerAutoConfiguration的配置,它里面会注入所有带@LoadBalanced 注解的 RestTemplate的bean;然后会给这些RestTemplate添加上一个LoadBalancerInterceptor的拦截器;
  • 在 RestTemplate 执行请求的时候,这个拦截器会拦截请求,将其转给LoadBalancerClient(实际是RibbonLoadBalancerClient来实现的)来做接下来的全部操作。
  • 在RibbonLoadBalancerClient中会根据服务名从注册表获取该服务对应的服务信息集合,然后根据设置的负载均衡规则选择一个服务信息;
  • 之后将将请求地址中的服务名称称替换为真实的地址,然后发起请求。

IPing机制

Ribbon中IPing机制其实就是定时的去检查拿到的注册表中的服务是否可用,如果不可用将会移除它。默认使用NIWSDiscoveryPing类实现IPing;它就是启动了一个定时任务,默认每隔30s执行一次,通过检查服务的状态是否是UP状态来判断该服务是否存活。

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

关于Ribbon获取服务注册表

Ribbon并没有直接使用eureka client的注册表信息,而是拷贝了一份注册表信息重新封装了一下。 它在初始化的时候会通过PollingServerListUpdater来启动一个定时任务,默认每隔30s到eureka client的注册表中拷贝一次然后刷新它自己的。这个时间可以通过配置 ribbon.ServerListRefreshInterval 来修改定时任务的执行间隔时间。

那么如果某台机器故障宕机,ribbon需要多久才能感知到呢?下面我们来分析下:首先eureka server的服务故障感知最坏的情况下是需要180s,同时只读缓存默认30s才会自动更新,eureka client默认30s才会去拉取一次注册信息,加上ribbon自己的刷新时间30s,那么整个过程需要的时间就是180s+30s+30s+30s=270s,也就是大约要4分钟半左右。

关于Ribbon的配置

Ribbon配置支持的key在ribbon-core中的CommonClientConfigKey类中,我们可以根据需要到里面去查阅;配置方式分为全局和局部。

  • 全部配置直接以ribbon开头,比如:ribbon.ServerListRefreshInterval:20 修改ribbon刷新注册表的时间
  • 局部配置就是针对某个服务的配置,格式为:<clientName>.<nameSpace>.<propertyName>=<value> ;示例

# 配置memberServer的服务调用失败的时候重试一次
memberServer.ribbon.MaxAutoRetries=1

————下载必看————

1、资源通过互联网渠道公开获取,仅供阅读测试,请在下载后24小时内删除,谢谢合作!
2、本站解压密码统一为:yudouyudou
3、本站微信客服/失效补发:rsst58
4、若版权方认为本站侵权,请联系发邮件至(rsstime@qq.com)处理。
5、关于下载,播放声音字幕,解压等问题,请点击查看>>常见问题
时光屋 » Spring-Cloud之Ribbon原理剖析

发表评论

至臻视听_发烧收藏

会员介绍 常见问题