SpringCloud Gateway 路由配置定位原理分析

环境:springcloud Hoxton.SR11

本节主要了解系统中的谓词与配置的路由信息是如何进行初始化关联生成路由对象的。每个谓词工厂中的Config对象又是如何被解析配置的。

所有的谓词工厂中的Config中属性值是如何被配置的。

在SpringCloud Gateway中的所有谓词工厂如下:

命名规则:XxxRoutePredicateFactory。所有的这些谓词工厂都是如下的继承关系

public class MethodRoutePredicateFactory extends   AbstractRoutePredicateFactory<MethodRoutePredicateFactory.Config>
//
public class PathRoutePredicateFactory extends AbstractRoutePredicateFactory<PathRoutePredicateFactory.Config>
// ...

所有的谓词工厂继承的
AbstractRoutePredicateFactory中的泛型都是内部类的Config。这个是如何被配置上值的呢?

6.1 gateway自动配置

在下面这个类中配置了所有的Predicate和Filter。

public class GatewayAutoConfiguration {
  @Bean
  @ConditionalOnEnabledPredicate
  public PathRoutePredicateFactory pathRoutePredicateFactory() {
    return new PathRoutePredicateFactory();
  }
  @Bean
  @ConditionalOnEnabledPredicate
  public QueryRoutePredicateFactory queryRoutePredicateFactory() {
    return new QueryRoutePredicateFactory();
  }
  @Bean
  public RouteLocator routeDefinitionRouteLocator(GatewayProperties properties, List<GatewayFilterFactory> gatewayFilters, List<RoutePredicateFactory> predicates, RouteDefinitionLocator routeDefinitionLocator, ConfigurationService configurationService) {
    return new RouteDefinitionRouteLocator(routeDefinitionLocator, predicates,
            gatewayFilters, properties, configurationService);
  }
  @Bean
  @Primary
  @ConditionalOnMissingBean(name = "cachedCompositeRouteLocator")
  public RouteLocator cachedCompositeRouteLocator(List<RouteLocator> routeLocators) {
    return new CachingRouteLocator(new CompositeRouteLocator(Flux.fromIterable(routeLocators)));
  }
}

这里会层层委托最终查找查找路由定位会交给
RouteDefinitionRouteLocator。CachingRouteLocator起到缓存的作用,将配置的所有路由信息保存。

注意:这里的路由信息是在容器启动后就会被初始化的。

public class CachingRouteLocator {
  private final RouteLocator delegate;

  private final Flux<Route> routes;

  private final Map<String, List> cache = new ConcurrentHashMap<>();

  private ApplicationEventPublisher applicationEventPublisher;

  public CachingRouteLocator(RouteLocator delegate) {
    this.delegate = delegate;
    routes = CacheFlux.lookup(cache, CACHE_KEY, Route.class) .onCacheMissResume(this::fetch);
  }

  private Flux<Route> fetch() {
    return this.delegate.getRoutes().sort(AnnotationAwareOrderComparator.INSTANCE);
  }
}

实例化CachingRouteLocator就开始查找所有配置的Route信息。最终的会委托给
RouteDefinitionRouteLocator

RouteDefinitionRouteLocator构造函数中的initFactories方法用来映射路由工厂的XxxRoutePredicateFactory。

private void initFactories(List<RoutePredicateFactory> predicates) {
  predicates.forEach(factory -> {
    String key = factory.name();
    if (this.predicates.containsKey(key)) {
      this.logger.warn("A RoutePredicateFactory named " + key + " already exists, class: " + this.predicates.get(key) + ". It will be overwritten.");
    }
    this.predicates.put(key, factory);
  });
}

方法中解析每一个谓词工厂对应的名称然后缓存到predicates 集合中。

factory.name()方法解析谓词名称。

default String name() {
  return NameUtils.normalizeRoutePredicateName(getClass());
}

CachingRouteLocator是个缓存路由定位器,是个首选的RouteLocator(@Primary),这里将
RouteDefinitionRouteLocator进行了合并。

6.2 生成路由对象Route及Config配置

