zuul微服务网关
微服务网关背景nginx
不一样的微服务通常有不一样的网络地址，而外部的客户端可能须要调用多个服务的接口才能完成一个业务需求。好比一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。若是客户端直接和微服务进行通讯，会存在一下问题：
# 客户端会屡次请求不一样微服务，增长客户端的复杂性
# 存在跨域请求，在必定场景下处理相对复杂
# 认证复杂，每个服务都须要独立认证
# 难以重构，随着项目的迭代，可能须要从新划分微服务，若是客户端直接和微服务通讯，那么重构会难以实施
# 某些微服务可能使用了其余协议，直接访问有必定困难
web
微服务网关引入后端
上述问题，均可以借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层，全部的外部请求都会先通过微服务网关（可结合设计模式--外观模式），架构演变成：设计模式
这样客户端只须要和网关交互，而无需直接调用特定微服务的接口，并且方便监控，易于认证，减小客户端和各个微服务之间的交互次数跨域
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过滤器原理解析app
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的高可用
一、Zuul客户端也注册到了Eureka Server上(通常用在服务端与服务端之间的通讯)
这种状况下，Zuul的高可用很是简单，只需将多个Zuul节点注册到Eureka Server上，就可实现Zuul的高可用。此时，Zuul的高可用与其余微服务的高可用没什么区别。见下图
当Zuul客户端也注册到Eureka Server上时，只需部署多个Zuul节点便可实现其高可用。Zuul客户端会自动从Eureka Server中查询Zuul Server的列表，并使用Ribbon负载均衡地请求Zuul集群。
二、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/