springcloud入门实战:Feign+Ribbon实现客户端负载均衡

(4)在demo-provider重要的源码处打上断点,通过断点可以查看每次RPC实际访问的目标提供者uaa-provider的实例。

断点之一设置在ribbon-loadbalancer组件LoadBalancerContext类的getServerFromLoadBalancer方法的某行代码上(见图2-14),该方法的功能是获取目标Provider实例。每次RPC请求调用到来时,可以查看Ribbon负载均衡计算出来的Provider,它放置在类型为Server的svc变量中。

springcloud入门实战:Feign+Ribbon实现客户端负载均衡

图2-14 Ribbon计算出来的Provider值示意图

断点之二可以设置在ribbon-loadbalancer组件的

AbstractLoadBalancerAwareClient类的方法executeWithLoadBalancer的某行代码上(见图2-15),可以查看到每次RPC调用的最终URL地址保存在finalUri变量中。

springcloud入门实战:Feign+Ribbon实现客户端负载均衡

图2-15 Ribbon计算出来的最终URL地址值示意图

多次执行并观察断点处的变量值可以发现uaa-provider的两个实例轮番被RPC访问到。

本小节的演示过程可参见疯狂创客圈社群网盘小视频:“SpringCloud实战视频:Feign+Ribbon实现客户端负载均衡.mp4”。

Spring Cloud Ribbon的负载均衡策略

==========================

Ribbon负载均衡的原理是:从Eureka Client实例获取Provider服务列表清单,并且定期通过IPing实例判断清单中Provider服务实例的可用性。每次RPC调用到来时,在Provider服务列表清单中根据IRule策略类的Bean计算出每次RPC要访问的最终Provider。

Ribbon内部有一个负载均衡器接口ILoadBalance,定义了添加Provider、获取所有的Provider列表、获取可用的Provider列表等基础的操作。该接口的核心实现类

DynamicServerListLoadBalancer会通过EurekaClient(实现类为DiscoveryClient)获取Provider清单,并且通过IPing实例定期(如每10秒)向每个Provider实例发送“ping”,并且根据Provider是否有响应来判断该Provider实例是否可用。如果该Provider的可用性发生了改变,或者Provider清单中的数量和之前的不一致,就从注册中心更新或者重新拉取Provider服务实例清单。

每次RPC请求到来时,由Ribbon的IRule负载均衡策略接口的某个实现类来进行负载均衡。主要的负载均衡策略实现类如下:

1.随机策略(RandomRule)

RandomRule实现类从Provider服务列表清单中随机选择一个Provider服务实例,作为RPC请求的目标Provider。

2.线性轮询策略(RoundRobinRule)

RoundRobinRule和RandomRule相似,只是每次都取下一个Provider服务器。假设一共有5台Provider服务节点,使用线性轮询策略,第1次取第1台,第2次取第2台,第3次取第3台,以此类推。

3.响应时间权重策略(WeightedResponseTimeRule)

WeightedResponseTimeRule为每一个Provider服务维护一个权重值,它的规则简单概括为Provider服务响应时间越长,其权重就越小。在进行服务器选择时,权重值越小,被选择的机会就越少。

WeightedResponseTimeRule继承了RoundRobinRule,开始时每一个Provider都没有权重值,每当RPC请求过来时,由其父类的轮询算法完成负载均衡方式。该策略类有一个默认的每30秒执行一次的权重更新定时任务,该定时任务会根据Provider实例的响应时间更新Provider权重列表。后续有RPC过来时,将根据权重值进行负载均衡。

4.最少连接策略(BestAvailableRule)

在进行服务器选择时,该策略类遍历Provider清单,选出可用的且连接数最少的一个Provider。该策略类里面有一个LoadBalancerStats类型的成员变量,会存储所有Provider的运行状况和连接数。在进行负载均衡计算时,如果选取到的Provider为null,就会调用线性轮询策略重新选取。

如果第一次RPC请求时LoadBalancerStats成员为null,就会使用线性轮询策略来获取符合要求的实例,后续的RPC在选择的时候,才能选择连接数最少的服务。每次RPC请求时,BestAvailableRule都会统计LoadBalancerStats,作为后续请求负载均衡计算的输入。

5.重试策略(RetryRule)

