路由熔断
当我们的后端服务出现异常的时候,我们不希望将异常抛出给最外层,期望服务可以自动进行一降级。Zuul给我们提供了这样的支持。当某个服务出现异常时,直接返回我们预设的信息。
如果没有配置fallback,zuul调用时超时了,
我们通过自定义的fallback方法,并且将其指定给某个route来实现该route访问出问题的熔断处理。主要继承ZuulFallbackProvider接口来实现,ZuulFallbackProvider默认有两个方法,一个用来指明熔断拦截哪个服务,一个定制返回内容。
public interface FallbackProvider extends ZuulFallbackProvider { /** * Provides a fallback response based on the cause of the failed execution. * * @param cause cause of the main method failure * @return the fallback response */ ClientHttpResponse fallbackResponse(Throwable cause); }
实现类通过实现getRoute方法,告诉Zuul它是负责哪个route定义的熔断。而fallbackResponse方法则是告诉 Zuul 断路出现时,它会提供一个什么返回值来处理请求。
后来Spring又扩展了此类,丰富了返回方式,在返回的内容中添加了异常信息,因此最新版本建议直接继承类FallbackProvider
。
我们以上面的spring-cloud-producer服务为例,定制它的熔断返回内容。
package com.dxz.zuul.fallback; import java.io.ByteArrayInputStream; import java.io.IOException; import java.io.InputStream; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.cloud.netflix.zuul.filters.route.FallbackProvider; import org.springframework.http.HttpHeaders; import org.springframework.http.HttpStatus; import org.springframework.http.MediaType; import org.springframework.http.client.ClientHttpResponse; import org.springframework.stereotype.Component; @Component public class ProducerFallback implements FallbackProvider { private final Logger logger = LoggerFactory.getLogger(FallbackProvider.class); // 指定要处理的 service。 @Override public String getRoute() { return "service-producter"; } public ClientHttpResponse fallbackResponse() { return new ClientHttpResponse() { @Override public HttpStatus getStatusCode() throws IOException { return HttpStatus.OK; } @Override public int getRawStatusCode() throws IOException { return 200; } @Override public String getStatusText() throws IOException { return "OK"; } @Override public void close() { } @Override public InputStream getBody() throws IOException { return new ByteArrayInputStream("The service is unavailable.".getBytes()); } @Override public HttpHeaders getHeaders() { HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); return headers; } }; } @Override public ClientHttpResponse fallbackResponse(Throwable cause) { if (cause != null && cause.getCause() != null) { String reason = cause.getCause().getMessage(); logger.info("Excption {}", reason); } return fallbackResponse(); } }
路由转发配置:
zuul.routes.api-test.path: /api-test/** zuul.routes.consuer.path: /service-consumer/** zuul.routes.consuer.serviceId: service-consumer zuul.routes.producter.path: /service-producter/** zuul.routes.producter.serviceId: service-producter
为了便于演示,将zuul里的超时配置短些:
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 6000 hystrix.command.default.execution.timeout.enabled: true feign.hystrix.enabled: true spring.cloud.loadbalancer.retry.enabled: true ribbon.ReadTimeout: 6000 ribbon.ConnectTimeout: 6000
访问: http://127.0.0.1:8091/service-producter/book/getbook5/2?token=1
当服务出现异常时,打印相关异常信息,并返回”The service is unavailable.”。
Zuul 目前只支持服务级别的熔断,不支持具体到某个URL进行熔断。
路由重试
有时候因为网络或者其它原因,服务可能会暂时的不可用,这个时候我们希望可以再次对服务进行重试,Zuul也帮我们实现了此功能,需要结合Spring Retry 一起来实现。下面我们以上面的项目为例做演示。
添加Spring Retry依赖
首先在spring-cloud-zuul项目中添加Spring Retry依赖。
compile 'org.springframework.retry:spring-retry:1.2.2.RELEASE'
开启Zuul Retry
再配置文件中配置启用Zuul Retry
#是否开启重试功能 zuul.retryable=true #对当前服务的重试次数 ribbon.MaxAutoRetries=2 #切换相同Server的次数 ribbon.MaxAutoRetriesNextServer=0
这样我们就开启了Zuul的重试功能。
测试
我们对service-producer进行改造,在getbook5方法中添加定时,并且在请求的一开始打印参数。
@RestController @RequestMapping("/book") public class BookProducter { @Autowired private RestTemplate restTemplate; @RequestMapping(value = "/getbook5/{id}", method = RequestMethod.GET) public Book getbook5(@ApiParam("id编号") @PathVariable("id") Integer id) throws InterruptedException { System.out.println(">>>>>>>>/getbook5/" + id); int i = new Random().nextInt(20); TimeUnit.SECONDS.sleep(i); System.out.println("SLEEP=" + i + ">>>>>>>>/getbook5/" + id); if (id == 1) { return new Book(id, "《李自成》", 55, "姚雪垠", "人民文学出版社"); } else if (id == 2) { return new Book(id, "中国文学简史", 33, "林庚", "清华大学出版社"); } return new Book(id, "文学改良刍议", 33, "胡适", "无"); } }
重启 service-producter和zuul-demo项目。
访问地址:http://127.0.0.1:8091/service-producter/book/getbook5/3?token=1,当页面返回:The service is unavailable.
时查看项目service-producter后台日志如下:
说明进行了三次的请求,也就是进行了两次的重试。这样也就验证了我们的配置信息,完成了Zuul的重试功能。
注意
开启重试在某些情况下是有问题的,比如当压力过大,一个实例停止响应时,路由将流量转到另一个实例,很有可能导致最终所有的实例全被压垮。说到底,断路器的其中一个作用就是防止故障或者压力扩散。用了retry,断路器就只有在该服务的所有实例都无法运作的情况下才能起作用。这种时候,断路器的形式更像是提供一种友好的错误信息,或者假装服务正常运行的假象给使用者。
不用retry,仅使用负载均衡和熔断,就必须考虑到是否能够接受单个服务实例关闭和eureka刷新服务列表之间带来的短时间的熔断。如果可以接受,就无需使用retry。