zuul微服务网关
微服务网关背景
不同的微服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。如果客户端直接和微服务进行通信，会存在一下问题：
# 客户端会多次请求不同微服务，增加客户端的复杂性
# 存在跨域请求，在一定场景下处理相对复杂
# 认证复杂，每一个服务都需要独立认证
# 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施
# 某些微服务可能使用了其他协议，直接访问有一定困难
微服务网关引入
上述问题，都可以借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关（可结合设计模式--外观模式），架构演变成：
这样客户端只需要和网关交互，而无需直接调用特定微服务的接口，而且方便监控，易于认证，减少客户端和各个微服务之间的交互次数
API Gateway的优点和缺点
如你所料，采用API Gateway也是优缺点并存的。API Gateway的一个最大好处是封装应用内部结构。相比起来调用指定的服务，客户端直接跟gatway交互更简单点。API Gateway提供给每一个客户端一个特定API，这样减少了客户端与服务器端的通信次数，也简化了客户端代码。
API Gateway也有一些缺点。它是一个高可用的组件，必须要开发、部署和管理。还有一个问题，它可能成为开发的一个瓶颈。开发者必须更新API Gateway来提供新服务提供点来支持新暴露的微服务。更新API Gateway时必须越轻量级越好。否则，开发者将因为更新Gateway而排队列。但是，除了这些缺点，对于大部分的应用，采用API Gateway的方式都是有效的。
zuul微服务网关
Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：
# 动态路由：动态将请求路由到不同后端集群
# 压力测试：逐渐增加指向集群的流量，以了解性能
# 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
# 静态响应处理：边缘位置进行响应，避免转发到内部集群
# 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求。Spring Cloud对Zuul进行了整合和增强。目前，Zuul使用的默认是Apache的HTTPClient，也可以使用Rest Client，可以设置ribbon.restclient.enabled=true.
使用规则：
访问 http://GATEWAY:GATEWAY_PORT/想要访问的Eureka服务id的小写/** 将会路由到http://想要访问的Eureka服务id的小写:该服务端口/**
zuul过滤器原理解析
zuul请求的生命周期如下图
过滤器(filter)是zuul的核心组件
zuul大部分功能都是通过过滤器来实现的。 zuul中定义了4种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。
- PRE：这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
- ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用 Apache HttpCIient或 Netfilx Ribbon请求微服务
- POST:这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
- ERROR：在其他阶段发生错误时执行该过滤器
zuul的容错与回退
大家可以想一下如果zuul代理的后端微服务挂了会出现什么情况？zuul默认已经整合了hystrix，也就是zuul也是可以利用hystrix做降级容错处理的，但是zuul监控的粒度是微服务级别，而不是某个API。
zuul的高可用
分两种场景讨论Zuul的高可用
1、Zuul客户端也注册到了Eureka Server上(一般用在服务端与服务端之间的通信)
这种情况下，Zuul的高可用非常简单，只需将多个Zuul节点注册到Eureka Server上，就可实现Zuul的高可用。此时，Zuul的高可用与其他微服务的高可用没什么区别。见下图
当Zuul客户端也注册到Eureka Server上时，只需部署多个Zuul节点即可实现其高可用。Zuul客户端会自动从Eureka Server中查询Zuul Server的列表，并使用Ribbon负载均衡地请求Zuul集群。
2、Zuul客户端未注册到Eureka Server上(一般用在客户端（app,web等终端）与服务端之间的通信)
现实中，这种场景往往更常见，例如，Zuul客户端是一个手机APP——我们不可能让所有的手机终端都注册到Eureka Server上。这种情况下，我们可借助一个额外的负载均衡器来实现Zuul的高可用，例如Nginx+keepalived.
Zuul客户端将请求发送到负载均衡器，负载均衡器将请求转发到其代理的其中一个Zuul节点。这样，就可以实现Zuul的高可用
总结：通常在一个大型应用中，两种策略都会使用，客服端通过nginx路由到Zuul服务，Zuul服务路由到具体的一个微服务如门户微服务，然后该门户微服务通过Zuul集群请求其他微服务
参考资料：
1.微服务实战（二）：使用API Gatewayhttp://dockone.io/article/482
2.使用Spring Cloud与Docker实战微服务http://book.itmuch.com/