Guyuebingchuan 2017-08-29
zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。
Zuul 在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
zuul的例子可以参考 netflix 在github上的 simple webapp,可以按照netflix 在github wiki 上文档说明来进行使用。
zuul的核心是一系列的filters, 其作用可以类比Servlet框架的Filter,或者AOP。
zuul把Request route到 用户处理逻辑 的过程中,这些filter参与一些过滤处理,比如Authentication,Load Shedding等。
Zuul提供了一个框架,可以对过滤器进行动态的加载,编译,运行。
Zuul的过滤器之间没有直接的相互通信,他们之间通过一个RequestContext的静态类来进行数据传递的。RequestContext类中有ThreadLocal变量来记录每个Request所需要传递的数据。
Zuul的过滤器是由Groovy写成,这些过滤器文件被放在Zuul Server上的特定目录下面,Zuul会定期轮询这些目录,修改过的过滤器会动态的加载到Zuul Server中以便过滤请求使用。
下面有几种标准的过滤器类型:
Zuul大部分功能都是通过过滤器来实现的。Zuul中定义了四种标准过滤器类型,这些过滤器类型对应于请求的典型生命周期。
(1) PRE:这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
(2) ROUTING:这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求,并使用Apache HttpClient或Netfilx Ribbon请求微服务。
(3) POST:这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
(4) ERROR:在其他阶段发生错误时执行该过滤器。
内置的特殊过滤器
zuul还提供了一类特殊的过滤器,分别为:StaticResponseFilter和SurgicalDebugFilter
StaticResponseFilter:StaticResponseFilter允许从Zuul本身生成响应,而不是将请求转发到源。
SurgicalDebugFilter:SurgicalDebugFilter允许将特定请求路由到分隔的调试集群或主机。
自定义的过滤器
除了默认的过滤器类型,Zuul还允许我们创建自定义的过滤器类型。
例如,我们可以定制一种STATIC类型的过滤器,直接在Zuul中生成响应,而不将请求转发到后端的微服务。
Zuul请求的生命周期如图,该图详细描述了各种类型的过滤器的执行顺序。
Zuul可以通过加载动态过滤机制,从而实现以下各项功能:
除此之外,Netflix公司还利用Zuul的功能通过金丝雀版本实现精确路由与压力测试。
ZuulServlet
类似SpringMvc的DispatcherServlet
,所有的Request都要经过ZuulServlet
的处理
三个核心的方法preRoute()
,route()
, postRoute()
,zuul对request处理逻辑都在这三个方法里
ZuulServlet
交给ZuulRunner
去执行。
由于ZuulServlet
是单例,因此ZuulRunner
也仅有一个实例。
ZuulRunner
直接将执行逻辑交由FilterProcessor
处理,FilterProcessor
也是单例,其功能就是依据filterType执行filter的处理逻辑
FilterProcessor
对filter的处理逻辑。
List<ZuulFilter> list
。processZuulFilter(ZuulFilter filter)
RequestContext
对每个filter的执行状况进行记录,应该留意,此处的执行状态主要包括其执行时间、以及执行成功或者失败,如果执行失败则对异常封装后抛出。 ContextLifecycleFilter的核心功能是为了清除RequestContext; 请求上下文RequestContext通过ThreadLocal存储,需要在请求完成后删除该对象。
RequestContext
提供了执行filter Pipeline所需要的Context,因为Servlet是单例多线程,这就要求RequestContext即要线程安全又要Request安全。
context使用ThreadLocal
保存,这样每个worker线程都有一个与其绑定的RequestContext
,因为worker仅能同时处理一个Request,这就保证了Request Context 即是线程安全的由是Request安全的。
Filter源码文件放在zuul 服务特定的目录, zuul server会定期扫描目录下的文件的变化,动态的读取\编译\运行这些filter,
如果有Filter文件更新,源文件会被动态的读取,编译加载进入服务,接下来的Request处理就由这些新加入的filter处理。
http://www.cnblogs.com/lexiaofei/p/7080257.html
2、架构图zuul 像其他微服务一样作为一个微服务向eureka server注册,并且能够通过注册列表获取所有的可用服务,其内部默认实现了ribbon,可达到负载均衡的目的,此时的微服务架构图如下: