微服技术栈之Spring could gateway

0 前言

之前使用到的gateway技术栈，光靠记忆可能没有记住那么多的，gateway当今比较主流的网关技术栈了。说到gateway，不得不提及Zuul，而Zuul已经被淘汰了。

1 概述

Could全家桶有个很重要的组件就是网关，在1.X版本中都是采用Zuul网关，但是在2.X版本中，Zuul的升级一直跳票，Spring Could最后自己研发Gateway,那就是Spring Could Gateway。

Springcloud Gateway是 Spring cloud 的一个全新项目，基于 Spring 5.0+spring Boot 2.0 和 Project Reactor等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API路由管理方式。

Springcloud Gateway 作为 Soring Cloud 生态系统中的网关，目标是替代,Zuul,在Spring Cloud 2.0以上版本中，没有对新版本的Zuyl 2.0以最新高性能版本进行集成，仍然还是使用的zuul1.x非Reactor模式的老版本。而为了提升网关的性能，springcloud Gateway是基于Webflux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway的目标提供统一的路由方式且基于 Filter 链的方式提供了网关基本的功能，例如:安全，监控/指标，和限流。如下图所示，所有的前段请求api都经过网关，网关是所有微服务的入口，而网关需要Nginx做代理，Nginx可以根据多个访问路径做成负载均衡调用。

一方面因为Zuu11.0已经进入了维护阶段，而且Gateway是SpringCloud团队研发的，是亲儿子产品，值得信赖。

而且很多功能Zuul都没有用起来也非常的简单便捷。

Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netfix早就发布了最新的 Zuul 2.x,但 Spring Cloud 貌似没有整合计划。而且Netflix相关组件都宣布进入维护期;不知前景如何?

多方面综合考虑Gateway是很理想的网关选择。

2. 特性

1）基于Spring Framework 5, Project Reǎctor 和 Spring Boot 2.0 进行构建

2）动态路由:能够匹配任何请求属性:

3）可以对路由指定 Predicate(断言)和 Fiter(过滤器)

4）集成Hystrix的断路器功能;

5）集成 Spring Cloud 服务发现功能;

6）易于编写的 Predicate(断言)和 Filter(过滤器)

7）请求限流功能;

8）支持路径重写。

2.1 gateway和Zuul1的区别

1、Zuu 1.x，是一个基于阻塞//0的 APl Gateway

2.Zuul1.x基于Serl@t 2.5使用阻塞架构它不支持任何长连接(如 Websocket) zuul 的设计模式和Nginx较像，每次 I0 操作都是3.从Zuul2工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx 用C++ 实现，Zuul 用 Java 实现，而 JVM本身会有第一次加载较慢的情况，使得Zuu的性能相对较差。Zuul 2.x理念更先进，想基于Netty非阻塞和支持长连接，但SpringCloud目前还没有整合。 Zuul 2.x的性能较 Zuul1x有较大提升3.在性能方面，根据官方提供的基准测试，Spring Cloud Gateway的 RPS(每秒请求数)是Zuul 的 1.6 倍。

4.Spring Cloud Gateway建立在 Spring framework 5、Project Reactor 和 Spring Boot2之上，使用非阻塞 API.

5.Spring Cloud Gateway 还支持 WebSocket，并且与Spring紧密集成拥有更好的开发体验

2.2 Zuul1.X模型

Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet I/O处理模型。

Servlet的生命周期?servlet由servlet container进行生命周期管理。

container启动时构造servlet对象并调用servlet init0)进行初始化。

container运行时接受请求，并为每个请求分配一个线程(一般从线程池中获取空闲线程)然后调用service0)

container关闭时调用servet destory0)销毁servlet;

上述模式的缺点:

servlet是一个简单的网络!0模型，当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的。但是一旦高并发(比如抽风用jemeter压)，线程数量就会上涨，而线程资源代价是昂贵的(上线文切换，内存消耗大)严重影响请求的处理时间。在一些简单业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极大并发的请求，这种业务场景下seriet模型没有优势。

所以zuu11.X是基于serviet之上的一个阻塞式处理模型，即spring实现了处理所有request请求的一个。servlet(Dispatcherservlet)并由该servlet阳塞式处理处理。所以Springcloud Zuul无法摆脱servlet模型的弊端。

2.3 WebFlux

传统的Web框架，比如说:struts2，springmvc等都是基于Servet APl与Servlet容器基础之上运行的。

但是在Servlet3,1之后有了异步非阳塞的支持。而Webflux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的，相对于传统的web框架来说，它可以运行在诸如Netty，Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程(Spring5必须让你使用java8)

Spring Webflux 是 Spring 5.0引入的新的响应式框架，区别于 Spring MVC，它不需要依赖Servlet AP!，它是完全异步非阻塞的，并且基于 Reactor 来实现响应式流规范。