该类会在一定的时限内进行Provider循环重试。RetryRule会在每次选取之后对选举的Provider进行判断,如果为null或者not alive,就会在一定的时限内(如500毫秒)不停地选取和判断。

6.可用过滤策略(AvailabilityFilteringRule)

该类扩展了线性轮询策略,会先通过默认的线性轮询策略选取一

个Provider,再去判断该Provider是否超时可用,当前连接数是否超过限制,如果都符合要求,就成功返回。

简单来说,AvailabilityFilteringRule将对候选的Provider进行可用性过滤,会先过滤掉因多次访问故障而处于熔断器跳闸状态的Provider服务,还会过滤掉并发的连接数超过阈值的Provider服务,然后对剩余的服务列表进行线性轮询。

7.区域过滤策略(ZoneAvoidanceRule)

该类扩展了线性轮询策略,除了过滤超时和连接数过多的Provider之外,还会过滤掉不符合要求的Zone区域中的所有节点。

Ribbon实现的负载均衡策略不止以上7种,还可以实现自定义的策略类。本文使用的Spring Cloud Ribbon版本中默认使用了ZoneAvoidanceRule负载均衡策略,可以通过Provider配置文件的

ribbon.NFLoadBalancerRuleClassName配置项更改实际的负载均衡策略。2.4.1小节的演示中,微服务demo-provider对uaa-provider的RPC调用使用RetryRule负载均衡策略,demo-provider的具体配置如下:

uaa-provider:

ribbon:

NFLoadBalancerRuleClassName: com.netflix.loadbalancer. RetryRule #重试+线性轮询

#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.BestAvailableRule

#最少连接策略

#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #随机选择

如果要配置全局的、针对所有Provider都使用的负载均衡策略,就可以在配置文件中直接使用

ribbon.NFLoadBalancerRuleClassName配置项进行配置,具体如下:

ribbon:

NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RetryRule #重试+线性轮询

#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.BestAvailableRule

#最少连接策略

#NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #随机选择

Spring Cloud Ribbon的常用配置

=========================

上节介绍了负载均衡的配置,本小节介绍Ribbon的一些常用配置选项,以及对这些选项进行配置的两种方式:代码方式和配置文件方式。

1.手工配置Provider实例清单

如果Ribbon没有和Eureka集成,Ribbon消费者客户端就不能从Eureka(或者其他的注册中心)拉取到Provider清单。如果不需要和Eureka集成,那么可以使用如下方式手工配置Provider清单:

ribbon:

eureka:

enabled: false #禁用Eureka

uaa-provider:

ribbon:

listOfServers:192.168.142.1:7702,192.168.233.128:7702#手工配置Provider清单这个配置是针对uaa-provider服务的,配置项的前缀就是RPC目标服务名称。配置完之后,demo-provider服务就可以通过目标服务名称uaaprovider来调用其接口。

无论是在开发环境还是在测试环境,手工配置Provider清单的方式都用得很少,之所以在此介绍该方式,仅仅是为了让大家更加明白Ribbon的工作方式。

2.RPC请求超时配置

Ribbon中有两种和时间相关的设置,分别是请求连接的超时时间ConnectTimeout和请求处理的超时时间ReadTimeout。大家都知道,HTTP请求的3个阶段:建立连接阶段、数据传送阶段、断开连接阶段。ConnectTimeout指的是第一个阶段建立连接所能用的最长时间。第一个阶段需要进行3次握手,ConnectTimeout用于设置3次握手完成的最长时间。如果在ConnectTimeout设置的时间内消费端连接不上目标Provider服务,连接就会超时。这个超时也许是目标Provider宕机所导致的,也许是网络延迟所导致的。

ReadTimeout指的是连接成功之后,从服务器读取到可用数据所花费的最长时间。如果在ReadTimeout设置的时间内目标Provider没有及时返回数据,就会导致读超时,也常常被称为请求处理超时。Ribbon设置RPC请求超时的规则如下:

ribbon:

ConnectTimeout: 30000 #连接超时时间,单位为毫秒

ReadTimeout: 30000 #读取超时时间,单位为毫秒

在实际场景中,每个目标Provider的性能要求也许是不一样的,可以单独为某些Provider目标服务设置特定的超时时间,只要通过服务名称进行指定即可:

uaa-provider:

