『互联网架构』软件架构-springcloud-zuul微服务网关（下）（102）

原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『互联网架构』软件架构-springcloud-zuul微服务网关（下）（102）

任何成熟的架构都是有生命周期的，zuul也是这样。一起了解下。
源码：https://github.com/limingios/netFuture/tree/master/源码/『互联网架构』软件架构-zuul微服务网关（下）（102）/

（一）zuul请求的生命周期

• 流程

1. 客户端HTTP发来一个请求。
2. spring框架经常使用会提到拦截器，过滤器，zuul也是如此，定制化微服务。
3. 通过前置过滤器"pre fiters" ，"routing fiters"访问后端的微服务，"post fiters"返回给客户端

（二）zuul过滤器使用及详解

过滤器(filter)是zuul的核心组件zuul大部分功能都是通过过滤器来实现的。 zuul中定义了4种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。

• PRE

这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

• ROUTING

这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用 Apache HttpCIient或 Netfilx Ribbon请求微服务。

• POST

这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

• ERROR

在其他阶段发生错误时执行该过滤器。

• 源码

08-ms-gateway-zuul-filter
由代码可知，自定义的 zuul Filter需实现以下几个方法。

• filterType

返回过滤器的类型。有 pre、 route、 post、 error等几种取值，分别对应上文的几种过滤器。详细可以参考 com.netflix.zuul.ZuulFilter.filterType()中的注释。

• filter0rder

返回一个 int值来指定过滤器的执行顺序，不同的过滤器允许返回相同的数字。

• shouldFilter

返回一个 boolean值来判断该过滤器是否要执行， true表示执行， false表示不执行。

• run

过滤器的具体逻辑。本例中让它打印了请求的 HTTP方法以及请求的地址。

• 代码示例

1.08-ms-provider-user
2.08-ms-gateway-zuul-filter
3.08-ms-eureka-server
4.08-ms-consumer-order-ribbon

直接源码运行就可以了，上几次文章都演示了，这次不演示了。直接main方法运行起来就可以了。

运行项目访问地址：http://localhost:8040/microservice-provider-user/getIpAndPort 可以看到zuul服务的后台正常打印了run方法里的日志。

• 禁用zuul过滤器

Spring Cloud默认为Zuul编写并启用了一些过滤器，例如DebugFilter、
FormBodyWrapperFilter等，这些过滤器都存放在spring-cloud-netflix-core这个jar包里，一些场景下，想要禁用掉部分过滤器，该怎么办呢？

只需在application.yml里设置
zuul...disable=true

例如，要禁用上面我们写的过滤器，这样配置就行了：
zuul.PreRequestLogFilter.pre.disable=true

• zuul的容错与回退

老铁！如果zuul代理的后端微服务挂了会出现什么情况？zuul默认已经整合了hystrix，也就是zuul也是可以利用hystrix做降级容错处理的，但是zuul监控的粒度是微服务级别，而不是某个API。

源码：08-ms-gateway-zuul-fallback
编写zuul的降级回退类如下

启动项目
1.08-ms-gateway-zuul-fallback
2.08-ms-eureka-server
3.08-ms-consumer-order-ribbon
注意：这里不启动记住不启动 08-ms-provider-user

关闭zuul代理的用户微服务，再运行本项目，访问地址：http://localhost:8040/microservice-provider-user/getIpAndPort，将会返回如下内容

（三）zuul的高可用

分两种场景讨论zuul的高可用

• zuul客户端也注册到了Eureka Server上

这种情况下，Zuul的高可用非常简单，只需将多个Zuul节点注册到Eureka Server上，就可实现Zuul的高可用。此时，Zuul的高可用与其他微服务的高可用没什么区别。

当zuul客户端也注册到Eureka Server上时，只需部署多个Zuul节点即可实现其高可用。zuul客户端会自动从Eureka Server中查询zuul Server的列表，并使用Ribbon负载均衡地请求Zuul集群。

• zuul客户端未注册到Eureka Server上

现实中，这种场景往往更常见，例如，zuul客户端是一个手机APP——我们不可能让所有的手机终端都注册到Eureka Server上。这种情况下，我们可借助一个额外的负载均衡器来实现Zuul的高可用，例如Nginx、HAProxy、F5等。

zuul客户端将请求发送到负载均衡器，负载均衡器将请求转发到其代理的其中一个zuul节点。这样，就可以实现Zuul的高可用。

PS：zuul 作为网关这么重要的角色，高可用是非常有必要的。但是通常来说网关所面对的请求应该的是来于外部，所以虽然说网关可以注册到Eureka Server上，但是外部的客户端数量众多，是不可能向Eureka Server注册的。那么要实现高可用的，要么在网关前面再架一个前置代理（如Nginx）。