共计 986 个字符，预计需要花费 3 分钟才能阅读完成。
这里说的是 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)、掘金，转载请注明出处。
