Gateway新一代网关
gateway官网:https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/
他是什么?
Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot 2和Project Reactor等技术。 Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如:熔断、限流、重试等
SpringCloud Gateway是Spring Cloud的一个全新项目，基于Spring 5.0 Spring Boot 2.0和Project Reactor等技术开发的网关，它旨在为微服务架构提供—种简单有效的统一的API路由管理方式。 SpringCloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul .0以上最新高性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能 SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。 Spring Cloud Gateway的目标提供统一的路由方式且基于Filter链的方式提供了网关基本的功能，例如:安全，监控/指标，和限流。
一句话概括就是:Spring Cloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架.
架构:
技术背景
有了Zuul了怎么又出来了gateway??
我们为什么选择Gatway?:
neflix不太靠谱，zuul2.0一直跳票,迟迟不发布
一方面因为Zuul1.0已经进入了维护阶段，而且Gateway是SpringCloud团队研发的，是亲儿子产品，值得信赖。而且很多功能Zuul都没有用起来也非常的简单便捷。 Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netflix早就发布了最新的Zuul 2.x,但Spring Cloud貌似没有整合计划。而且Netflix相关组件都宣布进入维护期;不知前景如何 ? 多方面综合考虑Gateway是很理想的网关选择。
SpringCloud Gateway具有如下特性
- 基于Spring Framework 5, Project Reactor和Spring Boot 2.0进行构建;动态路由:能够匹配任何请求属性;
- 可以对路由指定Predicate(断言）和Filter (过滤器）;集成Hystrix的断路器功能;
- 集成Spring Cloud服务发现功能;
- 易于编写的 Predicate(断言）和Filter (过滤器);请求限流功能;
- 支持路径重写。
技术对比
Zuul
Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet lO处理模型。 学过尚硅谷web中期课程都知道一个题目，Servlet的生命周期?servlet由servlet container进行生命周 期管理。 container启动时构造servlet对象并调用servlet init)进行初始化; container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()。container关闭时调用servlet destory0销毁servlet;
上述模式的缺点:
servlet是一个简单的网络IO模型，当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的。但是一旦高并发(此比如抽风用jemeter)，线程数量就会上涨，而线程资源代价是昂贵的（上线文切换，内存消耗大)严重影响请求的处理时间。
在一些简单业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极大并发的请求，这种业务场景下servlet模型没有优势
所以Zuul 1.X是基于servlet之上的一个姐塞式处理模型，即spring实现了处理所有request请求的一个servlet (DispatcherServiet)并由该servletse塞式处理处理。所以Springcloud Zuul无法摆脱servlet模型的弊端
gateway(webflux netty)
传统的Web框架，比如说: struts2,springmvc等都是基于Servlet API与Servlet容器基础之上运行的。 但是 在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty, Undertow及支持Servlet3.1的容器上。非阻塞式 函数式编程(Spring5必须让你使用java8)
Spring WebFlux是Spring 5.0引入的新的响应式框架，区别于Spring MVC，它不需要依赖Servlet API，它是完全异步非阻塞的，并且基于Reactor来实现响应式流规范。
Gateway三大核心概念
Route(路由)：
路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由
Predicate（断言）：
参考的是java8的java.util.function.Predicate开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由
Filter(过滤)：
指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。
总体:
- web请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细化控制。
- predicate就是我们的匹配条件;
- flter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了
Gateway工作流程
核心逻辑: 路由转发 执行过滤器链
demo实战
新建模块: cloud-gateway-gateway9527
导入依赖
代码语言：javascript复制 <dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-gatewayartifactId>
dependency>
<dependency>
<groupId>com.atguigu.springcloudgroupId>
<artifactId>cloud-api-commonsartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrixartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-devtoolsartifactId>
<scope>runtimescope>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
dependencies>配置对应的yml
代码语言：javascript复制server:
port: 9527
spring:
application:
name: cloud-gateway
cloud:
gateway:
routes:
- id: payment_routh #路由的ID，没有固定规则但要求唯一，建议配合服务名
uri: http://localhost:8001 #匹配后提供服务的路由地址
predicates:
- Path=/payment/get/** #断言,路径相匹配的进行路由
- id: payment_routh2
uri: http://localhost:8001
predicates:
- Path=/payment/lb/** #断言,路径相匹配的进行路由
eureka:
instance:
hostname: cloud-gateway-service
client:
service-url:
register-with-eureka: true
fetch-registry: true
defaultZone: http://eureka7001.com:7001/eureka编写主启动类:
代码语言：javascript复制@SpringBootApplication
@EnableEurekaClient
public class GateWayMain9527 {
public static void main(String[] args) {
SpringApplication.run( GateWayMain9527.class,args);
}
}构建好基本的网关模块之后,我们需要思考
9527网关如何做路由映射那？？？
我们打开服务提供者:cloud-provider-payment8001看看controller的访问地址
我们不想暴露8001服务端口，希望在8001外面套一层9527
于是乎
配置网管 9527的配置文件
代码语言：javascript复制server:
port: 9527
spring:
application:
name: cloud-gateway
cloud:
gateway:
routes:
- id: payment_routh #路由的ID，没有固定规则但要求唯一，建议配合服务名
uri: http://localhost:8001 #匹配后提供服务的路由地址
predicates:
- Path=/payment/get/** #断言,路径相匹配的进行路由
- id: payment_routh2
uri: http://localhost:8001
predicates:
- Path=/payment/lb/** #断言,路径相匹配的进行路由
eureka:
instance:
hostname: cloud-gateway-service
client:
service-url:
register-with-eureka: true
fetch-registry: true
defaultZone: http://eureka7001.com:7001/eureka这个时候我们可以来测试一下
添加网关前:http://localhost:8001/payment/get/1,我们访问会暴露出端口
添加网关后:http://localhost:9527/payment/get/1,我们访问网管,他会去找到配置文件对路由的匹配路由地址,之后断言按照规则匹配路由
通过微服务名实现动态路由
简单看到了网管效果之后,继续看看问题,我们现在的配置十分的膨胀,url是匹配死的,我们需要的是动态的,
默认情况下Gateway会根据注册中心的服务列表，以注册中心上微服务名为路径创建动态路由进行转发，从而实现动态路由的功能
这个时候我们启动 : 一个eureka7001 两个服务提供者8001/8002
此时我们要去继续修改9527的配置:
代码语言：javascript复制server:
port: 9527
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true #开启从注册中心动态创建路由的功能，利用微服务名进行路由
routes:
- id: payment_routh #路由的ID，没有固定规则但要求唯一，建议配合服务名
#uri: http://localhost:8001 #匹配后提供服务的路由地址
uri: lb://cloud-payment-service
predicates:
- Path=/payment/get/** #断言,路径相匹配的进行路由
- id: payment_routh2
#uri: http://localhost:8001 #匹配后提供服务的路由地址
uri: lb://cloud-payment-service
predicates:
- Path=/payment/lb/** #断言,路径相匹配的进行路由
eureka:
instance:
hostname: cloud-gateway-service
client:
service-url:
register-with-eureka: true
fetch-registry: true
defaultZone: http://eureka7001.com:7001/eurekaPS :
- 需要注意的是uri的协议为lb，表示启用Gateway的负载均衡功能。
- lb://serviceName是spring cloud gateway在微服务中自动为我们创建的负载均衡uri
之后再次测试
http://localhost:9527/payment/lb
就可以发现采用了轮询的方式做负载均衡,在8001/8002两个端口切换
Predicate的使用断言的使用
断言是什么?
启动我们的gatewat9527
我们会看到他在启动的时候
Route Predicate Factory 这个是什么东东？
Spring Cloud Gateway将路由匹配作为Spring WebFlux HandlerMapping基础架构的一部分。
- Spring Cloud Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。多个RoutePredicate工厂可以进行组合
- Spring Cloud Gateway创建Route对象时，使用RoutePredicateFactory 创建 Predicate对象，Predicate对象可以赋值给Route。Spring Cloud Gateway包含许多内置的Route Predicate Factories。
- 所有这些谓词都匹配HTTP请求的不同属性。多种谓词工厂可以组合
常用的Route Predicate
我们来看一下常用的断言:
代码语言：javascript复制 - Path=/payment/lb/** #断言,路径相匹配的进行路由
#- After=2020-03-08T10:59:34.102 08:00[Asia/Shanghai]
#- Cookie=username,zhangshuai #并且Cookie是username=zhangshuai才能访问
#- Header=X-Request-Id, d #请求头中要有X-Request-Id属性并且值为整数的正则表达式
#- Host=**.atguigu.com
#- Method=GET
#- Query=username, d #要有参数名称并且是正整数才能路由说白了，Predicate就是为了实现一组匹配规则，让请求过来找到对应的Route进行处理
Filter的使用
路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用。 Spring Cloud Gateway内置了多种路由过滤器，他们都由GatewayFilter的工厂类来产生
Spring Cloud Gateway的Filter
常用的GatewayFilter:AddRequestParameter
自定义全局GlobalFilter
两个主要接口介绍:
- GlobalFilter : 全局过滤器
- Ordered : 执行顺序
能干嘛?
- 全局日志记录
- 统一网关鉴权
- 等等等…
过滤器代码
代码语言：javascript复制@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter,Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
log.info("*********come in MyLogGateWayFilter: " new Date());
String uname = exchange.getRequest().getQueryParams().getFirst("username");
if(StringUtils.isEmpty(username)){
log.info("*****用户名为Null 非法用户,(┬＿┬)");
exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);//给人家一个回应
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder() {
return 0;
}
}使用了这个之后
我们的请求如果是没有带有uname这个参数就会被过滤,可以用来作为一些必要参数的筛选和鉴权.
以上就是gate网关的学习啦
