为什么我们的微服务中需要网关?

玩过微服务的小伙伴对 Spring Cloud 中的的 Spring Cloud Gateway 多多少少都有一些了解,松哥之前既写过相关的文章,也录过相关的视频跟小伙伴们介绍 Spring Cloud Gateway,不过在之前的介绍中,我可能更加侧重于跟小伙伴们介绍 Spring Cloud Gateway 的用法,对于我们在微服务中为什么要使用 Spring Cloud Gateway 可能没有和大家仔细分析过,最近年前得空,我们来一起探讨一下这个话题。

说起 Spring Cloud Gateway 的使用场景,我相信很多小伙伴都能够脱口而出认证二字,确实,在网关中完成认证操作,确实是 Gateway 的重要使用场景之一,然而并不是唯一的使用场景。在微服务中使用网关的好处可太多了,今天我们就来逐一分析一下。

1. 请求路由

首先,Gateway 的第一个重要特点就是对请求进行路由,根据不同的请求头、请求参数、请求路径等,将请求路由到不同的服务上。

从这个角度来说,Spring Cloud Gateway 所扮演的角色与 Nginx 这一类的反向代理服务器类似,之前就有小伙伴问我,Spring Cloud Gateway 和 Nginx 有啥区别?能不能用 Nginx 代替 Spring Cloud Gateway?其实,你要是单纯的只看请求路由这一个功能,那么确实可以用 Nginx 代替 Spring Cloud Gateway,然而在实际开发中,我们 Spring Cloud Gateway 所承担的责任可不仅仅是请求路由转发,还有其他方面的功能(后文有介绍),其他的功能用 Nginx 做起来就有一些吃力了。

如果用 Spring Cloud Gateway 做请求路由转发,我们可以画一张简单的架构图,如下:

2. API 组合

网关的另一个作用就是可以实现 API 的组合。当然这个一般来说需要一些代码开发,单纯的配置一般来说是无法实现需求的。

先来说说没有网关的时候我们可能会存在什么情况。

以松哥最近在录的 TienChin 项目视频为例,我有一个活动管理服务,也就是健身房定期会做一些促销活动,促销活动往往又分为线上或者线下,线上线下又继续细分为不同的渠道,如小红书推广、抖音推广、公众号推广、线下地推等等,所以,假设我现在要做一个修改活动的功能,那么当我选中一条记录,点击修改按钮,此时,客户端至少要发送两条请求:

  1. 首先根据我选中的记录的 ID,去服务端查询这条记录当前的值。
  2. 去查询活动渠道,因为活动记录中保存的是渠道 ID,我们得去查询所有的渠道信息,然后根据渠道信息才能显示出来具体的渠道。

画一张简单的架构图,类似下面这样:

如上图所示,如果你是一个微服务项目,但是却没有网关,那么前端用户一个点击事件你可能需要在后台发出 N 多个操作。并且,这 N 多个操作还都属于互联网请求,小伙伴们知道,互联网请求的一个特点就是低带宽和高延迟,连着发送两个甚至多个请求,用户体验肯定不佳。

像这样的场景,如果我们有网关,就可以在网关中提供一个粗粒度的 API,这样,前端只需要发送一个请求到网关,然后又网关去发送多个请求,从不同的微服务上把数据拿回来再统一返回给前端。如下图:

可能有小伙伴会说,你这个请求还是发送了两次,不一定省时间。其实不然!网关往往和微服务处于同一个局域网之中,相比于互联网,局域网的通信延迟就要小很多了。

这是网关的第二个作用。

3. 协议切换

通过网关我们还能实现请求协议的切换。

一般来说我们暴露给外部的服务都是 RESTful API,但是,有时候考虑到服务内部的执行效率问题,我们可以在服务内容实用其他更高效的协议,通过服务网关就可以实现这个切换。

当然,这并不是必须的,只是说,当我们在微服务中使用了网关之后,如果想做请求协议的切换,就会比较容易实现。

4. 限流

微服务中的限流操作,一个比较好的限流位置就是网关了,我们可以利用 Alibaba 的 Sentinel 结合 Spring Cloud Gateway 就可以非常方便的实现限流操作。

5. 请求分析

如果我们需要统计某一个请求的细节,如执行时间、参数等信息,那么这个操作也可以在网关上来做,在网关上对请求进行详细分析。

6. 缓存

对于一些不经常变化的数据,我们可以设置缓存时间,在网关上直接进行检查,如果缓存还没失效,直接响应 304,让从客户端读取即可。

7. 认证

这个是大家比较熟悉的了。

一般来说,我们可能会有单独的认证服务,当认证请求到达网关之后,网关将之转发到相应的认证服务上去完成认证。对于非认证请求,到达网关的时候需要校验这个请求是否有进行认证,这个校验就没必要转发了,可以直接在网关上进行校验。

松哥举个简单的例子,也是我自己之前在项目中的一个实践经验,就是用户登录请求到达网关之后,网关将之转发到专门的认证服务上去(由于认证的过程往往需要操作用户数据库,所以不要在网关上做认证,转发到专门的认证服务上去做认证操作),认证成功之后,返回 JWT 字符串给前端。下一次,请求带着 JWT 字符串来到网关,可以直接在网关上校验 JWT 字符串,这个校验本身比较容易,又不需要连接数据库,所以可以在网关上完成,校验成功之后,将校验得到的用户信息放到请求头中,然后再转发请求到不同的微服务上,这样在各个微服务上,就知道请求的用户到底是谁了。

8. 记录请求日志

如果需要记录请求日志,网关也是一个好地方。

网关能干这么多事,so,想要用 Nginx 代替 Spring Cloud Gateway 显然不太现实。

你可能感兴趣的:(为什么我们的微服务中需要网关?)