本文目录一览：
- 1、SpringCloud Zuul路由转发原理及源码解析
- 2、2-zuul转发websocket的坑
- 3、SpringCloud整体构架设计（一）
- 4、微服务核心组件 Zuul 网关原理剖析
- 5、23 nginx 和zuul 的区别
- 6、Spring Cloud——微服务网关介绍
SpringCloud Zuul路由转发原理及源码解析
server.port=8081
spring.application.name=first-service
eureka.instance.instance-id=${spring.application.name}:${random.int}
eureka.client.serviceUrl.defaultZone=
如图：
server.port=5555
spring.application.name=api-gateway
eureka.instance.instance-id=${spring.application.name}:${random.int}
eureka.client.serviceUrl.defaultZone=
# 表示eureka client发送心跳给server端的频率。如果在leaseExpirationDurationInSeconds后，server端没有收到client的心跳，则将摘除该instance。缺省=30-zuul代理下载文件
eureka.instance.lease-renewal-interval-in-seconds=30
# 表示eureka server至上一次收到client的心跳之后，等待下一次心跳的超时时间，在这个leaseExpirationDurationInSeconds时间内若没收到下一次心跳，则将移除该instance，缺省=90-zuul代理下载文件
eureka.instance.lease-expiration-duration-in-seconds=90
zuul.routes.api-a-url.path=/api-a/**
zuul.routes.api-a-url.service-id=first-service
zuul.routes.api-b-url.path=/api-b/**
zuul.routes.api-b-url.service-id=feign-consumer
如图：
@SpringBootApplication
@EnableZuulProxy // 启用Zuul代理
如图：
加载zuul routes配置：
加载后属性为LinkedHashMap结构，处理缺省属性，ZuulRoute为ZuulProperties内部类
Zuul代理类加载：
初始化路由转发过滤器RibbonRoutingFilter：
构造RibbonRoutingFilter：
显示配置已加载：
访问地址：localhost:5555/api-a/index
进入过滤顺序为10的RibbonRoutingFilter：
判断是否执行过滤器（依赖com.netflix.zuul.context.RequestContext）：
执行过滤器，先构造RibbonCommandContext上下文：
构造请求头，请求参数，负载等：
RibbonCommand执行转发：
吧啦吧啦到达服务返回结果，catch异常。。。先到这
2-zuul转发websocket的坑
原文地址：
之前的项目中，使用zuul网关统一过滤域名，为了管理方便，想要尝试看看能不能使用zuul管理websocket连接。
高版本的websocket在第一次http请求后，使用的是更快速的tcp连接
zuul网关只能管理http请求，并且不支持tcp以及udp请求
zuul转发websocket时，会将websocket降级为http请求转发掉（轮询的方式），换句话说就是不支持转发长连接，zuul2好像可以，详细情况看下面提供的链接
最好是不要通过zuul来管理websocket连接，降级为轮询后，效率会降低很多。
因为打算把服务器的websocket功能转接到我的这个zuul代理服务器来做，所以就不再研究怎么转发websocket了。
因为考虑到一个问题，那就是灰度发布的时候，需要将全部请求转发到灰度版的服务器作为现在的主服务器，那么原服务器的那些websocket长连接怎么办？肯定断了啊，那怎么继续在现在的服务器上保持？就是因为这一点所以才把websocket功能放到代理服务器实现的。-zuul代理下载文件
也不知道其他公司都是怎么做的，怎么解决我说的问题，望告知！感谢！
我现在把websocket功能放到代理服务器来做，万一以后业务要增加websocket功能，那岂不是得停服更新代理服务器，可是目的就是不停服啊
SpringCloud整体构架设计（一）
SpringClound整体核心架构只有一点：Rest服务，也就是说在整个SpringCloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个SpringCloud基础的结构就如下所示：-zuul代理下载文件
既然SpringCloud的核心是Restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。
1、所有的微服务地址一定会非常的多，所以为了统一管理这些地址信息，也为了可以及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且该注册中心应该支持有HA机制，为了高速并且方便进行所有服务的注册操作，在SpringCloud里面提供有一个Eureka的注册中心。-zuul代理下载文件
对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。-zuul代理下载文件
在进行客户端使用Rest架构调用的时候，往往都需要一个调用地址，即使现在使用了Eureka作为注册中心，那么它也需要有一个明确的调用地址，可是所有的操作如果都利用调用地址的方式来处理，程序的开发者最方便应用的工具是接口，所以现在就希望可以将所有的Rest服务的内容以接口的方式出现调用，所以它又提供了一个Feign技术，利用此技术可以伪造接口实现。-zuul代理下载文件
在进行整体的微架构设计的时候由于牵扯的问题还是属于RPC，所以必须考虑熔断处理机制，实际上所有的熔断就好比生活之中使用保险丝一样，有了保险丝在一些设备出现了故障之后依然可以保护家庭的电器可以正常使用，如果说现在有若干的微服务，并且这些微服务之间可以相互调用，例如A微服务调用了B微服务，B微服务调用了C微服务。-zuul代理下载文件
如果在实际的项目设计过程之中没有处理好熔断机制，那么就会产生雪崩效应，所以为了防止这样的问题出现，SpringCloud里面提供有一个Hystrix熔断处理机制，以保证某一个微服务即使出现了问题之后依然可以正常使用。-zuul代理下载文件
通过Zuul的代理用户只需要知道指定的路由的路径就可以访问指定的微服务的信息，这样更好的提现了java中的“key=value”的设计思想，而且所有的微服务通过zuul进行代理之后也更加合理的进行名称隐藏。-zuul代理下载文件
在SpringBoot学习的时候一直强调过一个问题：在SpringBoot里面强调的是一个“零配置”的概念，本质在于不需要配置任何的配置文件，但是事实上这一点并没有完全的实现，因为在整个在整体的实际里面，依然会提供有application.yml配置文件，那么如果在微服务的创建之中，那么一定会有成百上千个微服务的信息出现，于是这些配置文件的管理就成为了问题。例如：现在你突然有一天你的主机要进行机房的变更，所有的服务的IP地址都可能发生改变，这样对于程序的维护是非常不方便的，为了解决这样的问题，在SpringCloud设计的时候提供有一个SpringCloudConfig的程序组件，利用这个组件就可以直接基于GIT或者SVN来进行配置文件的管理。-zuul代理下载文件
在整体设计上SpringCloud更好的实现了RPC的架构设计，而且使用Rest作为通讯的基础，这一点是他的成功之处，由于大量的使用了netflix公司的产品技术，所以这些技术也有可靠的保证。
微服务核心组件 Zuul 网关原理剖析
Zuul 网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能。在分布式的微服务系统中，系统被拆为了多套系统，通过zuul网关来对用户的请求进行路由，转发到具体的后台服务系统中。-zuul代理下载文件
本 Chat 主要内容如下：
网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能，下面我们从单体应用到多体应用的演化过程来讲解网关的演化历程。
一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。对应单体应用架构模式（如下图1），由于只需一个应用，所有业务模块的功能都打包为了一个 War 包进行部署，这样可以减少机器资源和部署的繁琐。-zuul代理下载文件
图1 单体应用
在单体应用中，网关模块是和应用部署到同一个jvm进程里面的，当外部移动设备或者web站点访问单体应用的功能时候，请求是先被应用的网关模块拦截的，网关模块对请求进行鉴权、限流等动作后在把具体的请求转发到当前应用对应的模块进行处理。-zuul代理下载文件
随着业务的发展，网站的流量会越来越大，在单体应用中简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响，这时候多体的分布式系统就出现了，如下图2。-zuul代理下载文件
图2 多体应用
如上图在多体应用中业务模块A和B单独起了个应用，每个应用里面有自己的网关模块，如果业务模块多了，那么每个应用都有自己的网关模块，这样复用性不好，所以可以考虑把网关模块提起出来，单独作为一个应用来做服务路由，如下图3：-zuul代理下载文件
如上图当移动设备发起请求时候是具体发送到网关应用的，经过鉴权后请求会被转发到具体的后端服务应用上，对应前端移动设备来说他们不在乎也不知道后端服务器应用是一个还是多个，他们只能感知到网关应用的存在。
Zuul是Netflix开源的一个网关组件，在Netflix内部系统中Zuul被用来作为内部系统的门面，如下图是Zuul在Netflix内部使用的一个架构图：
如上图最上层的移动设备或者网站首先通过aws负载均衡器把请求路由到zuul网关上，zuul网关则负责把请求路由到具体的后端service上。
Zuul开源地址
Zuul网关的核心是一系列的过滤器，这些过滤器可以对请求或者响应结果做一系列过滤，Zuul 提供了一个框架可以支持动态加载，编译，运行这些过滤器，这些过滤器是使用责任链方式顺序对请求或者响应结果进行处理的，这些过滤器直接不会直接进行通信，但是通过责任链传递的RequestContext参数可以共享一些东西。-zuul代理下载文件
虽然Zuul 支持任何可以在jvm上跑的语言，但是目前zuul的过滤器只能使用Groovy脚本来编写。编写好的过滤器脚本一般放在zuul服务器的固定目录，zuul服务器会开启一个线程定时去轮询被修改或者新增的过滤器，然后动态进行编译，加载到内存，然后等后续有请求进来，新增或者修改后的过滤器就会生效了。-zuul代理下载文件
在zuul中过滤器分为四种：
如下图为zuul1.0的工作原理：
如上图，当zuul接受到请求后，首先会由前置过滤器进行处理，然后在由路由过滤器具体把请求转发到后端应用，然后在执行后置过滤器把执行结果写会到请求方，当上面任何一个类型过滤器执行出错时候执行该过滤器。-zuul代理下载文件
本节作者使用zuul的版本：
...
....
总结：zuul1.0时候当zuul接受到一个请求后会同步执行前置过滤器、路由过滤器、后置过滤器，等执行完毕后在同步把结果返回为调用方，调用方在整个过程中是阻塞的。其实SpringBoot集成的zuul就是自己实现了个前置过滤器做选择路由，然后自己实现了个路由过滤器根据前置过滤器选择的路由具体做路由转发。-zuul代理下载文件
Netty作为高性能异步网络通讯框架，在dubbo，rocketmq,sofa等知名开源框架中都有使用，如下图zuul2.0使用netty server作为网关监听服务器监听客户端发来的请求，然后把请求转发到前置过滤器（inbound filters）进行处理，处理完毕后在把请求使用netty client代理到具体的后端服务器进行处理，处理完毕后在把结果交给后者过滤器（outbound filters）进行处理，然后把处理结果通过nettyServer写回客户端。-zuul代理下载文件
...
总: 在zuul1.0时候客户端发起的请求后需要同步等待zuul网关返回，zuul网关这边对每个请求会分派一个线程来进行处理，这会导致并发请求数量有限。而zuul2.0使用netty作为异步通讯，可以大大加大并发请求量。-zuul代理下载文件
23 nginx 和zuul 的区别
Nginx 与Zuul的区别；
相同点：
Zuul和nginx 都可以实现负载均衡。反向代理，过滤请求，实现网关效果；
不同点：
Nginx 采用C 语言编写；
Zuul采用java 语言编写：
ZUul 负载均衡的实现： 采用ribbon+eureka实现本地负载均衡；
Nginx 负载均衡实现： 采用服务器端实现负载均衡。
Nginx比zuul 功能会强大点因为nginx可以整合一些脚本语言（nginx+lua）
nginx适合于服务器端负载均衡，也可以实现网关
ZUUL适合微服务中实现网关，而且使用技术是java 语言
最好建议nginx+zuul实现网关
nginx作用实现反向代理
Zuul 对微服务实现网关拦截
Spring Cloud——微服务网关介绍
为了解决以上的问题，API网关应运而生，加入网关后应用架构变为下图所示。
当引入API网关后，在用户端与微服务之间建立了一道屏障，通过API网关对微服务提供了统一的访问入口，所有用户端的请求被API网关拦截，并在此基础上可以实现额外的功能：
OpenResty是一个强大的Web应用服务器，web开发人员可以使用Lua脚本语言调用Nginx支持的各种以C以及Lua模块。
在性能方面，OpenResty可以快速构造出足以胜任10K以上并发连接响应的超高性能Web应用系统。
在国内，360、阿里云、腾讯网、去哪儿、酷狗音乐、新浪等都是OpenResty的深度用户。
但OpenResty是一款独立的产品，与主流的注册中心，存在一定的兼容问题，需要架构师独立实现其服务注册、发现功能。
Zuul是Netflix开源的微服务网关，主要职责是对用户请求进行路由转发与过滤。早期Spring Cloud与Netflix合作，使用Zuul作为微服务架构网关首选产品。
Zuul是基于J2EE Servlet实现路由转发，网络通信采用同步方式。
zuul 是netflix开源的一个API Gateway 服务器，本质上是一个web servlet应用。
Zuul可以通过加载动态过滤机制，从而实现以下各项功能：
Zuul的核心是一系列的filters，其作用可以类比Servlet框架的Filter，或者AOP。工作原理如下图所示：
Zuul可以对Groovy过滤器进行动态的加载，编译，运行。
Zuul2.x设计更为先进，基于Netty 非阻塞和支持长连接， 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。
Zuul2.x引入了Netty和RxJava，正如之前的 ZuulFilter 分为了 Pre、Post、Route、Error，Zuul2的Filter分为三种类型：
Spring 自己开发的新一代API网关产品，基于NIO异步处理，摒弃了Zuul基于Servlet同步通信的设计。
Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。-zuul代理下载文件
关键特征：
在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1.6 倍。
Spring Cloud Gateway十分优秀，Spring Cloud Alibaba也默认选用该组件作为网关产品。
客户端向 Spring Cloud Gateway 发出请求。如果 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。-zuul代理下载文件
Spring Cloud Gateway 的特征：
参考：
