官方地址 : https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.2.RELEASE/reference/html/
简介
Cloud 全家桶
中很重要的一个组件就是网关
,在 1.x 版本中都是采用 Zuul 网关,
但是在 2.x 版本中,zuul 升级一种跳票,SpringCloud 最后自己研发了一个网关替代Zuul, 那就是 SpringCloud GateWay 换句话说 gateway 就是原 zuul 1.x 版本的替代方案
SpringCloud GateWay 是 Spring Cloud 的一个全新的项目, 基于
Spring 5.0 + Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构通过一种简单有效
的统一的API 路由管理方式
Spring Cloud GateWay 作为 Spring Cloud 生态系统的网关, 目标是替代 Zuul , 在Spring Cloud2.0 以上版本种,没有对新版本的 Zuul 2.0 以上版本最高性能版本进行集成,仍然还是使用的 Zuul 1.x 非 Reactor 模式的老版本,为了提升网关性能, Spring Cloud GateWay 基于 WebFlux
框架实现的,而WebFlux 框架底层则使用了高性能的Reactor 模式通讯框架 Netty
Spring Cloud GateWay 的目标是提供统一的路由方式且基于Filter 链的方式提供网关的基本功能,例如:安全
,监控/指标
和 限流
。
网关在架构中的位置
网关是在微服务访问
的入口
,对外是负载均衡 Nginx
zuul 和 gateway
1、为什选择 gateway
- netflix 不靠谱,zuul2.0 一直跳票,迟迟不发布
-
一方面zuul 1.0 已经进入了维护阶段,而且GateWay 是spring cloud 团队研发的,值得信赖。 而且很多功能Zuul 都没用起来也非常的简单便捷。
-
GateWay 是基于异步非阻塞模型上进行开发的, 性能方面都不需要担心,虽然 Netflix
早就发布去了最新的 Zuul 2.x 但是 Spring Cloud 没有整合计划。 而且Netflix 相关组件都宣布进行维护期;不知前景如何? -
多方考虑Gateway 是很理想的网关选择
-
- springcloud gateway 具有如下特征
- 基于 Spring Framework5 . Project Reactor 和Spring Boot 2.0 进行构建。
- 动态路由:能够匹配任何请求属性;
- 可以路由指定 Predicate (断言) 和 Filter (过滤器)
- 集成 Hystrix 的断路器功能;
- 集成 Spring Cloud 服务发现功能
- 抑郁编写Predicate (断言) 和 Filter (过滤器)
- 请求限流共恩感
- 支持路径重写。
- springcloud gateway 和 zuul 的区别
- 在SpringCloud Finchley 正式版之前, Spring Cloud 推荐的网关是 Netflix 提供的 Zuul
- Zuul 1.x 是基于
阻塞 I/0
的 API Gateway - Zuul 1.x 基于 Servlet 2.5 使用阻塞架构他不支持任何常链接(如 WebSocket ) Zuul 的涉及模式和 Niginx 很像, 每次 I / 0 操作都是从工作线程种选择一个执行,请求线程被阻塞到工作线程完成,但是差别是 Nginx 使用的是 C++ 实现,Zuul 使用的是Java 实现,而JVM 本身会有第一次加载比较慢的情况,使得 Zuul 的性能相对较差
- Zuul2.x 理想更为陷阱,想基于Netty 非阻塞和支持常谅解, 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。在性能方面,根据官方提供的基准测试, Spring Cloud Gateway 的 RPS(每秒请求数)是Zuul 的 1.6 倍
- Spring Cloud Gateway 建立在
Spring Framework5、 Project Reactor 和Spring Boot 2之上,使用非阻塞 API
。 - Spring Cloud Gateway 还支持
websocket
, 并且与 Spring 紧密集成拥有更好的开发体验。
2、zuul1.0 模型
Springcloud 中集成的Zuul 版本, 采用的是 Tomcat 容器,使用的是 传统的 Servlet IO 处理模型。
servlet 由 servlet container 进行生命周期管理。
- container 启动时,构造 servlet 对象并调用 servlet init() 进行初始化;
- container 运行时接受请求,并为每一个请求分配一个线程(一般从线程池中获取空闲线程,)然后调用service()
- container 关闭时调用 servlet destory ()销毁 servlet
上述模型的缺点:
servlet 是一个简单的网络 I/O 模型,当前请求进入servlet container 时,servlet container 就会为其绑定一个线程, 在并发不高的场景下,这种模型适用的。但是一旦在高并发(比如用jmeter压测), 线程数量就会上涨, 而线程资源代价时昂贵的(上下文切换,内存消耗大)严重影响请求的处理时间。在一些简单业务场景下, 不希望为每个 request分配一个线程,只需要1个或这几个线程就能应对极大的并发请求。这种场景下servlet 模型没有优势。
所以 zuul1.x 时基于 servelt 开发的一个阻塞式处理模型,即 spring 实现了, 处理并发request 请求的 servlet (DispatcherServlet ) 并由该 servlet 阻塞式处理。所以 ,springcloud zuul 无法摆脱 servlet 模型的弊端。
3、gateway 模型
传统 Web 框架, 比如说: struts2 , spring mvc 等都是基于 Servlet API 与 Servlet 容器之上运行的。
- 在Servlet3.1 之后有了异步非阻塞的支持。 而WebFlux 是一个典型的非阻塞的异步的框架,它的核心是基于 Reactor 的相关 API 实现的 , 相对于传统的Web 框架来说,他可以运行在诸如 Netty ,Undertow 支持 Servlet 3.1 的容器上。 非阻塞+ 函数式编程 (Spring 5 必须让你使用 java8)
- Spring WebFlux 是Spring 5.0 引入的新的响应式框架,区别于 Spring MVC, 它不需要依赖 Servlet API, 它完全是异步非阻塞的, 并且基于 Reactor 来实现响应式流规范。
三大核心概念
Route(路由)
构建网关的基本模块,由id,目标URL,一系列的的断言和过滤组成,如果断言为true则匹配该路由
Predicate(断言)
参考 Java8 的 java.util.funcation.Predicate 开发人员可以指定HTTP 请求中的所有内容(例如请求头或请求参数),如果请求与断言适配类则进行路由
Filter(过滤)
spring框架中GatewayFilter实例,使用过滤器,可以在请求被路由前或后对请求进行修改