老鸟很过,只做学习使用,欢迎交流
Zuul是Netflix的开源项目,Spring Cloud将其收纳成为自己的一个子组件。zuul用的是多线程阻塞模型,它本质上就是一个同步 Servlet,这样的模型比较简单,他都问题是多线程之间上下文切换是有开销的,线程越多开销就越大。线程池数量固定意味着能力接受的请求数固定,当后台请求变慢,面对大量的请求,线程池中的线程容易被耗尽,后续的请求会被拒绝。
在Zuul 2.0中它采用了 Netty 实现异步非阻塞编程模型,异步非阻塞模式对线程的消耗比较少,对线程上线文切换的消耗也比较小,并且可以接受更多的请求。它的问题就是线程模型比较复杂,要求深究底层原理需要花一些功夫。
Spring Cloud Gateway是Spring Cloud自己的产物,基于Spring 5 和Spring Boot 2.0 开发,Spring Cloud Gateway的出现是为了代替zuul,在Spring Cloud 高版本中没有对zuul 2.0进行集成,SpringCloud Gateway使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway 的目标,不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。
所以说其实Gateway和zuul 2.0差别不是特别大,都是采用Netty高性能通信框架,性能都挺不错。
在Spring Cloud官方定义了SpringCloud Gateway 的如下特点:
基于 Spring 5,Project Reactor , Spring Boot 2.0
默认集成 Hystrix 断路器
默认集成 Spring Cloud DiscoveryClient
Predicates 和 Filters 作用于特定路由,易于编写的 Predicates 和 Filters
支持动态路由、限流、路径重写
Spring Cloud Gataway有几个核心组成:
Spring Cloud Gateway的Filter和Zuul的过滤器类似,可以在请求发出前后进行一些业务上的处理 ,这里分为两种类型的Filter,分别是Gateway Filter网关filter和Global Filter全局Filter, 他们的区别在后续会讲到。
网关配置的基本组成模块,和Zuul的路由配置模块类似。一个Route模块由一个 ID,一个目标 URI,一组断言和一组过滤器定义。如果断言为真,则路由匹配,目标URI会被访问。说白了就是把url请求路由到对应的资源(服务),或者说是一个请求过来Gateway应该怎么把这个请求转发给下游的微服务,转发给谁。
这是一个 Java 8 的 Predicate,可以使用它来匹配来自 HTTP 请求的任何内容,例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。简单理解就是处理HTTP请求的匹配规则,在什么样的请情况下才能命中资源继续访问。
Spring Cloud Gateway 的工作原理跟 Zuul 的差不多,最大的区别就是 Gateway 的 Filter 只有 pre 和 post 两种,下面是官方的执行流程图:
客户端向Spring Cloud Gateway发出请求。如果网关处理程序映射确定请求与路由匹配,则将其发送到网关Web处理程序。该处理程序通过特定于请求的过滤器链来运行请求。筛选器由虚线分隔的原因是,筛选器可以在发送代理请求之前和之后运行逻辑。所有“前置”过滤器逻辑均被执行。然后发出代理请求。发出代理请求后,将运行“后”过滤器逻辑。
工程名:springcloud-gateway-server-1110 ,导入gataway基础依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-gatewayartifactId>
dependency>
//服务注册与发现
@SpringBootApplication
@EnableDiscoveryClient
public class GatewayServerApplication1110 {
public static void main(String[] args) {
SpringApplication.run(GatewayServerApplication1110 .class);
}
}
eureka:
client:
serviceUrl:
defaultZone: http://peer1:1010/eureka/,http://peer2:1011/eureka/,http://peer3:1012/eureka/
instance:
prefer-ip-address: true #使用ip注册到Eureka
instance-id: gateway-server:1110 #指定客户端实例的ID
spring:
application:
name: gateway-server
cloud:
gateway:
discovery:
locator:
enabled: false #开放服务名访问方式
lower-case-service-id: true #服务名小写
routes:
- id : application-user #指定服务名
uri: lb://user-server #去注册中心找这个服务名
predicates: #断言,匹配访问的路径
- Path=/user/** #服务访问路径
filters:
- StripPrefix=1 #请求转发的时候会去掉 /user访问路径
server:
port: 1110
这里除了要注册到Eureak以外,还需要配置Gataway的路由
spring.cloud.gateway.discovery.locator.enabled=false
: 不开放服务名访问方式spring.cloud.gateway.discovery.locator.lower-case-service-id: true
忽略服务名大小写,大写小写都可以匹配spring.cloud.gateway.routes.id
: 指定了路由的服务名,可以自己定义spring.cloud.gateway.routes.uri=lb://user-server
: 去注册中心找服务,采用负载均衡的方式请求。其实就是找要调用的服务。spring.cloud.gateway.routes.predicates
: 断言,这里使用的Path=/user/**,即匹配访问的路径如果匹配/user/就可以将请求路由(分发)到user-server这个服务上。spring.cloud.gateway.routes.filters
:这里使用StripPrefix=1主要是处理前缀 /user ,访问目标服务的时候会去掉前缀访问。这个需要根据url情况来定义。启动注册中心,启动用户服务,启动网关访问:http://localhost:1110/user/user/1
,请求将会打到用户服务上,并返回用户数据。
什么是断言工程,在Spring Cloud Gateway官方文档有如下解释:
Spring Cloud Gateway将路由作为Spring WebFlux HandlerMapping基础架构的一部分进行匹配。Spring Cloud Gateway包括许多内置的路由断言工厂。所有这些断言都与HTTP请求的不同属性匹配。您可以将多个路由断言工厂与逻辑and语句结合使用。
这里不难理解,其实断言工厂就是用来判断http请求的匹配方式。比如我们再上面案例中配置的:“Path=/user/**
” ,就是使用的是 “Path Route Predicate Factory
” 路径匹配工厂,意思是http请求的资源地址必须是 /user 才会被匹配到对应的路由,然后继续执行对应的服务获取资源。
在Spring Cloud Gateway中,针对不同的场景内置的路由断言工厂,比如
Query Route Predicate Factory
:根据查询参数来做路由匹配RemoteAddr Route Predicate Factory
:根据ip来做路由匹配Header Route Predicate Factory
:根据请求头中的参数来路由匹配Host Route Predicate Factory
:根据主机名来进行路由匹配Method Route Predicate Factory
:根据方法来路由匹配Cookie Route Predicate Factory
:根据cookie中的属性值来匹配Before Route Predicate Factory
:指定时间之间才能匹配After Route Predicate Factory
: 指定时间之前才能匹配Weight Route Predicate Factory
: 根据权重把流量分发到不同的主机spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- Query=green
上面配置表达的试试是如果请求参数中包含了 green,那么就会断言成功,从而执行uri后面的地址。
spring:
cloud:
gateway:
routes:
- id: path_route
uri: https://example.org
predicates:
- Path=/red/{segment},/blue/{segment}
请求路径如: /red/1
或/red/blue
或/blue/green
就可以断言成功
spring:
cloud:
gateway:
routes:
- id: weight_high
uri: https://weighthigh.org
predicates:
- Weight=group1, 8
- id: weight_low
uri: https://weightlow.org
predicates:
- Weight=group1, 2
大约80%的请求转发到weighthigh.org,将大约20%的流量转发到weightlow.org。
spring:
cloud:
gateway:
routes:
- id: remoteaddr_route
uri: https://example.org
predicates:
- RemoteAddr=192.168.1.1/24
如果请求的远程地址为 192.168.1.1
到192.168.1.24
之间,则此路由匹配
spring:
cloud:
gateway:
routes:
- id: after_route
uri: https://example.org
predicates:
- After=2017-01-20T17:42:47.789-07:00[America/Denver]
在atfer配置的时间之后才能访问
spring:
cloud:
gateway:
routes:
- id: before_route
uri: https://example.org
predicates:
- Before=2017-01-20T17:42:47.789-07:00[America/Denver]
在before配置的时间之前才能访问
spring:
cloud:
gateway:
routes:
- id: between_route
uri: https://example.org
predicates:
- Between=2017-01-20T17:42:47.789-07:00[America/Denver], 2017-01-21T17:42:47.789-07:00[America/Denver]
请求时间在两个时间之内者允许访问
spring:
cloud:
gateway:
routes:
- id: cookie_route
uri: https://example.org
predicates:
- Cookie=chocolate, ch.p
cookies中必须有Cookie配置的属性才能匹配
spring:
cloud:
gateway:
routes:
- id: header_route
uri: https://example.org
predicates:
- Header=X-Request-Id, \d+
请求头必须出现 X-Request-Id 才可以访问
spring:
cloud:
gateway:
routes:
- id: host_route
uri: https://example.org
predicates:
- Host=**.somehost.org,**.anotherhost.org
如果请求的主机头具有值**.somehost.org,或者**.anotherhost.org这匹配路由
spring:
cloud:
gateway:
routes:
- id: method_route
uri: https://example.org
predicates:
- Method=GET,POST
只允许 GET和POST请求
Gateway的Filter的zuul的Filter有相似之处,与zuul不同的是,Gateway的filter从生命周期上可以分为“pre”和“post”类型。根据作用范围可分为针对于单个路由的gateway filter,和针对于所有路由的Global Filer。 官网文档
针对单个路由的Filter, 它允许以某种方式修改HTTP请求或HTTP响应。过滤器可以作用在某些特定的请求路径上。Gateway内置了很多的GatewayFilter工厂。如果要使用这些Filter只需要在配置文件配置GatewayFilter Factory的名称。下面拿一个内置的Gateway Filter举例:
AddRequestHeader GatewayFilter Factory
该Filter是Gateway内置的,它的作用是在请求头加上指定的属性。配置如下:
spring:
cloud:
gateway:
routes:
- id: add_request_header_route
uri: https://example.org
filters:
- AddRequestHeader=X-Request-red, blue
在spring.cloud.gateway.routes.filters
配置项配置了一个AddRequestHeader
,他是“AddRequestHeader GatewayFilter Factory
”的名称,意思是在请求头中添加一个“X-Request-red
”的属性,值为blue
。
其他的Filter可以去看 AbstractGatewayFilterFactory 的实现类。
在Spring Cloud Gateway自定义过滤器,过滤器需要实现GatewayFilter和Ordered这两个接口。我们下面来演示自定义filter计算请求的耗时。
public class RequestTimeFilter implements GatewayFilter, Ordered {
private static final Log log = LogFactory.getLog(GatewayFilter.class);
private static final String COUNT_Start_TIME = "countStartTime";
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
//开始时间
exchange.getAttributes().put(COUNT_Start_TIME, System.currentTimeMillis());
//执行完成之后
return chain.filter(exchange).then(
Mono.fromRunnable(() -> {
//开始时间
Long startTime = exchange.getAttribute(COUNT_Start_TIME);
//结束时间
Long endTime=(System.currentTimeMillis() - startTime);
if (startTime != null) {
log.info(exchange.getRequest().getURI().getRawPath() + ": " + endTime + "ms");
}
})
);
}
@Override
public int getOrder() {
return Ordered.LOWEST_PRECEDENCE;
}
}
提示: getOrder返回filter的优先级,越大的值优先级越低 , 在filterI方法中计算了请求的开始时间和结束时间
最后我们还需要把该Filter配置在对应的路由上,配置如下:
@Configuration
public class FilterConfig {
//配置TokenCheckFilter作用于那个访问规则上
@Bean
public RouteLocator customerRouteLocator(RouteLocatorBuilder builder) {
return builder.routes()
.route(r -> r.path("/user/**")
.filters(f -> f.stripPrefix(1)
.filter(new RequestTimeFilter())
.addResponseHeader("X-Response-test", "test"))
.uri("lb://user-server")
.order(0)
.id("test-RequestTimeFilter")
)
.build();
}
}
提示:这里将 RequestTimeFilter 添加到 “/user/**”这里路由上,当请求包含/user就会触发Filter的执行。
GlobalFilter:全局过滤器,不需要在配置文件中配置,作用在所有的路由上,最终通过GatewayFilterAdapter包装成GatewayFilterChain可识别的过滤器,它为请求业务以及路由的URI转换为真实业务服务的请求地址的核心过滤器,不需要配置,系统初始化时加载,并作用在每个路由上。
这里我们模拟了一个登陆检查的Filter.
@Component
public class TokenFilter implements GlobalFilter , Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
//获取请求中的token
String token = exchange.getRequest().getQueryParams().getFirst("authToken");
if (token == null || token.isEmpty()) {
//访问没有权限
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
//返回结果,不会继续往后执行
return exchange.getResponse().setComplete();
}
//放行
return chain.filter(exchange);
}
@Override
public int getOrder() {
return -200;
}
}
如果请求参数中没有 authToken ,就返回咩有权限的状态吗。
所谓的跨域是因为浏览器的同源(同一个域)策略限制,其实就是同源策略会阻止一个域的javascript脚本和另外一个域的内容进行交互 ,在前后端分离的项目架构中就会出现跨域问题,因为Gateway 网关是微服务的访问入口,所以我们只需要在Gateway配置跨域即可:官方文档
spring:
cloud:
globalcors: #跨域配置
cors-configurations:
'[/**]':
allowedOrigins: "https://docs.spring.io" #允许的站点
allowedMethods: #允许的请求方式
- GET
- POST
- DELETE
- PUT
- HEAD
- CONNECT
- TRACE
- OPTIONS
allowHeaders: #允许的请求头
- Content-Type
提示:运行跨域访问的站点:https://docs.spring.io ,同时把常见的请求方式都开放。
我们再《Spring Cloud极简入门》中有学习到Hystrix的熔断,在zuul中也有去开启Hystrix熔断,Hystrix作为微服务的安全保护机制,而Gateway作为微服务的访问入口和出口,集成Hystrix熔断机制也是必要的。
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrixartifactId>
dependency>
spring:
cloud:
gateway:
routes:
- id: hystrix_route #路由的ID,没有固定规则,但是要唯一
uri: lb://user-server #跳转的服务
predicates:
- Path=/user/** #path路径
filters:
- name: Hystrix
args:
name: fallbackcmd
fallbackUri: forward:/fallback
- StripPrefix=1
hystrix:
command:
fallbackcmd:
execution:
isolation:
thread:
timeoutInMilliseconds: 5000 #超时时间,熔断
这里的name:hystrix
其实是对应了HystrixGatewayFilterFactory
,它是一个Hystrix熔断的filter工厂。
配置了两个参数,一个是 name: fallbackcmd作为名称生成HystrixCommand对象进行熔断处理
fallbackUri: forward:/fallback : 是熔断后的回调方法,其实就是降级方法。
对应了配置中的fallbackUri
@RestController
public class GatewayController {
@RequestMapping(value = "/fallback")
public String fallback(){
return "fallback 。。。。。。";
}
}
当流量过大时,Gateway对服务进行限流可以提升服务的稳定性和可用性,其目的是现在对请求/并发数进行限制,一旦请求达到限定的速率就可以进行请求的拒绝,排队,或降级。
在Spring Cloud Gateway中提供了 RequestRateLimiterGatewayFilterFactory 用来做限流,适用在 Redis 内的通过执行 Lua 脚本实现了令牌桶的方式。限流配置如下:
spring:
cloud:
gateway:
routes:
- id: application-user
uri: lb://application-user
predicates:
- Path=/user/**
filters:
- name: RequestRateLimiter
args:
key-resolver: "#{@hostAddrKeyResolver}"
redis-rate-limiter.replenishRate: 1 #令牌通每秒填充平均速率
redis-rate-limiter.burstCapacity: 3 #令牌桶总数量
- StripPrefix=1
redis:
host: localhost
port: 6379
提示:这里了Redis的主机和端口,filters.name=RequestRateLimiter 指向的是RequestRateLimiterGatewayFilterFactory 限流filter, 配置了三个参数
Key-resolver参数跟的是IOC容器中bean的名字,是需要我们自己定义一个Bean,例如以ip限流为例,添加以下代码:
public class HostAddrKeyResolver implements KeyResolver {
@Override
public Mono<String> resolve(ServerWebExchange exchange) {
//获取返回ip地址,根据ip限流 , 其他的限流方式也是一样
return Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
}
public HostAddrKeyResolver hostAddrKeyResolver() {
return new HostAddrKeyResolver();
}
}
将该类注册到Spirng的IOC容器中
@Bean
public HostAddrKeyResolver hostAddrKeyResolver(){
return new HostAddrKeyResolver();
}
这里的Bean的名字为 hostAddrKeyResolver ,对应配置中“#{@hostAddrKeyResolver}”
通过简单的配置,Spring Cloud Gateway就可以支持请求重试功能。
spring:
cloud:
gateway:
routes:
- id: user-server-retry
uri: lb://user-server
predicates:
- Path=/user/**
filters:
- name: Retry
args:
retries: 3
series:
- SERVER_ERROR
statuses:
- OK
methods:
- GET
- POST
exceptions:
- java.io.IOException
这里通过四个参数来控制重试机制:
retries:重试次数默认是3 次
statuses:HTTP 的状态返回码,见:HttpStatus
methods:需要重试的请求方式,默认值是 GET 方法,见:HttpMethod
series:一些列的状态码配置,见:HttpStatus.Series。符合的某段状态码才会进行重试逻辑,默认值是 SERVER_ERROR,值是 5,也就是 5XX(5 开头的状态码),共有5个值。
exceptions : 指定哪些异常需要进行重试逻辑,默认值是java.io.IOException
超时配置在微服务调用和数据读取的时候显得尤为重要,线面演示Gateway中的全局超时设置:
spring:
cloud:
gateway:
httpclient:
connect-timeout: 1000
response-timeout: 5s
指定路由超时配置:
spring:
cloud:
gateway:
routes:
- id: per_route_timeouts
uri: https://example.org
predicates:
- name: Path
args:
pattern: /delay/{timeout}
metadata:
response-timeout: 200
connect-timeout: 200
本篇文章介绍了Spring Cloud Gateway的一些常用技能,希望对小伙伴有帮助。