这里说的是zuul
服务过滤
自定义过滤器的实现，需要继承ZuulFilter，需要重写实现下面四个方法：
四个具有4个基本特征：过滤类型、执行顺序、执行条件、具体操作
filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：
pre：可以在请求被路由之前调用
routing：在路由请求时候被调用
post：在routing和error过滤器之后被调用
error：处理请求时发生错误时被调用
filterOrder：通过int值来定义过滤器的执行顺序
shouldFilter：返回一个boolean类型来判断该过滤器是否要执行，所以通过此函数可实现过滤器的开关。在上例中，我们直接返回true，所以该过滤器总是生效。
run：过滤器的具体逻辑。需要注意，这里我们通过ctx.setSendZuulResponse(false)令zuul过滤该请求，不对其进行路由，然后通过ctx.setResponseStatusCode(401)设置了其返回的错误码，当然我们也可以进一步优化我们的返回，比如，通过ctx.setResponseBody(body)对返回body内容进行编辑等。
最后，总结一下为什么服务网关是微服务架构的重要部分，是我们必须要去做的原因： 不仅仅实现了路由功能来屏蔽诸多服务细节，更实现了服务级别、均衡负载的路由。 实现了接口权限校验与微服务业务逻辑的解耦。通过服务网关中的过滤器，在各生命周期中去校验请求的内容，将原本在对外服务层做的校验前移，保证了微服务的无状态性，同时降低了微服务的测试难度，让服务本身更集中关注业务逻辑的处理。 实现了断路器，不会因为具体微服务的故障而导致服务网关的阻塞，依然可以对外服务。
Zuul 和 nginx的性能对比
结论： Zuul的原始性能非常接近于Nginx。事实上，在启动预热之后，我的测试结果甚至略好一些（重申免责声明-这并非一个严肃的基准性能测试）。Nginx显示出更多的可预测性能（变化较小），可悲的是在Zuul预热期间，我们经历了一些小故障（150000个请求中的2个，但是您的微服务应该是容错机制的，对吧？）。
Zuul处理Cookie和重定向
本文来源于：程序员ken，专属平台有csdn、思否(SegmentFault)、 简书、 开源中国(oschina)、掘金，转载请注明出处。
来源：oschina
链接：https://my.oschina.net/u/3649200/blog/4914687