为Spring Cloud Ribbon/Zuul配置请求重试
来源:互联网 发布:linux 修改文件权限 编辑:程序博客网 时间:2024/06/05 17:10
来源 :
http://www.jianshu.com/p/5246ca996360
以下配置基于spring boot版本1.4.5.RELEASE,spring cloud版本采用Camden.SR6。
工程环境如下:
可以看到,compute-service服务包含了两个实例,实例1的端口号为2221、实例2的端口号2222。
通过http://localhost:3333/add
访问的时候,如果使用的是实例1,返回30;如果使用的是实例2,返回150;通过重复刷新http://localhost:3333/add
,交替返回30和150,可以发现,此时通过ribbon,已经实现了客户端负载均衡。
此时,关闭实例2,再次不断刷新http://localhost:3333/add
,会交替返回30和“Whitelabel Error Page”的异常页面。可见,在访问到实例2的时候,直接返回了“Connection refused”的问题。
为了解决这个问题,需要加入重试机制,在访问到实例2的时候, 遇到“Connection refused”,能够向实例1发起重试请求,从而返回正确结果。
在ribbon工程的application.xml文件里面,加入如下配置:
# 重试机制spring.cloud.loadbalancer.retry.enabled = truehystrix.command.default.execution.isolation.thread.timeoutInMilliseconds = 10000compute-service.ribbon.ConnectTimeout = 250compute-service.ribbon.ReadTimeout = 1000# 对所有操作请求都进行重试compute-service.ribbon.OkToRetryOnAllOperations = true# 切换实例的重试次数compute-service.ribbon.MaxAutoRetriesNextServer = 2# 对当前实例的重试次数compute-service.ribbon.MaxAutoRetries = 1
按照之前的步骤测试,仍然交替返回30和“Whitelabel Error Page”的异常页面,可见重试机制并未起效。
此时,在pom文件加入spring-boot-starter-actuator模块
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency>
重启ribbon工程,观察http://localhost:3333/autoconfig
,在negativeMatches下面,找到如下配置:
可以看到,这里给出的提示是:RibbonAutoConfiguration.loadBalancedRetryPolicyFactory方法没有找到RetryTemplate的依赖。
通过观察RibbonAutoConfiguration类的源码,可以看到如下代码:
@Bean@ConditionalOnClass(name = "org.springframework.retry.support.RetryTemplate")public LoadBalancedRetryPolicyFactory loadBalancedRetryPolicyFactory(SpringClientFactory clientFactory) { return new RibbonLoadBalancedRetryPolicyFactory(clientFactory);}
可见,在存在RetryTemplate依赖的前提下,才能获得有效的ribbon负载均衡重试策略工厂。
接下来,在pom文件,加入spring-retry的依赖:
<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId></dependency>
重启ribbon工程,重复刷新http://localhost:3333/add
,在compute-service服务的实例1和实例2都正常的情况下,交替返回30和150;
此时,关闭实例2,再次重复刷新http://localhost:3333/add
,会发现,一直返回30。只是,有时候会有1秒左右的延时,可见此时是在向实例2请求的时候,发生了“Connection refused”,然后再向实例1重试发送请求。
可见,重试机制已经生效。
此时,再观察http://localhost:3333/autoconfig
,在negativeMatches下面,会看到如下配置:
通过观察RibbonAutoConfiguration类的源码,可以看到如下代码:
@Bean@ConditionalOnMissingClass(value = "org.springframework.retry.support.RetryTemplate")public LoadBalancedRetryPolicyFactory neverRetryPolicyFactory() { return new LoadBalancedRetryPolicyFactory.NeverRetryFactory();}
可见,要让重试机制不生效,需要去掉RetryTemplate的依赖。
继续跟踪LoadBalancedRetryPolicyFactory的源码
public interface LoadBalancedRetryPolicyFactory { public LoadBalancedRetryPolicy create(String serviceId, ServiceInstanceChooser serviceInstanceChooser); static class NeverRetryFactory implements LoadBalancedRetryPolicyFactory { @Override public LoadBalancedRetryPolicy create(String serviceId, ServiceInstanceChooser serviceInstanceChooser) { return null; } }}
发现NeverRetryFactory的工厂方法直接返回了null,说明并未使用任何的重试策略机制。
可见,在不引入spring-retry的情况下,是不会让重试策略生效的。
为Zuul配置请求重试的方式,与Ribbon完全一致。
作者:吴俊达
链接:http://www.jianshu.com/p/cb69bb385d24
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
- 为Spring Cloud Ribbon/Zuul配置请求重试
- 为Spring Cloud Ribbon配置请求重试(Camden.SR2+)
- Spring Cloud Ribbon服务重试
- Spring Cloud Ribbon 重试机制
- spring cloud zuul 配置请求并发
- spring cloud 请求服务失败, 重试配置
- spring cloud ribbon配置
- spring cloud eureka zuul ribbon hystrix feign config 示例
- Spring Cloud Zuul中路由配置细节
- spring cloud Zuul 理解
- spring cloud 之 zuul
- spring cloud zuul
- spring cloud 之 zuul
- Spring Cloud Zuul
- spring-cloud-zuul超时
- Spring Cloud Zuul
- spring cloud zuul
- Spring Cloud OAuth2 & Zuul
- iOS Weex跨平台开发工具功能~简介
- 记录2017/9/6笔试题
- MSC Simufact.Forming 14.0.1 Update Only Win64 1DVD
- [C专家]分析C语言声明——关于枚举
- 并发基础_9_并发_锁_读写锁_未详解
- 为Spring Cloud Ribbon/Zuul配置请求重试
- Hybrid优化之两个WebView中的H5通信
- Android ListView setSelection()无效没作用
- Freemarker实例教程
- 代码整洁_格式
- sar 命令详解
- Werkzeug学习笔记
- 面试笔试整理4:机器学习面试问题准备(进阶)
- linux消息队列