Spring Cloud实战小贴士:Ribbon的饥饿加载(eager-load)模式
2017-11-17 10:11
411 查看
我们在使用Spring Cloud的Ribbon或Feign来实现服务调用的时候,如果我们的机器或网络环境等原因不是很好的话,有时候会发现这样一个问题:我们服务消费方调用服务提供方接口的时候,第一次请求经常会超时,而之后的调用就没有问题了。下面我们就来说说造成这个问题的原因,以及如何解决的方法。
造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去创建相应的Client,所以第一次调用的耗时不仅仅包含发送HTTP请求的时间,还包含了创建RibbonClient的时间,这样一来如果创建时间速度较慢,同时设置的超时时间又比较短的话,很容易就会出现上面所描述的显现。
从日志中我们也能知道这一点细节,在第一次发起调用的时候我们可以从日志中看到如下信息:
而Feign的实现基于Ribbon,所以它也有一样的问题,下面就来看看如何解决这个问题。
解决的方法很简单,既然第一次调用时候产生RibbonClient耗时,那么就让它提前创建,而不是在第一次调用的时候创建。
在Spring Cloud的Dlaston版本中提供了几个新的参数,它们可以很方便的帮我们实现这样的功能。
参数说明:
ribbon.eager-load.enabled:开启Ribbon的饥饿加载模式
ribbon.eager-load.clients:指定需要饥饿加载的客户端名称、服务名
通过上面的配置完成之后,我们尝试重启一下服务消费者,这个时候我们会发现,我们没有开始调用服务接口,但是上面初始化负载均衡的日志就已经打印出来了。这就说明我们对ribbon的饥饿加载模块设置已经生效了。
问题原因
造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去创建相应的Client,所以第一次调用的耗时不仅仅包含发送HTTP请求的时间,还包含了创建RibbonClient的时间,这样一来如果创建时间速度较慢,同时设置的超时时间又比较短的话,很容易就会出现上面所描述的显现。从日志中我们也能知道这一点细节,在第一次发起调用的时候我们可以从日志中看到如下信息:
123 | 2017-09-25 08:29:54,201 INFO [main] com.netflix.loadbalancer.DynamicServerListLoadBalancer - DynamicServerListLoadBalancer for client hello-service initialized: DynamicServerListLoadBalancer:{NFLoadBalancer:name=hello-service,current list of Servers=[192.168.99.176:9901],Load balancer stats=Zone stats: {unknown=[Zone:unknown; Instance count:1; Active connections count: 0; Circuit breaker tripped count: 0; Active connections per server: 0.0;]},Server stats: [[Server:192.168.99.176:9901; Zone:UNKNOWN; Total Requests:0; Successive connection failure:0; Total blackout seconds:0; Last connection made:Thu Jan 01 08:00:00 CST 1970; First connection made: Thu Jan 01 08:00:00 CST 1970; Active Connections:0; total failure count in last (1000) msecs:0; average resp time:0.0; 90 percentile resp time:0.0; 95 percentile resp time:0.0; min resp time:0.0; max resp time:0.0; stddev resp time:0.0]]}ServerList:ConsulServerList{serviceId='hello-service', tag=null} |
解决方法
解决的方法很简单,既然第一次调用时候产生RibbonClient耗时,那么就让它提前创建,而不是在第一次调用的时候创建。在Spring Cloud的Dlaston版本中提供了几个新的参数,它们可以很方便的帮我们实现这样的功能。
12 | ribbon.eager-load.enabled=trueribbon.eager-load.clients=hello-service, user-service |
ribbon.eager-load.enabled:开启Ribbon的饥饿加载模式
ribbon.eager-load.clients:指定需要饥饿加载的客户端名称、服务名
通过上面的配置完成之后,我们尝试重启一下服务消费者,这个时候我们会发现,我们没有开始调用服务接口,但是上面初始化负载均衡的日志就已经打印出来了。这就说明我们对ribbon的饥饿加载模块设置已经生效了。
相关文章推荐
- Spring Cloud实战小贴士:Ribbon的饥饿加载(eager-load)模式
- Spring Cloud实战小贴士:Ribbon的饥饿加载(eager-load)模式
- Spring Cloud实战小贴士:Zuul的饥饿加载(eager-load)使用
- Ribbon的饥饿加载(eager-load)模式
- Spring Cloud实战小贴士:Zuul的饥饿加载(eager-load)使用
- Spring Cloud实战小贴士:Zuul处理Cookie和重定向
- Spring Cloud实战小贴士:Zuul处理Cookie和重定向
- Spring Cloud综合实战 - 基于TCC补偿模式的分布式事务
- [Ext JS 4] 实战之Load Mask(加载遮罩)的显示与隐藏
- MySQL Connector Net 6.6.5 Entity Framework 显式预加载 Eager Load Bug
- [Ext JS 4] 实战之Load Mask(加载遮罩)的显示与隐藏
- spring cloud学习——16. Client Side Load Balancer: Ribbon
- Spring Cloud实战小贴士:Zuul处理Cookie和重定向
- Spring Cloud实战小贴士:Zuul统一异常处理(三)【Dalston版】
- Android源码分析实战之JNI so库加载System.loadLibrary流程分析
- MySQL Connector Net 6.6.5 Entity Framework 显式预加载 Eager Load Bug
- ActiveRecord 的数据三种预加载形式 - includes, preload, eager_load和joins(不是预加载)
- Error 25007.初始化合成时发生错误。安装程序无法使用 LoadLibraryShim() 加载合成。
- yii2加载第三方自动模式(composer)与手动模式
- 设计延迟加载的“单例设计模式”