曾经的项目-zuul过滤器

我们基层党建平台使用zuul做网关，版本1.3.1，zuul这边设置了多个过滤器，做个回顾。

首先简单说下zuul的工作过程

zuul过滤器在请求到zuul和zuul转发到对应服务前做过滤，看这个请求是否符合要求，如果没有zuul过滤器，请求将直接被转发，需要启用zuul proxy

转发逻辑可以看下具体的实现，这里就不说了。zuul过滤器可以帮助我们实现基础的请求白名单，黑名单，流量染色

过滤器实现了ZuulFilter，ZuulFilter在netflix core包下面，属于spring cloud组件

实现ZuulFilter要实现4个方法

filterType
filterOrder
shouldFilter
run

回顾下主要用的几个过滤器

ColoredFilter 根据流量的染色转发到对应服务
OauthFilter 负责根据token获取用户信息，判断用户是否登录，如果没有登录返回401 对/api/**开头的请求有效
OpenApiFilter 开放api，saas开头的api请求，仅开放此filter设置对外暴露的接口允许zuul转发
OperateFilter 运营相关api

不同的filter根据filter order排序，数字越小，越先执行。

zuul filter执行顺序说明：

1  按照filterType决定顺序

Pre 优先 Post执行，此时filterOrder没有作用。

2 filterType相同

filterOrder有作用，数字越小，越先执行。（负数也是这个规则，0和-1的话，-1先执行）

3 相同filterType,相同filterOrder，都执行，执行顺序不清楚。

prefilter先执行了，post后执行了。

有机会都可以试试看。

思考：为什么用zuul做网关

我个人觉得可能是考虑到zuul网关扩展性好一点吧，可以扩展至其他微服务框架中，另外党建平台后台这边限流是自己的实现，没有依赖网关。gateway的话对比zuul多依赖了spring-webflux，仅适合于Spring Cloud套件，不过zuul是netflix的，可能对spring cloud的嵌合更好些，我们其它项目用了gateway，而且据说gateway是基于响应式的、非阻塞式的 API，zuul是基于阻塞式的 API，不支持长连接。