ribbon:

ConnectTimeout: 30000 #连接超时时间,单位为毫秒

ReadTimeout: 30000 #读取超时时间,单位为毫秒

3.重试机制配置

在有很多Provider实例同时运行的集群环境中难免会有某个Provider节点出现故障。如果某个目标Provider节点已经挂掉,但其信息还是缓存在消费者的Ribbon实例清单,就会导致RPC时发生请求失败。要解决上述问题,简单的方法就是利用Ribbon自带的重试策略进行重试,此时只需要指定消费者的负载策略为重试策略,并且配置适当的重试参数即可。

为进行具体的演示,demo-provider微服务的重试策略和参数配置如下:

ribbon:

MaxAutoRetries: 1 #同一台实例的最大重试次数,但是不包括首次调用,默认为1次 MaxAutoRetriesNextServer: 1 #重试其他实例的最大重试次数,不包括首次调用,默认为0次 OkToRetryOnAllOperations: true #是否对所有操作都进行重试,默认为false

ServerListRefreshInterval: 2000 #从注册中心刷新Provider的时间间隔,默认为2000毫秒,即2秒 retryableStatusCodes: 400,401,403,404,500,502,504 NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RetryRule #负载均衡配置为重试策略在上面的配置中,选项retryableStatusCodes用于配置对特定的HTTP响应码进行重试,常见的HTTP请求的状态码如下:

(1)2xx(成功):这类状态码标识客户端的请求被成功接收、理解并接受,常见的如200(OK)、204(NoContent)。

(2)3xx(重定向):这类状态码标识请求发起端或请求代理要做出进一步的动作来完成请求,常见的如301(MovedPermanently)、302(MovedTemprarily)。

(3)4xx(客户端错误):这类状态码是客户端出错时使用的,常见的如400(BadRequest)、401(Unauthorized)、403(Forbidden)、404(NotFound)。

(4)5xx(服务器错误):这类状态码表示服务器知道自己出错或者没有能力执行请求,常见的如500(InternalServer Error)、502(BadGateway)、504(GatewayTimeout)。如果一个消费者依赖很多Provider,就可以使用上面的重试策略与参数针对特定的目标Provider进行单独配置。只要在配置时通过微服务名称进行指定即可:

uaa-provider:

ribbon:

MaxAutoRetries: 1

MaxAutoRetriesNextServer: 1

OkToRetryOnAllOperations: true

ServerListRefreshInterval: 2000

retryableStatusCodes: 400,401,403,404,500,502,504

NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RetryRule

4.代码配置Ribbon

配置Ribbon比较简单的方式是使用配置文件,除此之外,还可以通过代码的方式进行配置。

一个常见的场景为:实际的RPC往往需要传递一些特定请求头,比如认证令牌,这时可以通过代码配置的方式对Ribbon的请求模板template进行请求头设置,完成请求头的传递。参考的代码如下:

package com.crazymaker.springcloud.standard.config;

/**

*通过代码配置Ribbon

*/

@Configuration

public class FeignConfiguration implements RequestInterceptor

{

/**

*配置RPC时的请求头与参数,将来自用户的令牌传递给目标Provider

*@param template请求模板

*/

@Override

public void apply(RequestTemplate template)

{

/**

*从用户请求的上下文属性获取用户令牌

*/

ServletRequestAttributes attributes =

(ServletRequestAttributes)

RequestContextHolder.getRequestAttributes();

if (null == attributes)

{

return;

}

HttpServletRequest request = attributes.getRequest(); /**

*获取令牌

*/

String token = request.getHeader

(SessionConstants.AUTHORIZATION_HEAD);

if (null != token)

{

token = StringUtils.removeStart(token, "Bearer ");

/**

*设置令牌

*/

template.header("token ", new String[]{token});

}

}

/**

*配置负载均衡策略

*/

@Bean

public IRule ribbonRule()

{

/**

*配置为线性轮询策略

*/

return new RoundRobinRule();

}

}

在以上配置代码的apply()方法中,为Ribbon的RPC请求模板template增加了一个叫作token的请求头,用于在RPC调用时进行用户令牌的传递;另外,在以上代码的ribbonRule()方法中,通过程序的方式配置了Ribbon的负载均衡策略为线性轮询。

  • 11
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值