Cloud全家桶中有个很重要的组件就是网关,在1.x版本中都是采用的Zuul网关
但是在2.x版本中,zuul的升级一直在跳票,SpringCloud最后自己研发了一个网关替代Zuul,那就是SpringCloudGateway
一句话:gateway是原zuul 1.x版的替代
Gateway是在Spring生态系统之上构建的API网关服务,基于Spring5,SpringBoot2和Project Reactor等技术
Gateway旨在提供一种简单而有效的方式来对API进行路由,以及提供一些强大的过滤器功能,例如:熔断、限流、重试等
SpringCloud Gateway是SpringCloud的一个全新项目,基于Spring5,SpringBoot2和Project Reactor等技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的API路由管理方式
SpringCloud Gateway作为SpringCloud生态系统中的网关,目标是替代Zuul,在SpringCloud2以上的版本中,没有对新版的Zuul 2.0以上的最新高性能版本进行集成,仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能,SpringCloud Gateway是基于WebFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty
Spring Cloud Gateway的目标提供统一的路由方式且基于Filter链的方式提供了网关基本的功能,例如:安全,监控,指标,限流
Spring Cloud Gateway的主要功能:
反向代理、鉴权、流量控制、熔断、日志监控
一方面Zuul 1.0进入维护阶段,Gateway更值得信赖,而且很多功能用起来非常简单便捷
gateway是基于异步非阻塞模型上进行开发的,性能优秀
Spring Cloud Gateway具有如下特点:
基于Spring5,SpringBoot2和Project Reactor等技术开发的网关
动态路由:能够匹配任何请求属性
可以对路由指定Predicate(断言)和Filter(过滤器)
集成Hystrix的断路器功能
集成Spring Cloud服务发现功能
易于编写的Predicate(断言)和Filter(过滤器)
请求限流功能
支持路径重写
Zuul 1.x 是一个基于阻塞IO的API Gateway
Zuul 1.x 基于Servlet2.5使用阻塞架构它不支持任何长连接(如WebSocket)Zuul的涉及模式和Nginx较像,每次IO操作都是从工作线程中选择一个执行,请求线程被阻塞到工作线程完成,但是差别是Nginx是C++实现,Zuul是Java实现,而JVM本身会有第一次加载较慢的情况,使得Zuul的性能相对较差
Zuul 2.x理念更先进,想基于Netty非阻塞和支持长连接,但SpringCloud目前还没有整合。Zuul 2.x的性能比Zuul 1.x有很大提升。在性能方面,根据官方提供的基准测试,SpringCloudGateway的RPS(每秒请求数)是Zuul的1.6倍
Spring Cloud Gateway建立在Spring5,SpringBoot2和Project Reactor之上,使用非阻塞API
Spring Cloud Gateway还支持WebSocket,并且与Spring紧密集成拥有更好的开发体验
传统的Web框架,比如说:Struts2,SpringMVC等都是九月Servlet API与Servlet容器基础之上运行的
但是在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型非阻塞异步的框架,他的核心是基于Reactor的相关API实现的。相对于传统的web框架来书评,它可以运行在诸如Netty,Undertow及支持servlet3.1的容器上。非阻塞式+函数时编程(Spring5必须让你使用java8)
Spring webFlux 是Spring5引入的新的响应式框架,区别于SpringMVC,它不需要依赖ServletAPI,他是完全异步非阻塞的,并且基于Reactor来实现响应式流规范
Route(路由)
路由是构建网关的基本模块,它有ID,目标URI,一些列的断言和过滤器组成,如果断言为true则匹配该路由
Predicate(断言)
参考的是java8的java.util.function.Predicate
开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数),如果请求与断言相匹配则进行路由
Filter(过滤)
指的是Spring框架中GatewayFilter的实例,使用过滤器,可以在请求被路由前后对请求进行修改
总体
web请求,通过一些匹配条件,定位到正真的服务节点。并在这个转发过程的前后,进行一些精细化控制
Predicate就是我们的匹配条件;而filter就可以理解为一个无所不能的拦截器。有了这两个元素,再加上目标uri,就可以实现一个具体的路由了
客户端向Spring Cloud Gateway发出请求,然后在Gateway Handler Mapping中找到与请求相匹配的路由,将其发送到Gateway Web Handler
Handler再通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑,然后返回。
过滤器可以在发送代理请求前后执行业务逻辑
Filter在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等,在“post”类型的过滤器中可以做响应内容、响应头的修改,日志的输出,凉凉监控 等有着非常重要的作用
核心逻辑:路由转发+执行过滤器链
聚合父工程 添加链接描述
Eureka集群 添加链接描述
OpenFeign 添加链接描述
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
默认情况下Gateway会根据注册中心注册的服务列表,以注册中心上微服务名为路径创建动态路由进行转发,从而实现动态路由的功能
server:
port: 9527
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true #开启从注册中心动态创建路由的功能,利用微服务名进行路由
routes:
- id: payment_routh #payment_route #路由的ID,没有固定规则但要求唯一,建议配合服务名
#uri: http://localhost:8001 #匹配后提供服务的路由地址
uri: lb://cloud-payment-service #匹配后提供服务的路由地址
predicates:
- Path=/payment/get/** # 断言,路径相匹配的进行路由
- id: payment_routh2 #payment_route #路由的ID,没有固定规则但要求唯一,建议配合服务名
#uri: http://localhost:8001 #匹配后提供服务的路由地址
uri: lb://cloud-payment-service #匹配后提供服务的路由地址
predicates:
- Path=/payment/lb/** # 断言,路径相匹配的进行路由
#- After=2020-02-21T15:51:37.485+08:00[Asia/Shanghai]
#- Cookie=username,zzyy
#- Header=X-Request-Id, \d+ # 请求头要有X-Request-Id属性并且值为整数的正则表达式
eureka:
instance:
hostname: cloud-gateway-service
client: #服务提供者provider注册进eureka服务列表内
service-url:
register-with-eureka: true
fetch-registry: true
defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka
gateway也需要注册到eureka
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
@SpringBootApplication
@EnableEurekaClient
public class GateWayMain9527 {
public static void main(String[] args) {
SpringApplication.run(GateWayMain9527.class, args);
}
}
启动Eureka7001和7002
启动cloud-provider-payment8001
启动Gateway9527
网关已经注册到eureka了
访问 http://localhost:9527/payment/get/1