一.路由规则
1、创建项目zuul-demo,创建过程和Eureka客户端一致!
2、 通过@EnableZuulProxy注解开启Zuul的功能：
@SpringBootApplication
@EnableEurekaClient
@EnableZuulProxy // 开启Zuul的网关功能
public class ZuulDemoApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulDemoApplication.class, args);
}
}
3、编写配置
server:
port: 7082
spring:
application:
name: api-gateway #指定服务名
eureka:
client:
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
service-url:
defaultZone: http://localhost:8080/eureka
4、编写路由规则
zuul:
prefix: /api # 添加路由前缀
routes:
provider: /provider/** # 这里是映射路径
将/provider/**开头的请求，代理到http://127.0.0.1:8083
5、简化路由配置
zuul默认会从拉取的服务列表中匹配相对应的映射路径(映射匹配路径和服务名一样的情况,就可以使用默认),因此如果服务名和匹配映射路径一致就可以不配置
默认情况下，一切服务的映射路径就是服务名本身。
- 例如服务名为：
provider，则默认的映射路径就是：provider
6、启动测试
访问localhost:7082/api/provider/name=andy 显示 andy你好呀,这里是provider
二.过滤器ZuulFilter
1、ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：
public abstract ZuulFilter implements IZuulFilter{
abstract public String filterType();
abstract public int filterOrder();
boolean shouldFilter();// 来自IZuulFilter
Object run() throws ZuulException;// IZuulFilter
}
shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。
filterType：返回字符串，代表过滤器的类型。包含以下4种：
pre：请求在被路由之前执行
routing：在路由请求时调用
post：在routing和errror过滤器之后调用
error：处理请求时发生错误调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。
2、过滤器执行生命周期：
- 正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
- 异常流程：
- 整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。
3、使用场景
- 请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
- 异常处理：一般会在error类型和post类型过滤器中结合来处理。
- 服务调用时长统计：pre和post结合使用。
4、自定义过滤器
@Component
public class LoginFilter extends ZuulFilter{
@Override
public String filterType() {
// 登录校验，肯定是在前置拦截
return "pre";
}
@Override
public int filterOrder() {
// 顺序设置为1
return 1;
}
@Override
public boolean shouldFilter() {
// 返回true，代表过滤器生效。
return true;
}
@Override
public Object run() throws ZuulException {
// 登录校验逻辑。
// 1）获取Zuul提供的请求上下文对象
RequestContext ctx = RequestContext.getCurrentContext();
// 2) 从上下文中获取request对象
HttpServletRequest req = ctx.getRequest();
// 3) 从请求中获取token
String token = req.getParameter("access-token");
// 4) 判断
if(token == null || "".equals(token.trim())){
// 没有token，登录校验失败，拦截
ctx.setSendZuulResponse(false);
// 返回401状态码。也可以考虑重定向到登录页。
ctx.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
}
// 校验通过，可以考虑把用户信息放入上下文，继续向后执行
return null;
}
}
5、测试
没有token参数时，访问失败： 状态码显示为401
添加token参数后,访问成功!
6、负载均衡和熔断
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：
zuul:
retryable: true #开启zuul的重试
ribbon:
ConnectTimeout: 250 # 连接超时时间(ms)
ReadTimeout: 2000 # 通信超时时间(ms)
OkToRetryOnAllOperations: true # 是否对所有操作重试
MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数
MaxAutoRetries: 1 # 同一实例的重试次数
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMillisecond: 6000 # 熔断超时时长：6000ms