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 来实现响应式流规范。

gateway原理介绍

3.1 gateway工作流

前置知识
路由就是构建网关额基本模块，它由ID，目标URI，一系列的断言和过滤器组成的，如果断言为true则匹配该路由。
断言（Predicate）： 参考的是Java8的iava.util.function.Predicate
开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数)，如果请求与断言相匹配则进行路由
过滤器（Filter）：指的是Spring框架中Gateway Filter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改

总体

web请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细化控制。predicate就是我们的匹配条件;
而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了。

客户端向 Spring Cloud Gateway 发出请求，然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 GatewayWeb Handler.
Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前("pre”)或之后(“post”)执行业务罗辑,
Filter在 “pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等,在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。

3.2 集成配置

建立pom.xml

需要注意：移除web依赖，去除spring-boot-starter-web依赖，gateway不需要web，否则报错 。

配置yml文件

配置成功后启动gateway和微服务。

通过编码的方式配置路由规则，如下图所示：

3.2 gateway实现负载均衡

通过微服务名实现动态路由。网关与微服之间的架构如如下所示。
默认情况下gateway会根据注册中心的服务列表，以注册中心上的微服务名为路径创建动态路由进行转发，从而实现动态路由的功能。

具体配置，就是把IP地址改成了服务名，即在注册中心中的微服名称，如下图所示：

3.3 Predicate的使用

首先配置时间。

Cookie级别的配置。不带Cooki，和带Cookie
Cookie Route Predicate需要两个参数，路由规则会通过获取对应的 Cookie name个是Cookie name ,一个是正则表达式。
值和正则表达式去匹配，如果匹配上就会执行路由，如果没有匹配上则不执行。

请求头配置

Host路由断言配置。

验证配置是否成功如下：

3.4 Filter的使用

veb请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细化控制。predicate就是我们的匹配条件:而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了。
路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用。Spring Cloud Gateway 内置了多种路由过滤器，他们都由GatewayFilter的工厂类来产生。
由于官方给了过滤器有三十多种配置，本文不可能一一去描述，管网已经存在的配置描述本文略过，而是进行自定义的过滤器配置。
自定义全局GlobalFilter，注意实现GlobalFilter和Ordered两个接口。

结束语

微服组件网关已经结束了，下面就开始学习分布式事务的组件了Seata，是阿里巴巴的分布式事务的解决方案。