大话SpringCloud---谈谈我所理解的微服务网关与Spring Cloud Gateway&Zuul的技术选型

最近在学习微服务网关的一些知识，说实话，每次刚开始理论性的东西时，经常会懵圈。因为会感觉和别的概念很像，搞不懂这个东西存在的意义是什么。就像之前的服务熔断与服务降级一样。所以就需要反复吃透与记录笔记。

---

微服务网关是啥？

首先这个概念，在zuul的官方文档里面有介绍

说白了，这个东西就是拦住所有的请求，你想要访问我的微服务资源，要先过我这一关。

来一个例子，平时中小学甚至大学都不会随意给外人进入，因为有门卫处，里面有安保人员在那里盯着。你要进入学校要先经过他们的法眼。这样就可以拦住不安好心的人了。服务网关就是这么一个“安保处”。

再来看一张Spring官网的微服务架构图：

所有的终端设备（mobile手机端、brower浏览器、lot物联网设备等等）在访问微服务请求时都会先经过这个GateWay（微服务网关），然后再由 GateWay（微服务网关） 进行路由转发到对应的微服务去。

当然除了路由转发之外，它还可以做：反向代理、鉴权、流量控制、熔断、日志监控等等。

同时服务网关对外屏蔽内部服务调用细节，你只用访问这个地址就行了，里面发生了啥都不用去管。

之前一直弄懵这个概念是因为，它能做的路由转发，负责二次进行转发，并且会帮你实现负载均衡。我一直寻思着，这不是服务注册的功能吗。我们去 服务注册中心（Eureka Server） 寻找服务，它会把对应的微服务地址给你，然后让你去调用。只不过是主动与被动。后面看到一篇博客，同时想了一下，发现还是钻牛角尖了，两个根本不是一个东西。

上图中各组件的组件和运行流程如下：

• 所有请求都通过API网关来访问内部服务；
• 网关接受请求后，从注册中心获取可用服务模块；
• 由Ribbon进行负载均衡后，分发到后台的具体实例；
• 各个服务模块之间通过Feign进行通信处理业务；（现在推荐用openfeign）
• Hystrix负责处理服务超时熔断；
• Turbine监控服务间的调用和熔断相关指标。

最后再来聊一下技术选型

说到底，前面介绍的微服务网关只是一个“天上飞”的理论，总需要有什么框架去实现它。而业界有两个实现的网关框架：Zuul与Spring Cloud GateWay。其中Zuul是上文打过的招呼的。

我们平时怎么选呢？我们java程序员平时开发微服务一般都用Spring Cloud吧，那还用说用哪个吗？看都看得出啦。

玩笑话。以下通过商业和技术的分析来决定选用哪一个框架。

商业上通过查资料了解到，以前Spring Cloud是用Zuul的，它是由Netfilx公司开发的，这个公司挺强，人送外号“国外爱奇艺”。基本整个分布式开发一站式解决方案都是它搞出来，可惜后面不争气了。Zuul就是个例子。原本Netfilx想开发Zuul2.x，程序员们听了当然觉得好呀，Spring社区的人们也乐意。这样性能会更强。不过后面他们的开发核心人员被挖走了，同时内部还出现了巨大的分歧。于是到现在Zuul2.x还只有一个半成品。SpringCloud总不能用半成品吧，于是借鉴了Zuul2.x的思想，自己整了一个Spring Cloud Gateway。并且在新版的SpringCloud中进行整合。

接着从技术原因上进行简单分析，由于Zuul2.x还是个半成品所以这里不做讨论，以下Zuul代表Zuul1.x。

Zuul构建于 Servlet 2.5，兼容 3.x，使用的是阻塞式的 API，不支持长连接，比如 websockets。另外

Spring Cloud Gateway构建于 Spring 5+，基于 Spring Boot 2.x 响应式的、非阻塞式的 API。同时，它支持 websockets，和 Spring 框架紧密集成，开发体验相对来说十分不错。

性能上，当然也是Spring Cloud Gateway更加强一点，可以处理高并发的场景。同时因为它也属于Spring家族的成员之一，所以整合起来安全性和稳定性会由于Zuul。

现在开发，网关组件还是推荐使用Spring Cloud Gateway。感谢观看