网关GateWay的使用详解、路由、过滤器、跨域配置
一、网关的基本概念
SpringCloudGateway
网关是所有微服务的统一入口。
1.1 它的主要作用是:
- 反向代理(请求的转发)
- 路由和负载均衡
- 身份认证和权限控制
- 对请求限流
1.2 相比于Zuul的优势:
SpringCloudGateway
基于
Spring5
中提供的
WebFlux
,是一种响应式编程的实现,性能更加优越。
Zuul
的实现方式比较老式,基于
Servlet
的实现,它是一种阻塞式编程,在高并发下性能性能不佳。
拓展:
其实Nginx也可以作为网关,但是要使用Nginx自主实现网关的相关功能,还需要借助lua脚本语言
学习成本是比较高的,现在一般也不会使用它来做网关,但是只按性能来讲Nginx,性能是最高的。
1.3 SpringCloudGateway架构图:
微服务只接收来自网关的请求,而其它直接访问微服务本身的请求拒绝。
这样可以极大保护微服务免受不法侵害。
同时在请求压力激增时,可以实施服务限流,保护微服务集群。
二、SpringBoot中配置GateWay
2.1 引入GateWay的Maven依赖
<!--网关 起步依赖--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId></dependency><!--nacos服务发现 起步依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>
2.2 配置application.yml文件
server:port:10086# 网关端口spring:application:name: gateway # 服务名称cloud:nacos:server-addr: localhost:8848# nacos 地址gateway:routes:# 网关路由配置-id: user-service # 路由id,自定义,只要唯一即可# uri: http://127.0.0.1:8081 # 路由的目标地址 (直接写死地址的方式,不推荐)uri: lb://userservice # 路由的目标地址 lb是负载均衡,后面跟服务名称(推荐)predicates:# 路由断言,判断请求是否符合路由规则的条件- Path=/user/**# 按照路径匹配,以/user/开头的请求就符合要求-id: card-service
uri: lb://cardservice
predicates:- Path=/card/**
gateway配置中的注意点:
routes
后面的路由可以配置多个,相当于配置个数组,一个-
开头的配置就是其中的一个数组元素。uri
为什么选择以服务名+负载均衡的方式?主要是写死地址的话,今后如果userservice
的地址变了,那么又要去修改yml
配置文件。而lb://userservice
可以让程序员一眼认出这是哪个微服务,以后地址变了也无需修改yml
配置文件。
上述配置详解:
将
/user/**
开头的请求,代理到
lb://userservice
。
将
/card/**
开头的请求,代理到
lb://cardservice
。
lb
是负载均衡,根据服务名拉取服务列表,实现负载均衡。
http://127.0.0.1:10086/user/99
就算是/user/**
开头的请求,不要把协议、ip
和端口计算在内。- 有多少个需要配置的路由,都按上面的格式配置即可
三、GateWay路由配置详解
路由主要有四个配置:
- 路由id(
id
) - 路由目标(
uri
) - 路由断言(
predicates
):判断路由的规则, - 路由过滤器(
filters
):对请求或响应做处理
3.1 路由id
当前路由的唯一标识。
3.1 路由目标
路由的目标地址,
http
代表固定地址,
lb
代表根据服务名负载均衡。
一般都不会选择写死
http
固定地址的方式。而是选择可维护性更强的
lb
根据服务名负载均衡的方式。
具体优势如上所言。
3.3 路由断言
路由断言主要用来判断路由的规则。
配置文件中写的断言规则只是字符串,这些字符串会被Predicate Factory读取并处理。
例如Path=/user/**是按照路径匹配,这个规则是由
org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory
类来处理。
像这样的断言工厂在
SpringCloudGateway
还有十几个:
名称说明示例After是某个时间点后的请求- After=2022-01-20T14:32:27.789-07:00[Asia/Shanghai]Before是某个时间点之前的请求- Before=2022-04-13T15:14:47.433+08:00[Asia/Shanghai]Between是某两个时间点之前的请求- Between=2021-01-20T17:42:47.789-07:00[Asia/Shanghai], 2023-01-21T17:42:47.789-07:00[Asia/Shanghai]Cookie请求必须包含某些cookie- Cookie=chocolateHeader请求必须包含某些header- Header=asd, casHost请求必须是访问某个host(域名)- Host=baidu.com, jd.comMethod请求方式必须是指定方式- Method=GET,POSTPath请求路径必须符合指定规则- Path=/user/{params},/card/**Query请求参数必须包含指定参数- Query=name, JackRemoteAddr请求者的ip必须是指定范围- RemoteAddr=192.168.1.1/24Weight权重处理
实际使用时,根绝业务要求选择使用即可。
不过一般来讲,最常用的是使用
Path
这种断言工厂,仅用它就能满足常见的需求了。
关于Path断言工厂的补充:
Path=/card/**
代表 以
/card/
路径开头的多级路径请求,这么写多级路径请求和一级路径请求都生效。
Path=/card/*
代表 以
/card/
路径开头的一级路径请求,这么写多级路径请求将不会生效。
断言工厂官方文档:
(今后如果有复杂的断言工厂配置,可以参照官网文档上的例子去实现。)
3.4 路由过滤器(filters)
路由过滤器对请求或响应做处理。
客户端请求先找到路由,路由匹配时经过过滤器层层筛选,最终访问到微服务。
当然微服务的请求反悔时,也会经过过滤器的筛选,只不过我们一般只对请求过滤,而不会对响应过滤。
SpringCloudGateWay
目前已经提供了34种不同的过滤器工厂。
常用的几个有:
名称****说明AddRequestHeader给当前请求添加一个请求头RemoveRequestHeader移除请求中的一个请求头AddResponseHeader给响应结果中添加一个响应头RemoveResponseHeader从响应结果中移除有一个响应头RequestRateLimiter限制请求的流量
3.4.1 请求头过滤器配置示例(局部过滤器)
spring:cloud:gateway:routes:-id: user-service
uri: lb://userservice
predicates:- Path=/user/**filters:# 过滤器配置- AddRequestHeader=token, test # 添加请求头
上述过滤器的含义:
给所有进入
userservice
的请求添加一个请求头。
请求头的
key
为
token
,
value
为
test
。
由于当前前过滤器写在微服务的
userservice
路由下,因此仅仅对访问微服务
userservice
的请求有效。
3.4.2 默认过滤器配置示例(全局过滤器)
spring:cloud:gateway:routes:-id: user-service
uri: lb://userservice
predicates:- Path=/user/**default-filters:# 默认过滤器配置- AddRequestHeader=token, test # 添加请求头
default-filters
的配置和
routes
平级。
只要配置在
default-filters
下面的过滤器,会对
routes
配置的所有路由都生效。
过滤器工厂官方文档:
https://docs.spring.io/spring-cloud-gateway/docs/3.1.4-SNAPSHOT/reference/html/#gateway-request-predicates-factories
今后如果有复杂的断言工厂配置,可以参照官网文档上的例子去实现。
四、自定义全局路由过滤器
有时候
SpringCloudGateWay
提供的过滤器工厂不能满足自己的要求。
可能有时候需要在过滤时做一些其它的逻辑操作。
那么这时候可以选择使用
java
代码自定义全局过滤器。
代码示例:
@ComponentpublicclassGateWayFilterimplementsGlobalFilter,Ordered{@OverridepublicMono<Void>filter(ServerWebExchange exchange,GatewayFilterChain chain){// 1.获取请求参数 //1.这里的request并不是servlet中的request //2.返回值是一个多键的map集合、也就是说这个map集合的键可以重复MultiValueMap<String,String> params = exchange.getRequest().getQueryParams();// 2.获取userName参数String userName = params.getFirst("userName");// 3.校验if("root".equals(userName)){// 放行return chain.filter(exchange);}// 4.拦截// 4.1.禁止访问,设置状态码
exchange.getResponse().setStatusCode(500);// 4.2.结束处理return exchange.getResponse().setComplete();}@OverridepublicintgetOrder(){return-1;}}
当有多个过滤器时,
Order
的值决定了过滤器的执行顺序。
数值越大优先级越低, 负的越多, 优先级越高。
设置
Order
的值有两种方式:
1. 实现Ordered接口,并且重写getOrder方法
@ComponentpublicclassGateWayFilterimplementsGlobalFilter,Ordered{@OverridepublicMono<Void>filter(ServerWebExchange exchange,GatewayFilterChain chain){}@OverridepublicintgetOrder(){return-1;}}
2. 使用@Order注解
@Order(-1)@ComponentpublicclassGateWayFilterimplementsGlobalFilter,Ordered{@OverridepublicMono<Void>filter(ServerWebExchange exchange,GatewayFilterChain chain){}}
五、过滤路由过滤器的执行顺序
5.1 过滤器的种类
SpringCloudGateWay
中,有三种过滤器:
- 默认过滤器
default-filters
- 只对具体某个路由生效的局部过滤器
filters
- 使用
java
代码编写的全局过滤器GlobalFilter
5.2 过滤器的执行顺序
由上图知过滤器的执行顺序为:默认过滤器 → 当前路由过滤器 → 全局过滤器。
六、网关的跨域问题
6.1 跨域的概念和原理
跨域:请求位置和被请求位置不同源就会发生跨域。
这里的不同源包括两个点:
- 域名不同:
www.baidu.com
和www.taobao.com
。(IP
不同也是相同道理) - 端口不同:
127.0.0.1:8080
和``127.0.0.1:8081`。
而浏览器又会禁止请求的发起者与服务端发生跨域
AJAX
请求。
如果发生了跨域请求,服务器端是能够正常响应的,但是响应的结果会被浏览器拦截。
6.2 跨域常见解决方案
使用
CORS
方式。
CORS
是一个
W3C
标准,全称是"跨域资源共享"(
Cross-origin resource sharing
)。
它允许浏览器向跨源服务器,发出
XMLHttpRequest
请求,从而克服了
AJAX
只能同源使用的限制。
6.3 gateway中如何解决跨域问题
配置
application.yml
文件。
spring:cloud:gateway:globalcors:# 全局的跨域配置add-to-simple-url-handler-mapping:true# 解决options请求被拦截问题# options请求 就是一种询问服务器是否浏览器可以跨域的请求# 如果每次跨域都有询问服务器是否浏览器可以跨域对性能也是损耗# 可以配置本次跨域检测的有效期maxAge# 在maxAge设置的时间范围内,不去询问,统统允许跨域corsConfigurations:'[/**]':allowedOrigins:# 允许哪些网站的跨域请求 -"http://localhost:8090"allowedMethods:# 允许的跨域ajax的请求方式-"GET"-"POST"-"DELETE"-"PUT"-"OPTIONS"allowedHeaders:"*"# 允许在请求中携带的头信息allowCredentials:true# 允许在请求中携带cookiemaxAge:360000# 本次跨域检测的有效期(单位毫秒)# 有效期内,跨域请求不会一直发option请求去增大服务器压力
版权归原作者 流水武qin 所有, 如有侵权,请联系我们删除。