Spring Cloud Zuul网关 Filter、熔断、重试、高可用的使用方式。

原文：http://www.cnblogs.com/ityouknow/p/8391593.html

 

时间过的很快，写springcloud(十)：服务网关zuul初级篇还在半年前，如今已是2018年了，咱们继续探讨Zuul更高级的使用方式。

上篇文章主要介绍了Zuul网关使用模式，以及自动转发机制，但其实Zuul还有更多的应用场景，好比：鉴权、流量转发、请求统计等等，这些功能均可以使用Zuul来实现。

Zuul的核心

Filter是Zuul的核心，用来实现对外服务的控制。Filter的生命周期有4个，分别是“PRE”、“ROUTING”、“POST”、“ERROR”，整个生命周期能够用下图来表示。

Zuul大部分功能都是经过过滤器来实现的，这些过滤器类型对应于请求的典型生命周期。

• PRE： 这种过滤器在请求被路由以前调用。咱们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
• ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。
• POST：这种过滤器在路由到微服务之后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
• ERROR：在其余阶段发生错误时执行该过滤器。
  除了默认的过滤器类型，Zuul还容许咱们建立自定义的过滤器类型。例如，咱们能够定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。

Zuul中默认实现的Filter

类型	顺序	过滤器	功能
pre	-3	ServletDetectionFilter	标记处理Servlet的类型
pre	-2	Servlet30WrapperFilter	包装HttpServletRequest请求
pre	-1	FormBodyWrapperFilter	包装请求体
route	1	DebugFilter	标记调试标志
route	5	PreDecorationFilter	处理请求上下文供后续使用
route	10	RibbonRoutingFilter	serviceId请求转发
route	100	SimpleHostRoutingFilter	url请求转发
route	500	SendForwardFilter	forward请求转发
post	0	SendErrorFilter	处理有错误的请求响应
post	1000	SendResponseFilter	处理正常的请求响应

禁用指定的Filter

能够在application.yml中配置须要禁用的filter，格式：

zuul:
    FormBodyWrapperFilter:
        pre:
            disable: true

自定义Filter

实现自定义Filter，须要继承ZuulFilter的类，并覆盖其中的4个方法。

