『互联网架构』软件架构-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)。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』软件架构-springcloud-zuul微服务网关(下)(102)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注