Spring Cloud Gateway2.0实践报告

本文将从知识拓扑讲起，谈一下api网关的功能，以及spring cloud gateway的使用方法。文章很长，可以先过一下目录。

一、知识拓扑 (使用和原理)
二、网关的作用
三、Predicate，路由匹配
四、Filter，过滤器编写
五、自定义过滤器
六、常见问题
复制代码

为什么很多人觉得spring cloud gateway难用？因为它的背后用的是webflux，涉及到响应式编程，而不是传统的过程式编程。

我们把背后的技术梳理一下，不难发现，这个晦涩的根源，就来自于project reactor，与spring项目并驾齐驱的，”面向未来”的响应式编程框架。

结果最后的代码，都长的和lambda一样。其背后的思想，是观察者模式和非阻塞杂交的产物，学习曲线相对陡峭。

一、知识拓扑

spring cloud gateway涉及到许多比较新的知识和理念，但仅仅对于使用来说，坡度并不是很大。

1.1 使用相关

我们可以想象一下一个路由的必要元素：web请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细化控制。

其中，predicate就是我们的匹配条件；而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了。

由于spring cloud gateway是基于springboot的，所以使用yml进行路由的配置。yml的层次通常比较深，这就造成了配置文件看起来非常的乱。它也可以使用java代码（或者kotlin）进行路由的编写，风格偏向函数编程，所以需要首先了解lambda表达式的写法。

spring cloud gateway大多数时候是作为http服务的网关，可以针对http的报文进行一些细粒度的控制，所以还需要对http协议有较多的理解，才能在使用时游刃有余。

1.2 原理相关

而在原理方面，却复杂的多。由于实践方面的滞后性，现有的组件大多数还没有追上“响应式”这个“超前”的理念，催生了一堆晦涩的组件（主要是专用函数太多）。好在，使用spring cloud gateway并不需要直接接触这些api。

最重要的，就是对webflux框架的封装。webflux是可以替代spring mvc的一套解决方案，可以编写响应式的应用，两者之间的关系可以看下图。它的底层使用的是netty，所以操作是异步非阻塞的。

再往下走，webflux是运行在project reactor之上的一个封装，其根本特性是由后者提供的。这个东西和vert.x一样，初次接触使用起来会感觉特别怪异。

reactor是观察者模式的发扬，所以里面有Publisher的概念，其中最主要的实现，就是Flux和Mono。所谓的webflux，取名就在于此。

reactor参考：https://url.cn/5B7f5iY

从传统的开发模式过渡到reactor的开发模式，是有一定成本的。如果有时间可以了解一下背后的原理，对spring cloud gateway的使用，还是有好处的。

二、网关的作用

从名字就可以看到，它是一个网络的关卡，无论后端多么的复杂，这个对外的关卡表现是一致的。

更加重要的是，隐藏在关卡后面的一些通用的事务，都可以抽象出来进行处理。可以把网关，想像成一个类似于海关的东西，你的签证资料准备、安检、调度等，都可以统一进行处理。

api网关就是伴随着微服务概念兴起的一种架构模式，当然也不仅限于微服务。从图中我们可以看到网关的位置。

且看下面网关的具体作用。

2.1 反向代理

这个是所有网关，包括nginx的基本功能。除了能够对服务进行整形，网关一个非常重要的附加收益，就是对后端的服务细节进行了屏蔽。

反向代理同时会带有负载均衡的功能，包括带权重的流量分配。

2.2 鉴权

就是权限认证，也就是常说的权限系统。由于鉴权服务有非常高的相似性，就可以进行抽象处理，放在网关层。

比如https协议的统一接入，分布式session