public class MyFilter extends ZuulFilter { @Override String filterType() { return "pre"; //定义filter的类型，有pre、route、post、error四种 } @Override int filterOrder() { return 10; //定义filter的顺序，数字越小表示顺序越高，越先执行 } @Override boolean shouldFilter() { return true; //表示是否须要执行该filter，true表示执行，false表示不执行 } @Override Object run() { return null; //filter须要执行的具体操做 } }

自定义Filter示例

咱们假设有这样一个场景，由于服务网关应对的是外部的全部请求，为了不产生安全隐患，咱们须要对请求作必定的限制，好比请求中含有Token便让请求继续往下走，若是请求不带Token就直接返回并给出提示。

首先自定义一个Filter，在run()方法中验证参数是否含有Token。

public class TokenFilter extends ZuulFilter { private final Logger logger = LoggerFactory.getLogger(TokenFilter.class); @Override public String filterType() { return "pre"; // 能够在请求被路由以前调用 } @Override public int filterOrder() { return 0; // filter执行顺序，经过数字指定 ,优先级为0，数字越大，优先级越低 } @Override public boolean shouldFilter() { return true;// 是否执行该过滤器，此处为true，说明须要过滤 } @Override public Object run() { RequestContext ctx = RequestContext.getCurrentContext(); HttpServletRequest request = ctx.getRequest(); logger.info("--->>> TokenFilter {},{}", request.getMethod(), request.getRequestURL().toString()); String token = request.getParameter("token");// 获取请求的参数 if (StringUtils.isNotBlank(token)) { ctx.setSendZuulResponse(true); //对请求进行路由 ctx.setResponseStatusCode(200); ctx.set("isSuccess", true); return null; } else { ctx.setSendZuulResponse(false); //不对其进行路由 ctx.setResponseStatusCode(400); ctx.setResponseBody("token is empty"); ctx.set("isSuccess", false); return null; } } }

将TokenFilter加入到请求拦截队列，在启动类中添加如下代码：

@Bean public TokenFilter tokenFilter() { return new TokenFilter(); }

这样就将咱们自定义好的Filter加入到了请求拦截中。

测试

咱们依次启动示例项目：spring-cloud-eureka、spring-cloud-producer、spring-cloud-zuul，这个三个项目均为上一篇示例项目，spring-cloud-zuul稍微进行改造。

访问地址：http://localhost:8888/spring-cloud-producer/hello?name=neo，返回：token is empty ，请求被拦截返回。
访问地址：http://localhost:8888/spring-cloud-producer/hello?name=neo&token=xx，返回：hello neo，this is first messge，说明请求正常响应。

经过上面这例子咱们能够看出，咱们可使用“PRE"类型的Filter作不少的验证工做，在实际使用中咱们能够结合shiro、oauth2.0等技术去作鉴权、验证。

路由熔断

当咱们的后端服务出现异常的时候，咱们不但愿将异常抛出给最外层，指望服务能够自动进行一降级。Zuul给咱们提供了这样的支持。当某个服务出现异常时，直接返回咱们预设的信息。

咱们经过自定义的fallback方法，而且将其指定给某个route来实现该route访问出问题的熔断处理。主要继承ZuulFallbackProvider接口来实现，ZuulFallbackProvider默认有两个方法，一个用来指明熔断拦截哪一个服务，一个定制返回内容。

public interface ZuulFallbackProvider { /**  * The route this fallback will be used for.  * @return The route the fallback will be used for.  */ public String getRoute(); /**  * Provides a fallback response.  * @return The fallback response.  */ public ClientHttpResponse fallbackResponse(); }

实现类经过实现getRoute方法，告诉Zuul它是负责哪一个route定义的熔断。而fallbackResponse方法则是告诉 Zuul 断路出现时，它会提供一个什么返回值来处理请求。

后来Spring又扩展了此类，丰富了返回方式，在返回的内容中添加了异常信息，所以最新版本建议直接继承类FallbackProvider 。

咱们以上面的spring-cloud-producer服务为例，定制它的熔断返回内容。

@Component public class ProducerFallback implements FallbackProvider { private final Logger logger = LoggerFactory.getLogger(FallbackProvider.class); //指定要处理的 service。 @Override public String getRoute() { return "spring-cloud-producer"; } 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(); } }

当服务出现异常时，打印相关异常信息，并返回"The service is unavailable."。

启动项目spring-cloud-producer-2，这时候服务中心会有两个spring-cloud-producer项目，咱们重启Zuul项目。再手动关闭spring-cloud-producer-2项目，屡次访问地址：http://localhost:8888/spring-cloud-producer/hello?name=neo&token=xx，会交替返回：

hello neo，this is first messge The service is unavailable. ...

根据返回结果能够看出：spring-cloud-producer-2项目已经启用了熔断，返回:The service is unavailable.

Zuul 目前只支持服务级别的熔断，不支持具体到某个URL进行熔断。

路由重试

有时候由于网络或者其它缘由，服务可能会暂时的不可用，这个时候咱们但愿能够再次对服务进行重试，Zuul也帮咱们实现了此功能，须要结合Spring Retry 一块儿来实现。下面咱们以上面的项目为例作演示。

添加Spring Retry依赖

首先在spring-cloud-zuul项目中添加Spring Retry依赖。

<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> </dependency>

开启Zuul Retry

再配置文件中配置启用Zuul Retry

#是否开启重试功能 zuul.retryable=true #对当前服务的重试次数 ribbon.MaxAutoRetries=2 #切换相同Server的次数 ribbon.MaxAutoRetriesNextServer=0

这样咱们就开启了Zuul的重试功能。

测试

咱们对spring-cloud-producer-2进行改造，在hello方法中添加定时，而且在请求的一开始打印参数。

@RequestMapping("/hello") public String index(@RequestParam String name) { logger.info("request two name is "+name); try{ Thread.sleep(1000000); }catch ( Exception e){ logger.error(" hello two error",e); } return "hello "+name+"，this is two messge"; }

重启 spring-cloud-producer-2和spring-cloud-zuul项目。

访问地址：http://localhost:8888/spring-cloud-producer/hello?name=neo&token=xx，当页面返回：The service is unavailable.时查看项目spring-cloud-producer-2后台日志以下：

2018-01-22 19:50:32.401 INFO 19488 --- [io-9001-exec-14] o.s.c.n.z.f.route.FallbackProvider : request two name is neo 2018-01-22 19:50:33.402 INFO 19488 --- [io-9001-exec-15] o.s.c.n.z.f.route.FallbackProvider : request two name is neo 2018-01-22 19:50:34.404 INFO 19488 --- [io-9001-exec-16] o.s.c.n.z.f.route.FallbackProvider : request two name is neo

说明进行了三次的请求，也就是进行了两次的重试。这样也就验证了咱们的配置信息，完成了Zuul的重试功能。

注意

开启重试在某些状况下是有问题的，好比当压力过大，一个实例中止响应时，路由将流量转到另外一个实例，颇有可能致使最终全部的实例全被压垮。说到底，断路器的其中一个做用就是防止故障或者压力扩散。用了retry，断路器就只有在该服务的全部实例都没法运做的状况下才能起做用。这种时候，断路器的形式更像是提供一种友好的错误信息，或者伪装服务正常运行的假象给使用者。

不用retry，仅使用负载均衡和熔断，就必须考虑到是否可以接受单个服务实例关闭和eureka刷新服务列表之间带来的短期的熔断。若是能够接受，就无需使用retry。

Zuul高可用

咱们实际使用Zuul的方式如上图，不一样的客户端使用不一样的负载将请求分发到后端的Zuul，Zuul在经过Eureka调用后端服务，最后对外输出。所以为了保证Zuul的高可用性，前端能够同时启动多个Zuul实例进行负载，在Zuul的前端使用Nginx或者F5进行负载转发以达到高可用性。

示例代码-github

示例代码-码云