Gateway新一代网关（一）理论+实操+项目源码

最新推荐文章于 2024-06-06 22:32:20 发布

置顶西柚仔

最新推荐文章于 2024-06-06 22:32:20 发布

阅读量618

点赞数 1

分类专栏：微服务教程文章标签：网关过滤器 spring gateway java

本文链接：https://blog.csdn.net/weixin_45921762/article/details/106948723

版权

微服务教程专栏收录该内容

2 篇文章 1 订阅

订阅专栏

Gateway新一代网关（一）理论+实操+项目源码

前言

大家好！我是西柚仔！这篇文章是第一次写博客，2019年11月，我和几个大学同学共同创建了奥利奥团队，为了更好地走下去，我们整个团队开始一起写博客，一来可以当作笔记，二来可以把团队的知识和经验分享出去，团队成员发布之后会由团队号统一转载，也希望大家可以关注我们，支持我们！

团队CSDN链接：https://me.csdn.net/m0_48822519

团队码云链接：https://gitee.com/oreo_team

Gateway的诞生

做过微服务的朋友都知道，初学的时候我们用的Zuul（https://github.com/Netflix/zuul/wiki）网关，Zuul 1.0已经进入了维护阶段，但Zuul在升级为2.x的时候，核心程序员跳槽，高层神仙打架，2.x版本一直迟迟不能完善，Spring Cloud也就没有整合的计划了。

Spring Cloud等不及了，最后自己研发了一套网关代替Zuul，那就是SpringCloud Gateway（https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.3.RELEASE/reference/html/），Gateway是基于异步非阻塞模型，性能优越。

Gateway的简介

这是我在官网截下来的图，官方的解释是：该项目提供了一个在Spring生态系统之上构建的API网关，包括：Spring 5，Spring Boot 2和Project Reactor。Spring Cloud Gateway旨在提供一种简单而有效的方法来路由到API，并为它们提供跨领域的关注，例如：安全性，监视/指标和弹性。

Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标就是要替代Zuul，在Spring Cloud 2.0以上的版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍然使用Zuul 1.x的非Reactor模式（老版本），目的是为了提高网关的性能。Spring Cloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用的是高性能的Reactor模式通信框架的Netty。

在这里顺便介绍一下什么是WebFlux（https://docs.spring.io/spring/docs/5.2.7.RELEASE/spring-framework-reference/web-reactive.html#spring-webflux）

官方解释：Spring框架中包含的原始Web框架Spring Web MVC是专门为Servlet API和Servlet容器而构建的。反应性堆栈Web框架Spring WebFlux在更高版本5.0中添加。它是完全无阻塞的，支持 Reactive Streams背压，并在Netty，Undertow和Servlet 3.1+容器等服务器上运行。

这两个Web框架都反映了其源模块的名称（spring-webmvc和 spring-webflux），并在Spring Framework中并存。每个模块都是可选的。应用程序可以使用一个模块，也可以使用两个模块，在某些情况下，也可以使用两个模块，例如，带有react的Spring MVC控制器WebClient。

总结：传统的Web框架，比如struts2和Spring MVC等都是基于Servlet API和Servlet容器基础上运行的。在Servlet 3.1之后有了异步非阻塞的支持，而WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的，相对于传统Web框架来说，它可以运行在Netty、Undertow及支持Servlet 3.1的容器上。注意：非阻塞+函数式编程，Spring 5 要求的是Java 8。

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

一句话总结：Spring Cloud Gateway使用的是Webflux中的reactor-netty响应式组件，底层使用了Netty通讯框架。以下是我部署的项目，导入依赖后看到的结构，后面也会把源码放在码云，然后给链接给你们。

Gateway和Zuul的区别

在Spring Cloud Finchley正式版发布之前，Spring Cloud推荐的网关是Netflix提供的Zuul。

Zuul 1.0

是一个基于阻塞I/0的API Gateway，我们知道阻塞I/0是很慢的。
基于Servlet 2.5使用架构它不支持任何长连接（如WebSocket），Zuul的设计模式很像Nginx,每次I/0操作都是从工作空间线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx是用C++编写的，Zuul则采用Java语言，而JVM本身在第一次加载的时候就会较慢，从而使得Zuul的性能相对较差。

Zuul 2.0

Zuul 2.0理念更先进，想基于Netty非阻塞和支持长连接，但Spring Cloud目前还没有整合，Zuul 2.0的性能提升了很多，但是，Spring Cloud官方的基准测试，Spring Cloud Gateway的RPS(每秒请求数)是Zuul的1.6倍。

Spring Cloud Gateway

建立在Spring 5，Spring Boot 2和Project Reactor之上，使用非阻塞API。
还支持WebSocket，并且与Spring紧密集成，拥有更好的开发体验。

Spring Cloud Gateway的用途

方向代理
鉴权
流量控制
熔断
日志监控
…

Gateway在微服务架构中的位置

Gateway的工作流程

我在上面给你们的Gateway地址中，网页中有一张这样的官方图，这张图很好的诠释出它的工作流程。

客户端向Spring Cloud Gateway发出请求。如果网关处理程序映射确定请求与路由匹配，则将其发送到Gateway Web Handler。Handler通过特定于请求的过滤器链运行请求。筛选器由虚线分隔的原因是，筛选器可以在发送代理请求之前和之后运行逻辑。执行所有“pre”过滤器进行逻辑过滤。然后发出代理请求。发出代理请求后，将运行“post”过滤器执行逻辑过滤。

Filter在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等，在“post”类型的过滤器可以做响应内容、响应头修改、日志输出和流量监控等。

总结：核心逻辑就是路由转发+执行过滤器链。