Spring Cloud GateWay 入门

概述

SpringCloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用Zuul网关；

但是2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，那就是Springcloud Gateway一句话： Gateway是原Zuul1.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 链的方式提供网关的基本功能，例如：安全，监控/指标，和限流。

源码架构

image-20200521185213599

作用

反向代理
鉴权
流量控制
熔断
日志监控
.............

微服务架构中网关的位置

image-20200521190141313

我们为什么选择GateWay

一方面zuul 1.0 已经进入了维护阶段，而且GateWay 是spring cloud 团队研发的，值得信赖。而且很多功能Zuul d都没用起来也非常的简单便捷。
GateWay 是基于异步非阻塞模型上进行开发的，性能方面都不需要担心，虽然 Netflix
早就发布去了最新的 Zuul 2.x 但是 Spring Cloud 貌似没有整合计划。而且Netflix 相关组件都宣布进行维护期；不知前景如何？
多方考虑Gateway 是很理想的网关选择

Spring Cloud Gateway 具有如下特征：

基于 Spring Framework5 . Project Reactor 和Spring Boot 2.0 进行构建。
动态路由：能够匹配任何请求属性；
可以路由指定 Predicate (断言) 和 Filter （过滤器）
集成 Hystrix 的断路器功能；
集成 Spring Cloud 服务发现功能
抑郁编写Predicate (断言) 和 Filter (过滤器)
请求限流共恩感
支持路径重写。

Gatway 和 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 紧密集成拥有更好的开发体验。

Zuul1.x的模型

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 模型的弊端。

Gateway模型

传统的Web框架，比如说：struts2，springmvc等都是基于Servlet API与Servlet容器之上运行的。
但是在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型的非阻塞异步框架，它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty，Undertow及支持Servlet3.1的容器上。非阻塞+函数式编程（Spring5必须使用java8）。

Spring WebFlux是Spring 5.0引入的新的响应式框架，区别于SpringMVC，它不需要依赖Servlet API，它是完全异步非阻塞的，并且基于Reactor来实现响应式流规范。

服务网关

GetWay

GetWay是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot 2和Project Reactor等技术。
Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如：熔断、限流、重试等

三大核心概念

路由： 路由是构建网关的基本模块，它由ID，目标URL，一系列的断言和过滤器组成，如果断言为true则匹配该路由

断言：参考的是Java8的java.util.funcation.Predicate，开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由

过滤：指的是Spring框架中GateWayFilter的实例，使用过滤器，可以在请求被路由前或者之后队请求进行修改

20200318202547900

总体

Web请求，通过一些匹配条件，定位到真正的服务节点，并在这个转发过程前后，进行一些精细化控制。
Predicate就是我们的匹配条件；
而filter，就可以理解为一个无所不能的拦截器，有了这两个元素，再加上目标URL，就可以实现一个具体的路由了。

工作流程

20200318211144699

客户端向Spring Cloud Gateway发出请求。然后在GateWay Handler Mapping中找到与请求相匹配的路由，将其发送到GateWay Web Handler。

Handler再通过制定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（"pre")或之后（"post")执行业务逻辑。

Filter在‘pre'类型的过滤器可以做参数校验、流浪监控、日志输出、协议转换等，
在’post‘类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。

订阅号：JavaGym 写技术、聊健身、谈社会、说人生，这个世界值得研究。欢迎关注!
本文由博客群发一文多发等运营工具平台 OpenWrite 发布