十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
[TOC]
创新互联是一家集网站建设,达川企业网站建设,达川品牌网站建设,网站定制,达川网站建设报价,网络营销,网络优化,达川网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
简介:
Spring Cloud Gateway是Spring Cloud体系的第二代网关组件,基于Spring 5.0的新特性WebFlux进行开发,底层网络通信框架使用的是Netty,所以其吞吐量高、性能强劲,未来将会取代第一代的网关组件Zuul。Spring Cloud Gateway可以通过服务发现组件自动转发请求,默认集成了Ribbon做负载均衡,以及默认使用Hystrix对网关进行保护,当然也可以选择其他的容错组件,例如Sentinel
优点:
- 性能强劲:是第一代网关Zuul的1.6倍
- 功能强大:内置了很多实用的功能,例如转发、监控、限流等
- 设计优雅,容易扩展
缺点:
- 其实现依赖Netty与WebFlux,不是传统的Servlet编程模型,有一定的学习成本
- 不能在Servlet容器下工作,也不能构建成WAR包,即不能将其部署在Tomcat、Jetty等Servlet容器里,只能打成jar包执行
- 不支持Spring Boot 1.x,需2.0及更高的版本
如果对网关概念或Zuul不了解的话,可以参考另一篇文章:
核心概念:
1、Route(路由):
Spring Cloud Gateway的基础元素,可简单理解成一条转发规则。包含:ID、目标URL、Predicate集合以及Filter集合
这是一段比较典型的Gateway路由配置:
spring:
cloud:
gateway:
routes:
- id: user-center # 唯一标识,通常使用服务id
uri: lb://user-center # 目标URL,lb代表从注册中心获取服务,lb是Load Balance的缩写
predicates:
# Predicate集合
- Path=/zj/cloud/v1/user-center/** # 匹配转发路径
filters:
# Filter集合
- StripPrefix=4 # 从第几级开始转发
2、Predicate(谓词):
即
java.util.function.Predicate
这个接口,Gateway使用Predicate实现路由的匹配条件
3、Filter(过滤器):
与我们平时使用的Servlet编程模型里的过滤器概念类似,同样可以用于修改请求以及响应数据,可以利用Filter实现鉴权、访问日志记录,接口耗时记录等功能
Spring Cloud Gateway架构图:
简单解读一下这个图:
Gateway Client发送请求给Spring Cloud Gateway,Gateway Handler Mapping会判断请求的路径是否匹配路由的配置,如果匹配则会进入Gateway Web Handler,Web Handler会读取路由上所配置的过滤器,然后将该请求交给过滤器去处理,最后转发到路由配置的微服务上
- Gateway Client:泛指外部请求,例如浏览器、app、小程序等
- Proxied Service:指的是被网关代理的微服务
相关源码:
org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping
org.springframework.cloud.gateway.handler.FilteringWebHandler
由于Webflux大量运用函数式编程思想,所以本文中的示例代码都会使用lambda表达式及函数式API来简化。若对此不了解的话,可以参考相关文章,篇幅有限这里就不进行介绍了:
这里使用IDEA的Spring Initializr进行项目的创建,到选择依赖这一步勾选gateway依赖,如下图:
网关组件一般都配合服务发现组件使用,我这里使用Nacos作为服务发现组件,具体的依赖如下:
org.springframework.cloud
spring-cloud-starter-gateway
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
org.springframework.boot
spring-boot-starter-actuator
org.springframework.boot
spring-boot-starter-test
test
org.springframework.cloud
spring-cloud-dependencies
Greenwich.SR2
pom
import
com.alibaba.cloud
spring-cloud-alibaba-dependencies
2.1.0.RELEASE
pom
import
如果对Nacos不熟悉的话可以参考另一篇关于Nacos的文章,或者采用Eureka也是一样的:
然后编写配置文件内容如下:
server:
port: 8040
spring:
application:
name: gateway
cloud:
nacos:
discovery:
# 指定nacos server的地址
server-addr: 127.0.0.1:8848
gateway:
discovery:
locator:
# 让gateway通过服务发现组件找到其他的微服务,从而自动转发请求
enabled: true
# actuator相关配置
management:
endpoints:
web:
exposure:
# 暴露所有监控端点
include: '*'
endpoint:
health:
# 总是显示健康检测详情
show-details: always
完成以上步骤后,我们来启动这个网关服务,进行一个简单的测试,看看是否能将请求正常地转发到指定的微服务上。此时有一个名为user-center
的微服务,该微服务有一个按id获取用户信息的接口,接口路径为/users/{id}
。若通过网关服务来访问这个接口,要如何做呢?很简单,gateway配合服务发现组件使用时,会有一个默认的转发规则,如下:
${GATEWAY_URL}/{微服务名称}/{接口路径}
所以按该规则得出来的具体url为:localhost:8040/user-center/users/{id}
,访问结果如下:
从测试结果可以看到,gateway可以根据url上的微服务名称将访问请求转发到该微服务上。
以上这种是Gateway最简单的使用方式,但通常在实际开发中,可能不希望使用默认的转发规则,因为这种方式不太灵活,例如一些服务接口是存在版本划分的,需要根据不同版本的访问路径转发到不同版本的微服务上。此时就需要自定义转发路由,实际上在第一小节的时候就已经给出过配置示例了。修改配置如下:
spring:
cloud:
gateway:
routes:
- id: user-center # 唯一标识,通常使用服务id
uri: lb://user-center # 目标URL,lb代表从注册中心获取服务
predicates:
# Predicate集合
- Path=/zj/cloud/v1/user-center/** # 匹配转发路径
filters:
# Filter集合
- StripPrefix=4 # 从第几级开始转发,数字从0开始
自定义路由的注意事项:
predicates
配置项必须有,且必须配置一个及以上的Predicate
,但不一定非要配置Path
,可以配置其他的Predicate
,例如After
、Before
等,此时Path
的默认值为/**
重启项目,此时访问的url为:localhost:8040/zj/cloud/v1/user-center/users/{id}
,访问结果如下:
Spring Cloud Gateway的路由配置有两种形式,分别是路由到指定的URL以及路由到指定的微服务,在上一小节的示例中我们就已经使用过路由到微服务的这种配置形式了。在这两种形式中,均支持访问路径的通配及精确匹配,在之前的示例中我们只使用了通配。所以本小节将给出具体的配置示例,以此直观的了解这两种形式及不同匹配方式在配置上的区别。
通配,使用通配符/**
进行匹配,示例:
spring:
cloud:
gateway:
routes:
- id: test_route # 路由的唯一标识
uri: http://www.xxx.com
predicates:
# 使用通配符匹配
- Path=/**
GATEWAY_URL/**
时会转发到 http://www.xxx.com/**
精确匹配,配置具体的接口路径即可,示例:
spring:
cloud:
gateway:
routes:
- id: test_route # 路由的唯一标识
uri: http://www.xxx.com/user/order/detail
predicates:
# 指定具体的路径进行匹配
- Path=/user/order/detail
GATEWAY_URL/user/order/detail
时会转发到 http://www.xxx.com/user/order/detail
通配,示例:
spring:
cloud:
gateway:
routes:
- id: user-center # 路由的唯一标识,这种形式下通常是微服务名称
uri: lb://user-center # lb代表从注册中心获取服务
predicates:
# 使用通配符匹配
- Path=/**
GATEWAY_URL/**
时会转发到 user-center
微服务的/**
精确匹配,示例:
spring:
cloud:
gateway:
routes:
- id: user-center # 路由的唯一标识,这种形式下通常是微服务名称
uri: lb://user-center/users/info # lb代表从注册中心获取服务
predicates:
# 指定具体的路径进行匹配
- Path=/users/info
GATEWAY_URL/users/info
时会转发到 user-center
微服务的/users/info
前面提到过谓词是路由的判断条件,而路由谓词工厂就是作用到指定路由上的一堆谓词判断条件。在之前的示例里,我们就已经使用过路由谓词工厂了,就是自定义转发路径时所配置的Path。
Spring Cloud Gateway内置了众多路由谓词工厂,这些路由谓词工厂为路由匹配的判断提供了有力的支持,而我们之前所使用的Path就是内置的路由谓词工厂之一,用于判断当前访问的接口路径是否与该路由所配置的路径相匹配,若匹配则进行转发。由于Gateway内置的路由谓词工厂比较多,篇幅有限就不在本文中介绍了,可以参考另一篇文章:
现在我们已经知道Spring Cloud Gateway内置了一系列的路由谓词工厂,但如果这些内置的路由谓词工厂不能满足业务需求的话,我们可以自定义路由谓词工厂来实现特定的需求。例如有某个服务限制用户只允许在09:00 - 17:00这个时间段内才可以访问,内置的路由谓词工厂是无法满足这个需求的,所以此时我们就需要自定义能够实现该需求的路由谓词工厂。
首先定义一个配置类,用于承载时间段的配置参数:
@Data
public class TimeBetweenConfig {
/**
* 开始时间
*/
private LocalTime start;
/**
* 结束时间
*/
private LocalTime end;
}
然后定义一个路由谓词工厂,具体代码如下:
package com.zj.node.gateway.predicate;
import com.zj.node.gateway.config.TimeBetweenConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.handler.predicate.AbstractRoutePredicateFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import java.time.LocalTime;
import java.util.Arrays;
import java.util.List;
import java.util.function.Predicate;
/**
* 路由谓词工厂必须以RoutePredicateFactory结尾,
* 这是Spring Cloud Gateway的约定
*
* @author 01
* @date 2019-08-14
**/
@Slf4j
@Component
public class TimeBetweenRoutePredicateFactory extends AbstractRoutePredicateFactory {
public TimeBetweenRoutePredicateFactory() {
super(TimeBetweenConfig.class);
}
/**
* 实现谓词判断的方法
*/
@Override
public Predicate apply(TimeBetweenConfig config) {
return exchange -> {
LocalTime start = config.getStart();
LocalTime end = config.getEnd();
// 判断当前时间是否为允许访问的时间段内
LocalTime now = LocalTime.now();
return now.isAfter(start) && now.isBefore(end);
};
}
/**
* 控制配置类(TimeBetweenConfig)属性和配置文件中配置项(TimeBetween)的映射关系
*/
@Override
public List shortcutFieldOrder() {
/*
* 例如我们的配置项是:TimeBetween=上午9:00, 下午5:00
* 那么按照顺序,start对应的是上午9:00;end对应的是下午5:00
**/
return Arrays.asList("start", "end");
}
}
最后需要在配置文件中启用该路由谓词工厂,并且需要禁止gateway通过服务发现组件转发请求到其他的微服务,修改Gateway相关配置如下:
spring:
cloud:
gateway:
discovery:
locator:
# 禁止gateway通过服务发现组件转发请求到其他的微服务
enabled: false
routes:
- id: user-center
# 目标URL,lb代表从注册中心获取服务
uri: lb://user-center
predicates:
# 注意名称必须为路由谓词工厂类名的前缀,参数为允许访问的时间段
- TimeBetween=上午9:00,下午5:00
可以看到这里主要是配置了我们自定义的路由谓词工厂类名的前缀以及允许访问的时间段,这个时间格式不是随便配置的,而是Spring Cloud Gateway的默认时间格式,相关源码如下:
org.springframework.format.support.DefaultFormattingConversionService#addDefaultFormatters
时间格式是可以注册的,关于时间格式注册的相关源码如下:
org.springframework.format.datetime.standard.DateTimeFormatterRegistrar#registerFormatters
另外,这里之所以要禁止gateway通过服务发现组件转发请求到其他的微服务,是因为开启该配置项的话会导致我们自定义的路由谓词工厂不生效。不生效也是有原因的,开启该配置项会令Gateway优先将请求按照该配置项进行转发,那么我们自定义的路由就不会生效。
到此为止我们就实现了一个自定义路由谓词工厂,若此时不在允许的访问时间段内,访问就会报404,如下:
前面提到了过滤器可以为请求和响应添加一些业务逻辑或者修改请求和响应对象等,适当地使用过滤器可以让我们的工作事半功倍,而本小节将要介绍的过滤器工厂就是用来创建过滤器的。在此之前我们已经学习过路由谓词工厂了,而过滤器工厂与路由谓词工厂在使用上是类似的,只不过实现的功能不一样。
同样的Spring Cloud Gateway内置了非常多的过滤器工厂,有二十多个。通过这些内置的过滤器工厂就已经可以灵活且方便地处理请求和响应数据,由于Gateway内置的过滤器工厂实在太多,而篇幅有限就不在本文中介绍了,可以参考另一篇文章:
若Spring Cloud Gateway内置的过滤器工厂无法满足我们的业务需求,那么此时就需要自定义自己的过滤器工厂以实现特定功能。所谓过滤器工厂实际上就是用于创建过滤器实例的,而创建的过滤器实例都实现于GatewayFilter
接口。
过滤器的生命周期:
自定义过滤器工厂的方式:
继承AbstractGatewayFilterFactory
,参考源码:org.springframework.cloud.gateway.filter.factory.RequestSizeGatewayFilterFactory
。使用该方式实现的过滤器工厂的配置形式如下:
spring:
cloud:
gateway:
routes:
filters:
# 过滤器工厂的名称
- name: RequestSize
# 该过滤器工厂的参数
args:
maxSize: 500000
AbstractNameValueGatewayFilterFactory
,参考源码:org.springframework.cloud.gateway.filter.factory.AddRequestHeaderGatewayFilterFactory
。使用该方式实现的过滤器工厂的配置形式如下:
spring:
cloud:
gateway:
routes:
filters:
# 过滤器工厂的名称及参数以name-value的形式配置
- AddRequestHeader=S-Header, Bar
注:AbstractNameValueGatewayFilterFactory
继承了AbstractGatewayFilterFactory
,所以实际上第二种方式是第一种方式的简化
核心API:
exchange.getRequest().mutate().xxx
:修改requestexchange.mutate().xxx
:修改exchangechain.filter(exchange)
:传递给下一个过滤器处理exchange.getResponse()
:获取响应对象注:这里的exchange
实际类型为ServerWebExchange
,chain
实际类型为GatewayFilter
最后我们来实际动手编写一个自定义过滤器工厂,需求是记录访问日志,这里为了简单起见采用第二种方式实现,具体代码如下:
package com.zj.node.gateway.filter;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.factory.AbstractNameValueGatewayFilterFactory;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
/**
* 过滤器工厂必须以GatewayFilterFactory结尾,
* 这是Spring Cloud Gateway的约定
*
* @author 01
* @date 2019-08-15
**/
@Slf4j
@Component
public class PreLogGatewayFilterFactory extends AbstractNameValueGatewayFilterFactory {
@Override
public GatewayFilter apply(NameValueConfig config) {
// 使用lambda表达式来创建GatewayFilter的实例,实际就是匿名内部类的简写
return (exchange, chain) -> {
// 通过config获取配置的参数
log.info("配置参数:{}, {}", config.getName(), config.getValue());
// 修改request,可以添加一些header什么的
ServerHttpRequest modifiedRequest = exchange.getRequest()
.mutate()
.header("X-GatewayHeader","A","B")
.build();
// 打印访问的接口地址
String path = modifiedRequest.getURI().getPath();
log.info("访问的接口为:{}", path);
// 修改exchange
ServerWebExchange modifiedExchange = exchange.mutate()
.request(modifiedRequest).build();
// 传递给下一个过滤器处理
return chain.filter(modifiedExchange);
};
}
}
最后需要添加相关配置以启用这个过滤器工厂,如下:
spring:
cloud:
gateway:
routes:
- id: user-center
uri: lb://user-center
predicates:
- TimeBetween=上午9:00,下午5:00
filters:
# 名称必须为过滤器工厂类名的前缀,并且参数只能有两个,因为NameValueConfig里只定义了两个属性
- PreLog=testName,testValue
启动项目,访问user-center的接口,此时控制台输出的日志如下:
现在我们已经知道前面所介绍的过滤器工厂实际用于创建GatewayFilter
实例,并且这些GatewayFilter
实例仅作用于指定的路由上,那么有没有可以作用于全部路由上的过滤器呢?答案是有的,这就是本小节将要介绍的全局过滤器。Spring Cloud Gateway默认就内置了许多全局过滤器,本文仅介绍如何自定义全局过滤器,关于Gateway内置的过滤器可以参考另一篇文章:
自定义全局过滤需要实现GlobalFilter
接口,该接口和 GatewayFilter
有一样的方法定义,只不过 GlobalFilter
的实例会作用于所有的路由。
Tips:
官方声明:
GlobalFilter
的接口定义以及用法在未来的版本可能会发生变化。个人判断:
GlobalFilter
可用于生产;如果有自定义GlobalFilter
的需求,理论上也可放心使用。因为未来即使接口定义以及使用方式发生变化,理应也是平滑过渡的(比如Zuul的Fallback,原先叫ZuulFallbackProvider
,后来改叫FallbackProvider
,中间就有段时间新旧使用方式都支持,后面才逐步废弃老的使用方式)。
接下来我们自定义一个全局过滤器,需求是打印访问的接口路径以及打印该接口的访问耗时。具体代码如下:
package com.zj.node.gateway.filter;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;
/**
* 自定义全局过滤器
*
* @author 01
* @date 2019-08-17
**/
@Slf4j
public class MyGlobalFilter implements GlobalFilter {
@Override
public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
String path = exchange.getRequest().getURI().getPath();
log.info("[MyGlobalFilter] 访问的接口:{}", path);
long start = System.currentTimeMillis();
return chain.filter(exchange)
// then的内容会在过滤器返回的时候执行,即最后执行
.then(Mono.fromRunnable(() ->
log.info("[ {} ] 接口的访问耗时:{} /ms",
path, System.currentTimeMillis() - start))
);
}
}
最后需要使该全局过滤器生效,方法有很多种,可以直接在该类上加@Component
注解,也可以通过代码配置(@Bean
),还有其他的一些方式。这里个人比较倾向于使用一个专门的配置类去实例化这些全局过滤器并交给Spring容器管理。代码如下:
package com.zj.node.gateway.config;
import com.zj.node.gateway.filter.MyGlobalFilter;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
@Slf4j
@Configuration
public class FilterConfig {
@Bean
// 该注解用于指定过滤器的执行顺序,数字越小越优先执行
@Order(Ordered.HIGHEST_PRECEDENCE)
public GlobalFilter myGlobalFilter(){
log.info("create myGlobalFilter...");
return new MyGlobalFilter();
}
}
启动项目,看看我们自定义的全局过滤器是否已生效,访问Gateway控制台输出如下: