Spring Cloud Gateway VS Netflix Zuul2
最近公司要引入统一网关，自己也参与调研了几种，当在研究Netflix的Zuul2和SpringCloudGateway时被网络上杂七杂八的材料跟震惊了，不客气地说很多国内博客都是在误人子弟，充斥着那些基于SpringCloud全家桶号称自己使用的是zuul2的“专家”。所以下定决心用一个系列好好介绍下第二代NIO的两个网关：SpringCloudGateway和NetflixZuul2。
背景介绍
我们系统架构面临现状和痛点
1. 流量调度不灵活，完全依赖DNS
虽然后端服务已经实现了多云多活，但是每次做流量割接的时候都要从DNS层一个运营商一个运营商的一点点的做调度。我需要有个统一接入层，可以直接把一个云平台的所有流量直接调到另一个云平台上
2. 各IDC的LB组件不同，配置管理不统一
对接入层的配置，变成了对每个产品LB入口的配置，我们大约有近百个应用，而且每个应用又涉及到物理机房IDC、阿里云、腾讯云这样的差异性，而且每家云平台LB的设计和操作又千差万别，所以接入层的配置变成了臃肿而且学习成本很高的一件事情。
3. 突发流量导致雪崩，无限流
公司目前没有限流策略，今年春节后因为疫情原因大家都窝在家里，我们的爆款节目就引发了两次因流量洪峰导致的重大故障。虽然后端的服务已经具备了很出色的弹性能力，但是弹性毕竟需要时间，因为缺乏接入层限流的保护，很容易造成后端服务雪崩效应。
4. 无法干预路由策略，无法混沌工程
今年我们将会启动混沌工程，更需要一个优秀的网关来配合打标或自定义路由，而且要能很好地控制网关的生命周期，因为混沌工程执行是临时性的，混沌结束后需要恢复。
我期望中的统一网关应该具备的能力
1、七层转发：基于path、host、uid、其他自定义方式。
2、拦截策略：统一安全，request、response报文干预。
3、统一管理：统一的监控、日志、配置管理方案。
4、限流熔断：基于不同粒度的限流规则。
现状图
理想图
网关发展史
选择网关之前我们要先了解下netflix与spring的恩怨情仇
蜜月期
2013： Netflix推出以zuul1为代表开的源项目
2014： SpringBoot诞生，引入Netflix开源组件
2015： SpringCloud诞生，引入Netflix开源组件
2016： 发现Zuul1存在性能问题，Netflix官宣进行优化
争执期
2016-2017： Netflix跳票
2018-05： Netflix发布Zuul 2.x，Spring未引入
2018-06： Netflix宣告Eureka 2.0 开源工作停止
分手
2018-11： Netflix宣告Hystrix开源工作停止
2018-11： Spring推出新一代网关Gateway、一些列孵化项目
2018-12：Spring官方宣布Netflix的相关项目进入维护模式
2018-12:：Netflix 宣布 Spring 系列技术栈进入维护模式
SpringCloud因分手受影响的模块
spring-cloud-netflix-archaius
spring-cloud-netflix-hystrix-contract
spring-cloud-netflix-hystrix-dashboard
spring-cloud-netflix-hystrix-stream
spring-cloud-netflix-hystrix
spring-cloud-netflix-ribbon
spring-cloud-netflix-turbine-stream
spring-cloud-netflix-turbine
spring-cloud-netflix-zuul
总之一句话：爱过。
网关的发展经历了BIO和NIO时代
一代网关：BIO
实现方式
基于Thread方式，当I/O阻塞系统，但CPU空闲的时候，可以利用多线程使用CPU资源
性能
严重依赖于线程，线程的创建和销毁成本很高；
线程本身占用较大内存。
代表
SpringCloudZuul(Netflix-Zuul1)
二代网关：NIO
实现方式
基于Reactor方式，成熟框架（Netty、MINA）,当I/O阻塞系统，但CPU空闲的时候，可以利用多线程使用CPU资源。
性能
除了事件的轮询是阻塞的，剩余的都是纯CPU操作，单线程处理多任务；
由于线程的节约，高链接场景下线程切换带来的问题也随之解决；
I/O多路复用。
代表
SpringCloudGateway & Netflix-Zuul2
核心网关详解
Zuul2-架构
基于Filter的体系
Inbound
输入过滤器，在请求被代理之前执行。可用于：认证、路由、Ddos、指标统计等。
Endpoint
基于输入过滤器的执行情况处理请求，如：将请求代理到后端等。
Outbound
输出过滤器处理接收到后端服务返回后的操作；如：增删响应头信息、压缩等
Zuul2-动态过滤器
核心代码：ZuulFiltersModule，FilterFileManager，FilterLoader
核心配置：zuul.filters.classes，zuul.filters.packages，zuul.filters.locations
SpringCloudGateway
Gateway Handler Mapping
找到与请求相匹配的路由，将其发送到 Gateway Web Handler
Gateway Web Handler
通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑。
Filter
pre：Gateway转发请求之前
post：Gateway转发请求之后
网关对比与选型
网关对比
| 名称 |
Zuul1 |
Zuul2 |
Spring Cloud Gateway |
| Path注入 |
不自带，部分可实现 |
不自带，可以自己实现 |
自带 |
| host转发 |
不支持 |
不自带，可以自己实现 |
自带 |
| 动态代码 |
不支持 |
可动态通过代码修改filter |
不支持 |
| 动态配置 |
Archaius,Spring |
Netflix Archaius |
Spring（config+bus+actuator）或自开发 |
| 网关高可用 |
云平台的LB+弹性，Eureka |
云平台的LB+弹性，Eureka |
云平台的LB+弹性，Eureka |
| 服务发现 |
eureka |
eureka |
eureka，nacos |
| 功能扩展 |
只扩展过滤器 |
可创建路由规则，过滤规则 |
路由规则，过滤规则都可扩展 |
| 限流 |
信号量、线程数 |
内置限流统计，需要自己封装实现，集群可能需要自开发 |
引入redis计数，可细化到针对IP做限流，限流规则可自定义 |
| 熔断 |
Hystrix降级 |
需要基于内置的统计做封装 |
利用Hystrix |
| 实现方式 |
BIO |
NIO |
NIO |
技术选型
性能：
Gateway和Zuul2底层都是reactor模式，性能上比zuul1时代提高很多，所以zuul1不考虑。
开源：
Gateway社区更成熟，内置10种路由和20种过滤器，zuul2只有Netflix博客和github可获取相关资料，很多功能需要自己开发。
特性：
Zuul2基于groovy的filter代码动态更新是一大亮点，而且与混沌工程配合的天衣无缝，从Zuul2的设计思想来看就是要利用代码来替代配置。
语言：
Netflix是Java+Groovy体系，Spring是Java体系
总结： 倾向于Zuul2