Gateway源码分析
1. GateWay的自动配置
springboot 在引入一个新的组件时，一般都会有对应的XxxAutoConfiguration类来对该组件进行配置，GateWay也不例外，在引入了以下配置后，就会生成对应的GatewayAutoConfiguration自动配置类
<!-- gateway网关 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
GatewayAutoConfiguration自动配置类信息如下：
@Configuration(proxyBeanMethods = false)
//spring.cloud.gateway.enabled配置项必须为true，自动配置才生效，默认为true
@ConditionalOnProperty(name = "spring.cloud.gateway.enabled", matchIfMissing = true)
@EnableConfigurationProperties
//自动配置前置条件：引入了WebFlux 和 HttpHandler 组件
@AutoConfigureBefore({ HttpHandlerAutoConfiguration.class,
WebFluxAutoConfiguration.class })
//自动配置后置组件：负载均衡组件
@AutoConfigureAfter({ GatewayLoadBalancerClientAutoConfiguration.class,
GatewayClassPathWarningAutoConfiguration.class })
@ConditionalOnClass(DispatcherHandler.class)
public class GatewayAutoConfiguration {
..... // 初始化各种bean
}
从配置类上的注解，可以了解到
- spring.cloud.gateway.enabled配置项必须为true，自动配置才生效，默认为true
- 在使用Gataway之前，必须存在WebFlux 和 HttpHandler 组件
- 注入Gataway之后，需要对请求负载到某一台服务器上，所以后置组件为负载均衡组件
自动配置类GatewayAutoConfiguration在内部初始化了很多bean，列举几个重要的如下：
- PropertiesRouteDefinitionLocator：用于从配置文件（yml/properties）中读取路由配置信息！
- RouteDefinitionLocator：把 RouteDefinition 转化为 Route
- RoutePredicateHandlerMapping：类似于 mvc 的HandlerMapping，不过这里是 Gateway实现的。用于匹配对应的请求route
- GatewayProperties：yml配置信息封装在 GatewayProperties 对象中
- AfterRoutePredicateFactory：各种路由断言工厂，正是这些断言工厂在启动时已经生成对应的bean，我们才可以在 yml 中配置一下，即可生效
- RetryGatewayFilterFactory：各种 Gateway 过滤器，正是这些过滤器在启动时已经生成对应的bean，我们才可以在 yml 中配置一下，即可生效
- GlobalFilter实现类：全局过滤器
2. GateWay的源码执行流程
GateWay采用的是webFlux的响应式编程，其整个流程与spring mvc 类似
所有请求都会经过 gateway 的DispatcherHandler中的handle方法！可以看到该方法使用的就是webFlux的响应式编程
@Override
public Mono<Void> handle(ServerWebExchange exchange) {
if (this.handlerMappings == null) {
return createNotFoundError();
}
if (CorsUtils.isPreFlightRequest(exchange.getRequest())) {
return handlePreFlight(exchange);
}
return Flux
// 1.遍历所有的 handlerMapping
.fromIterable(this.handlerMappings)
// 2.获取对应的handlerMapping ，比如常用的 RequestMappingHandlerMapping、RoutePredicateHandlerMapping
.concatMap(mapping -> mapping.getHandler(exchange))
.next()
.switchIfEmpty(createNotFoundError())
// 3.获取对应的适配器，调用对应的处理器
.flatMap(handler -> invokeHandler(exchange, handler))
// 4.返回处理结果
.flatMap(result -> handleResult(exchange, result));
}
其实这就是 gateway的核心逻辑
①：进入路由断言HandlerMapping，扫描yml文件，匹配路由信息 上文核心逻辑代码中getHandler(exchange)方法是获取对应的HandlerMapping。由于是网关组件，当请求进入时，会先判断路由，所以会进入实现类RoutePredicateHandlerMapping中
org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping # getHandlerInternal 方法如下：
@Override
protected Mono<?> getHandlerInternal(ServerWebExchange exchange) {
if (this.managementPortType == DIFFERENT && this.managementPort != null
&& exchange.getRequest().getURI().getPort() == this.managementPort) {
return Mono.empty();
}
exchange.getAttributes().put(GATEWAY_HANDLER_MAPPER_ATTR, getSimpleName());
//寻找并匹配路由
return lookupRoute(exchange)
.flatMap((Function<Route, Mono<?>>) r -> {
//移除上下文中旧的属性
exchange.getAttributes().remove(GATEWAY_PREDICATE_ROUTE_ATTR);
if (logger.isDebugEnabled()) {
logger.debug(
"Mapping [" + getExchangeDesc(exchange) + "] to " + r);
}
//把该路由与上下文绑定，后续负载均衡会用
exchange.getAttributes().put(GATEWAY_ROUTE_ATTR, r);
//返回 webHandler
return Mono.just(webHandler);
}).switchIfEmpty(Mono.empty().then(Mono.fromRunnable(() -> {
exchange.getAttributes().remove(GATEWAY_PREDICATE_ROUTE_ATTR);
if (logger.isTraceEnabled()) {
logger.trace("No RouteDefinition found for ["
+ getExchangeDesc(exchange) + "]");
}
})));
}
其中lookupRoute方法会找到yml中配置的所有的路由断言工厂（Before、After、Path等等），并执行apply方法，进行路由匹配，判断是否允许请求通过！执行顺序由springboot自动配置时自己制定
protected Mono<Route> lookupRoute(ServerWebExchange exchange) {
// getRoutes 获取所有的断言工厂
return this.routeLocator.getRoutes()
.concatMap(route -> Mono.just(route).filterWhen(r -> {
exchange.getAttributes().put(GATEWAY_PREDICATE_ROUTE_ATTR, r.getId());
// 先获取Route内部的predicate属性
//然后调用apply方法 执行断言！判断请求是否通过
return r.getPredicate().apply(exchange);
})
其中getRoutes()方法就是通过RouteDefinitionRouteLocator从配置文件中获取所有路由的，然后把找到的路由转换成Route
public Flux<Route> getRoutes() {
// getRouteDefinitions() 从配置文件中获取所有路由
Flux<Route> routes = this.routeDefinitionLocator.getRouteDefinitions()
// convertToRoute()：把找到的路由转换成Route
.map(this::convertToRoute);
Route内部结构如下
public class Route implements Ordered {
//路由id
private final String id;
//请求URI
private final URI uri;
//排序
private final int order;
//断言
private final AsyncPredicate<ServerWebExchange> predicate;
//过滤器
private final List<GatewayFilter> gatewayFilters;
//元数据
private final Map<String, Object> metadata;
②：找到对应的适配器HandlerAdaptor，执行过滤器链
Gateway由于在第①步匹配路由后返回的是webHandler类型的，所以也需要找到对应的HandlerAdaptor，进入获取对应的适配器方法 invokeHandler(exchange, handler)中
SimpleHandlerAdapter 中的handle方法如下
public class SimpleHandlerAdapter implements HandlerAdapter {
@Override
public Mono<HandlerResult> handle(ServerWebExchange exchange, Object handler) {
//处理WebHandler 类型
WebHandler webHandler = (WebHandler) handler;
Mono<Void> mono = webHandler.handle(exchange);
return mono.then(Mono.empty());
}
}
其中webHandler.handle方法就是处理所有过滤器链的方法，该过滤器链包括globalFilters和gatewayFilters
@Override
public Mono<Void> handle(ServerWebExchange exchange) {
// 1. 根据路由与上下文绑定关系，获取对应的路由Route
Route route = exchange.getRequiredAttribute(GATEWAY_ROUTE_ATTR);
List<GatewayFilter> gatewayFilters = route.getFilters();
// 2. 收集所有的 globalFilters 并放入List<GatewayFilter>
//注意这里使用了适配器模式
List<GatewayFilter> combined = new ArrayList<>(this.globalFilters);
// 3. 把 gatewayFilters 也放入List<GatewayFilter>，形成一条过滤器立案
combined.addAll(gatewayFilters);
// 4. 根据order排序
AnnotationAwareOrderComparator.sort(combined);
if (logger.isDebugEnabled()) {
logger.debug("Sorted gatewayFilterFactories: " + combined);
}
// 5. 执行过滤器链中的每一个过滤器方法！
return new DefaultGatewayFilterChain(combined).filter(exchange);
}
注意：在组装过滤器链的时候，是把globalFilters和gatewayFilters两种过滤器都放进了List<GatewayFilter>中，这是怎么做的呢？
这其实用到了一种 适配器 的设计模式！
- 如果放入的是globalFilters，会先把globalFilters转化成GatewayFilterAdapter。 GatewayFilterAdapter在内部集成了GlobalFilter，同时也实现了GatewayFilter，使 globalFilters和gatewayFilters在 适配器 类GatewayFilterAdapter中共存！
- 如果放入的是gatewayFilters，直接放入即可！
//使用适配器类GatewayFilterAdapter 解决了 globalFilters想要放入List<GatewayFilter>中的类型不一致问题
private static class GatewayFilterAdapter implements GatewayFilter {
//集成了`GlobalFilter`
private final GlobalFilter delegate;
GatewayFilterAdapter(GlobalFilter delegate) {
this.delegate = delegate;
}
//调用filter时，调的是globalFilters的filter方法！
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
return this.delegate.filter(exchange, chain);
}
@Override
public String toString() {
final StringBuilder sb = new StringBuilder("GatewayFilterAdapter{");
sb.append("delegate=").append(delegate);
sb.append('}');
return sb.toString();
}
}
然后在执行过滤器链中的globalFilters和gatewayFilters的filter方法时，就会为请求加上请求头、请求参数等扩展点！
3：Gateway的负载均衡是如何实现的？
Gateway的负载均衡只需要在yml中配置 uri: lb://mall-order即可实现负载均衡，底层是由全局过滤器LoadBalancerClientFilter的filter方法去做的！
以订单服务的http://localhost:8888/order/findOrderById/1为例！8888为网关Gateway的端口
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 1. 根据路由与上下文绑定关系
// 获取原始的url：http://localhost:8888/order/findOrderById/1
URI url = exchange.getAttribute(GATEWAY_REQUEST_URL_ATTR);
String schemePrefix = exchange.getAttribute(GATEWAY_SCHEME_PREFIX_ATTR);
if (url == null
|| (!"lb".equals(url.getScheme()) && !"lb".equals(schemePrefix))) {
return chain.filter(exchange);
}
addOriginalRequestUrl(exchange, url);
if (log.isTraceEnabled()) {
log.trace("LoadBalancerClientFilter url before: " + url);
}
// 2. 通过ribbon的负载均衡算法，根据服务名 去nacos选择一个实例！
// 该实例就有order服务真正的 url 地址：http://localhost:9001/order/findOrderById/1
final ServiceInstance instance = choose(exchange);
if (instance == null) {
throw NotFoundException.create(properties.isUse404(),
"Unable to find instance for " + url.getHost());
}
// 3. 拿到原生的 uri ：http://localhost:8888/order/findOrderById/1
URI uri = exchange.getRequest().getURI();
String overrideScheme = instance.isSecure() ? "https" : "http";
if (schemePrefix != null) {
overrideScheme = url.getScheme();
}
// 4. 拿服务实例instance的uri替换原生的uri地址 得到 新的url
// 新的url: http://localhost:8888/order/findOrderById/1
URI requestUrl = loadBalancer.reconstructURI(
new DelegatingServiceInstance(instance, overrideScheme), uri);
if (log.isTraceEnabled()) {
log.trace("LoadBalancerClientFilter url chosen: " + requestUrl);
}
// 5. 再次记录上下文关系
exchange.getAttributes().put(GATEWAY_REQUEST_URL_ATTR, requestUrl);
// 6. 执行过滤器链中的其他过滤请求
return chain.filter(exchange);
}
Spring Cloud GateWay 网关的相关面试题
Spring Cloud GateWay如何实现限流？
1.Spring Cloud GateWay使用令牌桶算法实现限流（Nginx使用漏桶算法实现限流 ）
2.Spring Cloud GateWay默认使用Redis 的RateLimter限流算法来实现，所以需要引入Redis依赖
3.使用的过程中，主要配置 令牌桶填充的速率，令牌桶容量，指定限流的key
4.限流的Key,可以根据用户 来做限流，IP 来做限流，接口限流等等。
微服务中网关的作用
统一入口：为全部微服务提供唯一入口点，网关起到外部和内部隔离，保障了后台服务的安全性 鉴权校验：识别每个请求的权限，拒绝不符合要求的请求 动态路由：动态的将请求路由到不同的后端集群中 减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射 流量控制算法----漏桶算法和令牌桶算法
什么是漏桶算法？ 漏桶算法思路很简单，请求先进入到漏桶里，漏桶以固定的速度出水，也就是处理请求，当水加的过快，则会直接溢出，也就是拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。
漏桶算法
long timeStamp = getNowTime();
int capacity = 10000;// 桶的容量
int rate = 1;//水漏出的速度
int water = 100;//当前水量
public static bool control() {
//先执行漏水，因为rate是固定的，所以可以认为“时间间隔*rate”即为漏出的水量
long now = getNowTime();
water = Math.max(0, water - (now - timeStamp) * rate);
timeStamp = now;
if (water < capacity) { // 水还未满，加水
water ++;
return true;
} else {
return false;//水满，拒绝加水
}
}
该算法很好的解决了时间边界处理不够平滑的问题，因为在每次请求进桶前都将执行“漏水”的操作，再无边界问题。
但是对于很多场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。
什么是令牌桶算法？ 从某种意义上讲，令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。
实现思路：可以准备一个队列，用来保存令牌，另外通过一个线程池定期生成令牌放到队列中，每来一个请求，就从队列中获取一个令牌，并继续执行。
