这里说的是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和重定向