共计 2207 个字符，预计需要花费 6 分钟才能阅读完成。
玩过微服务的小伙伴对 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 字符串，这个校验自身比拟容易，又不须要连贯数据库，所以能够在网关上实现，校验胜利之后，将校验失去的用户信息放到申请头中，而后再转发申请到不同的微服务上，这样在各个微服务上，就晓得申请的用户到底是谁了。
8. 记录申请日志
如果须要记录申请日志，网关也是一个好中央。
网关无能这么多事，so，想要用 Nginx 代替 Spring Cloud Gateway 显然不太事实。
