我们的微服务中为什么需要网关？-电子发烧友网

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

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

画一张简单的架构图，类似下面这样：

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

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

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

这是网关的第二个作用。

3. 协议切换

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

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

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

4. 限流

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

5. 请求分析

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

6. 缓存

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

7. 认证

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

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

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