getRoutes---》convertToRoute---》combinePredicates---》lookup。

根据上面的自动配置也知道了在服务启动时就进行初始化所有路由信息了。

获取路由信息

public Flux<Route> getRoutes() {
  Flux<Route> routes = this.routeDefinitionLocator.getRouteDefinitions() .map(this::convertToRoute);
  routes = routes.onErrorContinue((error, obj) -> {
    return routes.map(route -> {
            return route;
  });
}

合并谓词

private AsyncPredicate<ServerWebExchange> combinePredicates(
            RouteDefinition routeDefinition) {
  // other code
  for (PredicateDefinition andPredicate : predicates.subList(1, predicates.size())) {
    AsyncPredicate<ServerWebExchange> found = lookup(routeDefinition, andPredicate);
    predicate = predicate.and(found);
  }
  return predicate;
}

进入lookup中

private AsyncPredicate<ServerWebExchange> lookup(RouteDefinition route, PredicateDefinition predicate) {
  RoutePredicateFactory<Object> factory = this.predicates.get(predicate.getName());
  if (factory == null) {
    throw new IllegalArgumentException("Unable to find RoutePredicateFactory with name " + predicate.getName());
  }
  // 这里将配置中(yml文件)配置的name,args和谓词工厂中的Config进行关联设置值
  Object config = this.configurationService.with(factory)
    .name(predicate.getName())
    .properties(predicate.getArgs())
    .eventFunction((bound, properties) -> new PredicateArgsEvent(
        RouteDefinitionRouteLocator.this, route.getId(), properties))
    .bind();
  // 最终调用谓词工厂(XxxRoutePredicateFactory的apply方法返回RoutePredicate该对象继承Predicate)
  return factory.applyAsync(config);
}

lookup方法中查找,也就是在这里将对应的谓词Config与RouteDefinition(Predicate)中定义的相对应的属性关联。

进入factory.applyAsync方法

@FunctionalInterface
public interface RoutePredicateFactory<C> extends ShortcutConfigurable, Configurable<C> {
  default AsyncPredicate<ServerWebExchange> applyAsync(C config) {
    return toAsyncPredicate(apply(config)); // 查看下面的6.2-1图当前apply所有的实现就是系统内部定义的XxxRoutePredicateFactory
  }
}
// apply(config),如这里配置了Path谓词,那么就会进入PathRoutePredicateFactory中的apply方法
public Predicate<ServerWebExchange> apply(Config config) {
  // other code
  return new GatewayPredicate() {
    public boolean test() {
      // todo
    }
  }
}
// 最后返回一个异步的谓词
public static AsyncPredicate<ServerWebExchange> toAsyncPredicate(Predicate<? super ServerWebExchange> predicate) {
  Assert.notNull(predicate, "predicate must not be null");
  // 这里from就是返回一个DefaultAsyncPredicate默认的异步谓词
  return AsyncPredicate.from(predicate);
}
static AsyncPredicate<ServerWebExchange> from( Predicate<? super ServerWebExchange> predicate) {
  return new DefaultAsyncPredicate<>(GatewayPredicate.wrapIfNeeded(predicate));
}

图6.2-1

最后在combinePredicates方法中将当前路由中配置的所有谓词进行了and操作返回。最终回到convertToRoute方法中将当前路由中配置的谓词,过滤器进行了整合包装返回Route(一个路由对象)

public class Route implements Ordered {
  private final String id;

  private final URI uri;

  private final int order;

  private final AsyncPredicate<ServerWebExchange> predicate;

  private final List<GatewayFilter> gatewayFilters;

  private final Map<String, Object> metadata;
}

这些Route对象会被保存在上面说的
CachingRouteLocator.routes中。

6.3 定位路由

根据上面的配置RouteLocator 该类用来定位路由(查找具体的使用哪个路由);当一个请求过来会查找是哪个路由。

RouteLocator中定义了一个方法

public interface RouteLocator {

  Flux<Route> getRoutes();

}

查看这个getRoutes方法是谁调用的

看到这个
RoutePredicateHandlerMapping是不是想起了Spring MVC中的HandlerMapping(我们所有的Controller都会被RequestMappingHanlderMapping 匹配)。通过名称也就知道了该HandlerMapping用来匹配我们的路由谓词的谁来处理路由。

接下来回到前面说的
RequestMappingHanlderMapping 对象,当我们请求一个路由地址时会执行该类中的lookup方法查找路由

protected Mono<Route> lookupRoute(ServerWebExchange exchange) {
  // 这里的this.routeLocator就是 CachingRouteLocator对象
  return this.routeLocator.getRoutes()
      .concatMap(route -> Mono.just(route).filterWhen(r -> {
        exchange.getAttributes().put(GATEWAY_PREDICATE_ROUTE_ATTR, r.getId());
        // 过滤查找符合的路由
        return r.getPredicate().apply(exchange);
     }).doOnError(e -> logger.error(
          "Error applying predicate for route: " + route.getId(),
     e)).onErrorResume(e -> Mono.empty()))
        .next()
        .map(route -> {
          if (logger.isDebugEnabled()) {
            logger.debug("Route matched: " + route.getId());
          }
          validateRoute(route, exchange);
          return route;
     });
}

进入r.getPredicate().apply(exchange)

public interface AsyncPredicate<T> extends Function<T, Publisher<Boolean>> {
  static AsyncPredicate<ServerWebExchange> from(Predicate<? super ServerWebExchange> predicate) {
  return new DefaultAsyncPredicate<>(GatewayPredicate.wrapIfNeeded(predicate));
  }

  class DefaultAsyncPredicate<T> implements AsyncPredicate<T> {

    private final Predicate<T> delegate;

    public DefaultAsyncPredicate(Predicate<T> delegate) {
      this.delegate = delegate;
    }

    @Override
    public Publisher<Boolean> apply(T t) {
      return Mono.just(delegate.test(t));
    }

    @Override
    public String toString() {
      return this.delegate.toString();
    }

  }

}

这里会调用Predicate.test方法(XxxRoutePredicateFactory中的apply方法返回的GatewayPredicate)。

调用GatewayPredicate.test返回判断当前请求的路由是否匹配。

整体的一个流程:

1、系统先初始化所有的Predicate(谓词)和Filter(过滤器)

2、根据配置的路由信息(过滤器,谓词)包装返回Route对象

3、根据请求路由路径查找匹配的路由

完毕!!!

到此这篇关于SpringCloud Gateway 路由配置定位原理分析的文章就介绍到这了,更多相关SpringCloud Gateway原理分析内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 详解SpringCloud Finchley Gateway 统一异常处理

    SpringCloud Finchley Gateway 统一异常处理 全文搜索[@@]搜索重点内容标记 1 . 问题:使用SpringCloud Gateway时,会出现各种系统级异常,默认返回HTML. 2 . Finchley版本的Gateway,使用WebFlux形式作为底层框架,而不是Servlet容器,所以常规的异常处理无法使用 翻阅源码,默认是使用DefaultErrorWebExceptionHandler这个类实现结构如下: 可以实现参考DefaultErrorWebExcep

  • 详解SpringCloudGateway内存泄漏问题

    SpringCloudGateway内存泄漏问题 项目完善差不多,在进入压力测试阶段期间,发现了gateway有内存泄漏问题,问题发现的起因是,当时启动一台gateway,一台对应的下游应用服务,在压力测试期间,发现特别不稳定,并发量时高时低,而且会有施压机卡住的现象,然后找到容器对应的宿主机,并使用container stats命令观察内存,经过观察发现,压力测试时内存会暴涨,并由于超过限制最大内存导致容器挂掉(这里由于用的swarm所以会自动选择节点重启)最终发现由于之前测试服务器配置低,所

  • SpringCloud Finchley Gateway 缓存请求Body和Form表单的实现

    在接入Spring-Cloud-Gateway时,可能有需求进行缓存Json-Body数据或者Form-Urlencoded数据的情况. 由于Spring-Cloud-Gateway是以WebFlux为基础的响应式架构设计,所以在原有Zuul基础上迁移过来的过程中,传统的编程思路,并不适合于Reactor Stream的开发. 网络上有许多缓存案例,但是在测试过程中出现各种Bug问题,在缓存Body时,需要考虑整体的响应式操作,才能更合理的缓存数据 下面提供缓存Json-Body数据或者Form

  • SpringCloud Gateway跨域配置代码实例

    这篇文章主要介绍了SpringCloud Gateway跨域配置代码实例,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 Springboot版本:2.1.8.RELEASE SpringCloud版本:Greenwich.SR2 yml配置: spring: cloud: gateway: globalcors: cors-configurations: '[/**]': # 允许携带认证信息 # 允许跨域的源(网站域名/ip),设置*为全部

  • springboot2.0和springcloud Finchley版项目搭建(包含eureka,gateWay,Freign,Hystrix)

    前段时间spring boot 2.0发布了,与之对应的spring cloud Finchley版本也随之而来了,两者之间的关系和版本对应详见我这边文章:spring boot和spring cloud对应的版本关系 项目地址:spring-cloud-demo spring boot 1.x和spring cloud Dalston和Edgware版本搭建的微服务项目现在已经很流行了,现在很多企业都已经在用了,这里就不多说了. 使用版本说明: spring boot 2.0.x spring

  • springcloud gateway聚合swagger2的方法示例

    问题描述 在搭建分布式应用时,每个应用通过nacos在网关出装配了路由,我们希望网关也可以将所有的应用的swagger界面聚合起来.这样前端开发的时候只需要访问网关的swagger就可以,而不用访问每个应用的swagger. 框架 springcloud+gateway+nacos+swagger 问题分析 swagger页面是一个单页面应用,所有的显示的数据都是通过和springfox.documentation.swagger.web.ApiResponseController进行数据交互,

  • 详解SpringCloud Gateway之过滤器GatewayFilter

    在Spring-Cloud-Gateway之请求处理流程文中我们了解最终网关是将请求交给过滤器链表进行处理,接下来我们阅读Spring-Cloud-Gateway的整个过滤器类结构以及主要功能 通过源码可以看到Spring-Cloud-Gateway的filter包中吉接口有如下三个,GatewayFilter,GlobalFilter,GatewayFilterChain,下来我依次阅读接口的主要实现功能. GatewayFilterChain 类图 代码 /** * 网关过滤链表接口 * 用

  • SpringCloud Gateway 路由配置定位原理分析

    环境:springcloud Hoxton.SR11 本节主要了解系统中的谓词与配置的路由信息是如何进行初始化关联生成路由对象的.每个谓词工厂中的Config对象又是如何被解析配置的. 所有的谓词工厂中的Config中属性值是如何被配置的. 在SpringCloud Gateway中的所有谓词工厂如下: 命名规则:XxxRoutePredicateFactory.所有的这些谓词工厂都是如下的继承关系 public class MethodRoutePredicateFactory extends

  • SpringCloud Gateway路由组件详解

    目录 简介 核心概念 具体示例 GlobalFilter 简介   Gateway是SpringCloud Alibaba中的路由组件(前身是Zuul),作为浏览器端请求的统一入口.当项目采用微服务模式时,若包含了路由模块,浏览器端的请求都不会直接请求含有业务逻辑的各个业务模块,而是请求这个路由模块,然后再由它来转发到各个业务模块去. 核心概念   Gateway中的三个核心概念:路由.断言(Predicate).过滤器.   路由:由唯一id.目的url.断言和过滤组成   断言:即路由规则,

  • SpringCloud Config统一配置中心问题分析解决与客户端动态刷新实现

    目录 一.问题分析及解决方案 1.问题分析 2.解决方案 二.手动刷新 1.添加服务监控 2.暴露服务端点 3.刷新业务类controller 4.手动刷新 三.自动刷新 什么是总线 基本原理 一.问题分析及解决方案 1.问题分析 上一章我们讲过远程仓储统一管理配置信息,客户端可以通过统一配置服务中心 config server 服务端获取配置信息.现在我们来做一个改变,并进行分析. 首先启动注册中心.统一配置中心configserver服务端.订单服务.浏览器访问地址:http://local

  • Springcloud GateWay网关配置过程图解

    一般为了不暴露自己的端口信息等,会选择架构一个网关在前面进行阻挡,起到保护的作用.附上一张工作示列图. 1.配置网关9527 gateway作为网关需要和其他的应用一样需要注册进eureka中进行管理,先创建应用gateway9527 pom文件,关键是gateway依赖 <dependencies> <dependency> <groupId>com.bai</groupId> <artifactId>cloud-api-common</

  • 解读mysql主从配置及其原理分析(Master-Slave)

    1.在主数据库服务器为从服务器添加一个拥有权限访问主库的用户:GRANT REPLICATION SLAVE ON *.* TO ' test'@'%' IDENTIFIED BY 'test'; (%表示允许所有IP,可设置指定从服务器IP)添加用户后:可在从服务器上用mysql -h127.0.0.1 -utest -ptest;  来测试是否有权限访问主数据库 2.在主据库配置文件加上:#master configserver-id       = 1log-bin          =

  • 解决SpringCloud Gateway配置自定义路由404的坑

    目录 问题背景 问题现象 解决过程 1 检查网关配置 2 跟源码,查找可能的原因 3 异常原因分析 解决方法 心得 问题背景 将原有项目中的websocket模块迁移到基于SpringCloud Alibaba的微服务系统中,其中网关部分使用的是gateway. 问题现象 迁移后,我们在使用客户端连接websocket时报错: io.netty.handler.codec.http.websocketx.WebSocketHandshakeException: Invalid subprotoc

  • SpringCloud Gateway动态路由配置详解

    目录 路由 动态 路由模型实体类 动态路径配置 路由模型JSON数据 路由 gateway最主要的作用是,提供统一的入口,路由,鉴权,限流,熔断:这里的路由就是请求的转发,根据设定好的某些条件,比如断言,进行转发. 动态 动态的目的是让程序更加可以在运行的过程中兼容更多的业务场景. 涉及到两个服务,一个是门户服务(作用是提供给运营人员管理入口--包括:管理路由.绑定路由),一个是网关服务(gateway组件,为门户服务提供:查询路由信息.添加路由.删除路由.编辑路由接口). 路由模型实体类 /*

  • SpringCloud Gateway加载断言predicates与过滤器filters的源码分析

    我们今天的主角是Gateway网关,一听名字就知道它基本的任务就是去分发路由.根据不同的指定名称去请求各个服务,下面是Gateway官方的解释: https://spring.io/projects/spring-cloud-gateway,其他的博主就不多说了,大家多去官网看看,只有官方的才是最正确的,回归主题,我们的过滤器与断言如何加载进来的,并且是如何进行对请求进行过滤的. 大家如果对SpringBoot自动加载的熟悉的话,一定知道要看一个代码的源码,要找到META-INF下的spring

  • SpringCloud Gateway详细分析实现负载均衡与熔断和限流

    目录 环境准备 1.pom依赖 2.yaml配置 3.路由转发和负载均衡测试 user服务暴露接口 返回结果输出 4.gateway熔断实现 4.1 熔断代码 4.2 测试 5.gateway限流 5.1 需要集成redis 5.2 yaml配置 5.3 注入到spring容器 5.4 测试 环境准备 注册中心Nacos,也可以其他 springboot 2.6.8 spring-cloud-dependencies 2021.0.3 1.pom依赖 parent包 <parent> <

  • SpringCloud配置刷新原理解析

    我们知道在SpringCloud中,当配置变更时,我们通过访问http://xxxx/refresh,可以在不启动服务的情况下获取最新的配置,那么它是如何做到的呢,当我们更改数据库配置并刷新后,如何能获取最新的数据源对象呢?下面我们看SpringCloud如何做到的. 一.环境变化 1.1.关于ContextRefresher 当我们访问/refresh时,会被RefreshEndpoint类所处理.我们来看源代码: /* * Copyright 2013-2014 the original a

随机推荐