时间过的很快,写springcloud(十):服务网关zuul初级篇还在半年前,如今已是2018年了,咱们继续探讨Zuul更高级的使用方式。html
上篇文章主要介绍了Zuul网关使用模式,以及自动转发机制,但其实Zuul还有更多的应用场景,好比:鉴权、流量转发、请求统计等等,这些功能均可以使用Zuul来实现。前端
Filter是Zuul的核心,用来实现对外服务的控制。Filter的生命周期有4个,分别是“PRE”、“ROUTING”、“POST”、“ERROR”,整个生命周期能够用下图来表示。java
Zuul大部分功能都是经过过滤器来实现的,这些过滤器类型对应于请求的典型生命周期。git
类型 | 顺序 | 过滤器 | 功能 |
---|---|---|---|
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 | 处理正常的请求响应 |
禁用指定的Filtergithub
能够在application.yml中配置须要禁用的filter,格式:spring
zuul:
FormBodyWrapperFilter:
pre:
disable: true
复制代码
实现自定义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须要执行的具体操做
}
}
复制代码
咱们假设有这样一个场景,由于服务网关应对的是外部的全部请求,为了不产生安全隐患,咱们须要对请求作必定的限制,好比请求中含有Token便让请求继续往下走,若是请求不带Token就直接返回并给出提示。安全
首先自定义一个Filter,在run()方法中验证参数是否含有Token。bash
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在经过Eureka调用后端服务,最后对外输出。所以为了保证Zuul的高可用性,前端能够同时启动多个Zuul实例进行负载,在Zuul的前端使用Nginx或者F5进行负载转发以达到高可用性。
参考:
Spring Cloud(七)服务网关 Zuul Filter 使用
Spring Cloud技术分析(4)- spring cloud zuul
Zuul 路由使用