spring-cloud + Zuul

本文关于 Zuul 的部分转自：
http://www.ityouknow.com/springcloud/2017/06/01/gateway-service-zuul.html
http://www.ityouknow.com/springcloud/2018/01/20/spring-cloud-zuul.html

什么是网关

参考：https://blog.csdn.net/zhaisharap/article/details/102719392
参考：https://blog.csdn.net/qiuzhongweiwei/article/details/80172529
要实现两个网络之间的通信，则必须通过网关。如果网络A中的主机发现数据包的目的主机不在本地网络中，就把数据包转发给它自己的网关，再由网关转发给网络B的网关，网络B的网关再转发给网络B的某个主机。

什么是 API 网关

转自：https://www.jianshu.com/p/7baab672b822

将所有API的调用统一接入API网关层，由网关层负责接入和输出。
网关可以拦截客户端所有请求，对该请求进行权限控制、负载均衡、日志管理、接口调用监控等

API 服务专注于自己的业务逻辑处理。
API 网关专注于安全、流量、路由等问题。

• 网关与代理的区别：
  代理是纯粹的数据透传，协议不会发生变化；
  网关在数据透传的背景下，还会设计协议的转换，比如上图中用户请求传输到网关的协议是 HTTP，通过网关透传到下游则可能已经转换成企业内部的 RPC 了。

• 网关与过滤器的区别：
  过滤器是拦截单个tomcat服务器请求。
  网关是拦截整个微服务所有请求。

基本功能：

API网关的架构示例

Zuul

在Spring Cloud体系中， Spring Cloud Zuul就是API gateway，提供

• 负载均衡
• 反向代理
• 权限认证

Spring Cloud Zuul路由是微服务架构的不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

demo

参考：
http://www.ityouknow.com/springcloud/2017/06/01/gateway-service-zuul.html
http://www.ityouknow.com/springcloud/2018/01/20/spring-cloud-zuul.html

Zuul filter

转自：http://www.ityouknow.com/springcloud/2018/01/20/spring-cloud-zuul.html

Filter是Zuul的核心，用来实现对外服务的控制。Filter的生命周期有4个，分别是“PRE”、“ROUTING”、“POST”、“ERROR”，整个生命周期可以用下图来表示。

Zuul大部分功能都是通过过滤器来实现的，这些过滤器类型对应于请求的典型生命周期。

• PRE：
  这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
• ROUTING：
  这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。
• POST：
  这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
• ERROR：
  在其他阶段发生错误时执行该过滤器。 除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。例如，我们可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。
• 其他：
  还可以自定义 Filter，参考：http://www.ityouknow.com/springcloud/2018/01/20/spring-cloud-zuul.html

Zuul 路由熔断

当我们的后端服务出现异常的时候，我们不希望将异常抛出给最外层，期望服务可以自动进行一降级。Zuul给我们提供了这样的支持。当某个服务出现异常时，直接返回我们预设的信息。

我们通过自定义的fallback方法，并且将其指定给某个route来实现该route访问出问题的熔断处理。主要继承ZuulFallbackProvider接口来实现，ZuulFallbackProvider默认有两个方法，一个用来指明熔断拦截哪个服务，一个定制返回内容。

Zuul 高可用

我们实际使用Zuul的方式如上图，不同的客户端使用不同的负载将请求分发到后端的Zuul，Zuul在通过Eureka调用后端服务，最后对外输出。因此为了保证Zuul的高可用性，前端可以同时启动多个Zuul实例进行负载，在Zuul的前端使用Nginx或者F5进行负载转发以达到高可用性。

Zuul 和 nginx 对比

相同点

• 能实现反向代理，隐藏真实服务器地址
• 能负载均衡（zuul使用的是ribbon实现负载均衡）
• 能过滤请求，实现网关效果

不同点

总结自网络。

	nginx	zuul
功能偏向	做负载均衡请求转发，更多被用作负载均衡器使用的	请求转发，一般用来做网关，zuul 配合 eureka 来使用。nginx 要做这些功能也是可以，但是需要各种脚本语言来支持，比如 lua
负载均衡	nginx 有多重算法，参考：https://blog.csdn.net/justsomebody126/article/details/104111787	采用 ribbon + eureka 实现本地负载均衡，适合微服务中实现网关
其他	功能会更加强大，因为Nginx整合一些脚本语言（Nginx+Lua）

nginx + zuul

以 nginx + zuul 实现网关

• nginx 作用实现反向代理
• zuul 对微服务实现网关拦截