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中会根据服务名从注册表获取该服务对应的服务信息集合,然后根据设置的负载均衡规则选择一个服务信息;

之后将将请求地址中的服务名称称替换为真实的地址,然后发起请求。

Spring-Cloud之Ribbon原理剖析

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

Spring-Cloud之Ribbon原理剖析

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zgzwjf.html