本文将从知识拓扑讲起,谈一下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 鉴权
就是权限认证,也就是常说的权限系统。由于鉴权