先去看下官网的解释:
This project provides an API Gateway built on top of the Spring Ecosystem, including: Spring 6, Spring Boot 3 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.
Spring提供了一个API网关,基于Spring 6、Spring Boot 3以及Project Reactor。目标是提供一个简单、有效的方式进行API路由,以及安全、监控等众多项目的公共需求。
这个描述其实很简单,但是我们需要了解一个背景知识:安全、权限、监控、系统弹性等需求是每一个系统或模块的公共需求,这类需求的解决方案可以是在每一个模块中处理,但显而易见的弊端是相同的处理逻辑会在每一个模块中重复实现,增加系统的复杂性,降低系统的可维护性。
Spring Cloud Gateway可以完美解决以上问题,集中处理鉴权、安全、监控、流量监控等公共需求,并可实现对最终用户隐藏真实的业务调用接口,避免业务接口的细节的对外暴露。
下图展示了Spring Cloud网关的工作原理:
客户端发送请求给spring cloud网关而不是真实的业务服务端(这种情况下网关的作用类似于反向代理nginx),网关的Gateway Handle Mapping判断Predicate符合的话在转发请求给Gateway Web Handle,之后Gateway Web Handle调用Filters处理后将请求发送给被代理的各业务服务(网关uri定义的)。
有没有发现上图比较眼熟?是不是和Servlet+Spring MVC处理请求的过程很类似?
Filters组成filters chain,像剥洋葱一样逐个调用,先执行各过滤器的before逻辑,调用完Proxied Service之后再执行after逻辑。
我们在前面案例的基础上,增加Spring Cloud Gateway模块。
项目中引入Spring Cloud Gateway,pom文件:
springCloud
com.example
0.0.1-SNAPSHOT
4.0.0
springgateway
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
org.springframework.cloud
spring-cloud-starter-gateway
17
17
注意Spring Cloud Gateway不能是SpringMVC项目,所以pom文件中不能引入spring-boot-starter-web,否则项目启动不了。
然后配置yam文件:
spring:
application:
name: spring-gateway
cloud:
gateway:
routes:
- id: path_route
uri: http://127.0.0.1:9090
predicates:
- Path=/order/*
eureka:
client:
service-url: # eureka service
defaultZone: http://127.0.0.1:10086/eureka/
server:
port: 9095
在applicaton.yml文件中配置一个route:
id: 任意一个名字就可以,但是需要唯一。
uri:断言判断匹配成功之后的路由地址,指向proxied service
predicates:断言,配置为Path断言,判断请求路径中是否包含/order
Spring Cloud Gateway提供了很多断言工厂:
我们的案例使用path断言工厂,path断言工厂负责根据请求路径进行匹配。
我们把Spring Cloud Gateway也配置为Eureka客户端,放在注册中心统一管理,后面我们可以看到,Spring Cloud Gateway支持通过注册中心进行路由。
上面的配置很简单,判断请求路径中如果包含/order的话,将请求路由到http://127.0.0.1:9090去处理。
依次启动Eureka、orderservice、orderservice以及springGateway service:
gateway启动在端口9095,端都9090是orderservice。
看一下10086端口的Eureka注册中心:
发现orderservice、userservice以及spring-gateway都已经在Eureka注册中心完成注册。
接下来访问9095端口的gateway服务:
说明Spring Cloud Gateway已经开始正常工作了,能够路由的orderservice服务。
上面路由配置直接指向了 http://127.0.0.1:9090,只能访问到指定的应用,无法访问到spring loadbalance提供的负载均衡服务。
下面我们尝试通过注册中心访问服务、并享受到spring loadbalance提供的负载均衡服务。
前面的案例访问orderservice后,会通过orderservice访问userservice的服务。现在我们是为了验证gateway,简单起见,我们暂时去掉userservice,通过网关gateway访问orderservice、由orderservice直接提供服务,不再访问userservice了。
为此,简单改造一下orderservice的orderController,不再调用userservice了,直接返回当前orderservice的端口:
package com.example.controller;
@RestController
@RequestMapping("/order")
@Slf4j
public class OrderController {
@Value("${server.port}")
private String serverPort;
@Autowired
OrderService orderService;
@Autowired
FallbackHandle fallbackHandle;
@GetMapping("/getOrder")
@HystrixCommand(fallbackMethod = "fallback",commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "5000")
})
public String getOrder(){
log.info("Come here to get Order....123===");
return "order service from:"+serverPort;
// return orderService.getOrder();
}
public String fallback(){
return "orderService服务异常";
}
}
重新启动服务,访问网关:
说明网关服务、以及改造后的orderservice都能正常工作了。
copy一份orderservice的配置,在9091端口再启动一个orderservice服务:
启动服务后,检查Eureka注册中心:
发现9090/9091端口分别由一个orderservice注册到了Eureka注册中心。
下面我们修改一下网关服务的配置:
spring:
application:
name: spring-gateway
cloud:
gateway:
routes:
- id: path_route
uri: lb://orderservice
predicates:
- Path=/order/*
eureka:
client:
service-url: # eureka service
defaultZone: http://127.0.0.1:10086/eureka/
server:
port: 9095
断言匹配成功后,通过Eureka注册中心以及loadbalance路由到orderservice服务。
启动服务,访问验证:
可以发现,不需要太多的配置,Spring Cloud Gateway已经可以通过Spring Eureka注册中心获取到注册的服务、并通过Spring LoadBalance负载均衡策略访问到服务了。
通过简单的配置,我们现在的应用其实已经具备了微服务的注册中心、负载均衡、网关等强大能力了!
过滤器的作用原理我们在开篇说过了,过滤器可以修改请求的request或response,或者对请求进行某种控制,从而实现众多附加功能,比如修改头信息、修改请求参数、权限验证、超时控制等等。
Spring Cloud Gateway的过滤去分为路由过滤器和全局过滤器,路由过滤器作用范围是当前匹配到的路由,全局过滤器的作用范围是全局(所有路由)。
Spring Cloud Gateway提供了众多内置的路由过滤器:
以及内置的全局过滤器:
当请求匹配之后,路由过滤器以及全局过滤器会被装配成filterChain,filterChain装配的过程中,过滤器会按照org.springframework.core.Ordered接口进行排序,按顺序调用。
As Spring Cloud Gateway distinguishes between “pre” and “post” phases for filter logic execution (see How it Works), the filter with the highest precedence is the first in the “pre”-phase and the last in the “post”-phase.
高优先级的过滤器意味着早一些被 pre-phase阶段调用、晚一些被post-phase阶段调用。也就是说,高优先级针对的是请求服务之前的处理,和Servlet的过滤器的优先顺序类似。
除了Spring Cloud Gateway提供的内置过滤器之外,我们还可以实现自己的过滤器。
我们可以通过实现接口GatewayFilterFactory从而实现自己的路由过滤器。
Spring Cloud Filter提供了一个虚拟类AbstractGatewayFilterFactory,我们可以扩展该类实现自己的路由过滤器,比如我们创建一个MyGatewayFilterFactory :
package com.example.filter;
@Component
@Slf4j
public class MyGatewayFilterFactory extends AbstractGatewayFilterFactory {
public MyGatewayFilterFactory() {
super(Config.class);
}
@Override
public GatewayFilter apply(Config config) {
// grab configuration from Config object
log.info("filter:"+config.getName());
return (exchange, chain) -> {
//If you want to build a "pre" filter you need to manipulate the
//request before calling chain.filter
//获取request
ServerHttpRequest request = exchange.getRequest();
//从request中获取用户信息,进行用户鉴权......之后
log.info("This is pre filter===");
return chain.filter(exchange).then(Mono.fromRunnable(()-> {
ServerHttpResponse response = exchange.getResponse();
response.getHeaders().add("Auth","xxxx.yyyy.zzzz");
log.info("this is after filter");
}));
};
}
public static class Config {
//Put the configuration properties for your filter here
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
}
需要通过@Component注解将过滤器加入到Spring容器中。
通过Config接收一个name参数,在apply方法中可以实现路由前置、以及路由后置过滤逻辑。我们的MyGatewayFilterFactory 同时实现了前置逻辑和后置逻辑,前置逻辑中可以添加用户鉴权等代码,简单起见,我们只是log打印一句话。后置逻辑中同样很简单,打印一句话,设置一个reponse header。
上面我们实现的是漏油过滤器,所以只有配置在某一路由上才会生效:
spring:
application:
name: spring-gateway
cloud:
gateway:
routes:
- id: path_route
# uri: http://127.0.0.1:9090
uri: lb://orderservice
predicates:
- Path=/order/*
filters:
- name: My
args:
name: My own pre-filter
eureka:
client:
service-url: # eureka service
defaultZone: http://127.0.0.1:10086/eureka/
server:
port: 9095
启动服务,测试:
首先从前端请求中发现response header已经成功添加。然后看一下后台log:
我们自己的路由过滤器已经可以正常工作了。
全局过滤器需要实现GlobalFilter 接口:
package com.example.filter;
@Component
@Slf4j
public class MyGlobalGatewayFilter implements GlobalFilter {
@Override
public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
log.info("Here i can do anything to exchage");
return chain.filter(exchange).then(Mono.just(exchange)).map(serverWebExchange->{
serverWebExchange.getResponse().getHeaders().add("Global-Filter","Global filter OK");
return serverWebExchange;
}).then();
}
}
同样,我们添加的MyGlobalGatewayFilter 同时实现前置和后置过滤逻辑,不过都非常简单,前置过滤逻辑只是打印一段话,后置过滤逻辑添加一个response header。
全局过滤器是不需要额外配置的,对所有router都生效。
重新启动gateway,测试:
response header已经成功添加。
Ok,我们已经完成了对Spring Cloud Gateway的配置和使用,初步了解了Spring Cloud Gateway的用法,其实使用和配置起来一点都不复杂。
Thanks!