Spring Cloud Gateway 不小心换了个 Web 容器就不能用了

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: Spring Cloud Gateway 不小心换了个 Web 容器就不能用了
个人创作公约:本人声明创作的所有文章皆为自己原创,如果有参考任何文章的地方,会标注出来,如果有疏漏,欢迎大家批判。如果大家发现网上有抄袭本文章的,欢迎举报,并且积极向这个 github 仓库 提交 issue,谢谢支持~本文是我 TM 人傻了的第多少期我忘了,每一期总结一个坑以及对于坑的一些发散性想法,往期精彩回顾:


最近组员修改微服务的一些公共依赖,在某个依赖中需要针对我们微服务使用的 Undertow 容器做一些订制,所以加入了 web 容器 Undertow 的依赖。但是,一般这种底层框架依赖,是要兼顾当前使用的这个项目的 web 容器是否是 Undertow,这位同学在配置类上写了 @Conditional:

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({ Undertow.class }) 
public class CustomizedUndertowConfiguration {
    .......
}

但是加的 undetow 依赖的 scope 没有设置为 provided,导致只要加入这个依赖就会加入 Undertow 的依赖。正好网关也用到了这个依赖,并且我们的网关使用的是 Spring-Cloud-Gateway。这就导致了 Spring-Cloud-Gateway 本身的 Netty 的 Reactive 的 web 容器被替换成了 Undertow 的 Reactive 的 web 容器,从而导致了一系列的 Spring-Cloud-Gateway 不兼容的问题。


为何引入 undetow 依赖就会使异步 web 容器从原来的基于 netty 变为基于 undertow


我们知道,Spring-Cloud-Gateway 其实底层也是基于 Spring Boot 的。首先来看下 Spring Boot 中初始化哪种 web 容器的选择原理:首先第一步是根据类是否存在确定是哪种 WebApplicationType:

WebApplicationType

public enum WebApplicationType {
  /**
   * 没有 web 服务,不需要 web 容器
   */
  NONE,
  /**
   * 使用基于 servlet 的 web 容器
   */
  SERVLET,
  /**
   * 使用响应式的 web 容器
   */
  REACTIVE;
  private static final String[] SERVLET_INDICATOR_CLASSES = { "javax.servlet.Servlet",
      "org.springframework.web.context.ConfigurableWebApplicationContext" };
  private static final String WEBMVC_INDICATOR_CLASS = "org.springframework.web.servlet.DispatcherServlet";
  private static final String WEBFLUX_INDICATOR_CLASS = "org.springframework.web.reactive.DispatcherHandler";
  private static final String JERSEY_INDICATOR_CLASS = "org.glassfish.jersey.servlet.ServletContainer";
  private static final String SERVLET_APPLICATION_CONTEXT_CLASS = "org.springframework.web.context.WebApplicationContext";
  private static final String REACTIVE_APPLICATION_CONTEXT_CLASS = "org.springframework.boot.web.reactive.context.ReactiveWebApplicationContext";
  static WebApplicationType deduceFromClasspath() {
    if (ClassUtils.isPresent(WEBFLUX_INDICATOR_CLASS, null) && !ClassUtils.isPresent(WEBMVC_INDICATOR_CLASS, null)
        && !ClassUtils.isPresent(JERSEY_INDICATOR_CLASS, null)) {
      return WebApplicationType.REACTIVE;
    }
    for (String className : SERVLET_INDICATOR_CLASSES) {
      if (!ClassUtils.isPresent(className, null)) {
        return WebApplicationType.NONE;
      }
    }
    return WebApplicationType.SERVLET;
  }

从源码中可以看出,当有 WEBFLUX_INDICATOR_CLASS 并且没有 WEBMVC_INDICATOR_CLASS 以及 JERSEY_INDICATOR_CLASS 的时候,判断为 REACTIVE 环境。如果所有 SERVLET_INDICATOR_CLASSES 就认为是 SERVLET 环境。其实这样也可以看出,如果又引入 spring-web 又引入 spring-webflux 的依赖,其实还是 SERVLET 环境。如果以上都没有,那么就是无 web 容器的环境。在 Spring-Cloud-Gateway 中,是 REACTIVE 环境。

如果是 REACTIVE 环境,就会使用 org.springframework.boot.web.reactive.server.ReactiveWebServerFactory 的实现 Bean 创建 web 容器。那么究竟是哪个实现呢?目前有四个实现(Spring-boot 2.7.x):

  • TomcatReactiveWebServerFactory:基于 Tomcat 的响应式 web 容器 Factory
  • JettyReactiveWebServerFactory:基于 Jetty 的响应式 web 容器 Factory
  • UndertowReactiveWebServerFactory:基于 Undertow 的响应式 web 容器 Factory
  • NettyReactiveWebServerFactory:基于 Netty 的响应式 web 容器 Factory

实际会用哪个,看到底哪个 Bean 会注册到 ApplicationContext 中:

ReactiveWebServerFactoryConfiguration

@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(ReactiveWebServerFactory.class)
@ConditionalOnClass({ HttpServer.class })
static class EmbeddedNetty {
  @Bean
  @ConditionalOnMissingBean
  ReactorResourceFactory reactorServerResourceFactory() {
    return new ReactorResourceFactory();
  }
  @Bean
  NettyReactiveWebServerFactory nettyReactiveWebServerFactory(ReactorResourceFactory resourceFactory,
      ObjectProvider<NettyRouteProvider> routes, ObjectProvider<NettyServerCustomizer> serverCustomizers) {
    NettyReactiveWebServerFactory serverFactory = new NettyReactiveWebServerFactory();
    serverFactory.setResourceFactory(resourceFactory);
    routes.orderedStream().forEach(serverFactory::addRouteProviders);
    serverFactory.getServerCustomizers().addAll(serverCustomizers.orderedStream().collect(Collectors.toList()));
    return serverFactory;
  }
}
@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(ReactiveWebServerFactory.class)
@ConditionalOnClass({ org.apache.catalina.startup.Tomcat.class })
static class EmbeddedTomcat {
  @Bean
  TomcatReactiveWebServerFactory tomcatReactiveWebServerFactory(
      ObjectProvider<TomcatConnectorCustomizer> connectorCustomizers,
      ObjectProvider<TomcatContextCustomizer> contextCustomizers,
      ObjectProvider<TomcatProtocolHandlerCustomizer<?>> protocolHandlerCustomizers) {
    TomcatReactiveWebServerFactory factory = new TomcatReactiveWebServerFactory();
    factory.getTomcatConnectorCustomizers()
        .addAll(connectorCustomizers.orderedStream().collect(Collectors.toList()));
    factory.getTomcatContextCustomizers()
        .addAll(contextCustomizers.orderedStream().collect(Collectors.toList()));
    factory.getTomcatProtocolHandlerCustomizers()
        .addAll(protocolHandlerCustomizers.orderedStream().collect(Collectors.toList()));
    return factory;
  }
}
@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(ReactiveWebServerFactory.class)
@ConditionalOnClass({ org.eclipse.jetty.server.Server.class, ServletHolder.class })
static class EmbeddedJetty {
  @Bean
  @ConditionalOnMissingBean
  JettyResourceFactory jettyServerResourceFactory() {
    return new JettyResourceFactory();
  }
  @Bean
  JettyReactiveWebServerFactory jettyReactiveWebServerFactory(JettyResourceFactory resourceFactory,
      ObjectProvider<JettyServerCustomizer> serverCustomizers) {
    JettyReactiveWebServerFactory serverFactory = new JettyReactiveWebServerFactory();
    serverFactory.getServerCustomizers().addAll(serverCustomizers.orderedStream().collect(Collectors.toList()));
    serverFactory.setResourceFactory(resourceFactory);
    return serverFactory;
  }
}
@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(ReactiveWebServerFactory.class)
@ConditionalOnClass({ Undertow.class })
static class EmbeddedUndertow {
  @Bean
  UndertowReactiveWebServerFactory undertowReactiveWebServerFactory(
      ObjectProvider<UndertowBuilderCustomizer> builderCustomizers) {
    UndertowReactiveWebServerFactory factory = new UndertowReactiveWebServerFactory();
    factory.getBuilderCustomizers().addAll(builderCustomizers.orderedStream().collect(Collectors.toList()));
    return factory;
  }
}

从原码可以看出,每种配置上都有 @ConditionalOnMissingBean(ReactiveWebServerFactory.class) 以及判断是否有对应容器的 class 的条件,例如:@ConditionalOnClass({ Undertow.class })@Configuration(proxyBeanMethods = false)是关闭这个配置中 Bean 之间的代理加快加载速度。

由于每个配置都有 @ConditionalOnMissingBean(ReactiveWebServerFactory.class),那么其实能保证就算满足多个配置的条件,最后也只有一个 ReactiveWebServerFactory,那么当满足多个条件时,哪个优先加载呢?这就要看这里的源码:

ReactiveWebServerFactoryAutoConfiguration

@Import({ ReactiveWebServerFactoryAutoConfiguration.BeanPostProcessorsRegistrar.class,
    ReactiveWebServerFactoryConfiguration.EmbeddedTomcat.class,
    ReactiveWebServerFactoryConfiguration.EmbeddedJetty.class,
    ReactiveWebServerFactoryConfiguration.EmbeddedUndertow.class,
    ReactiveWebServerFactoryConfiguration.EmbeddedNetty.class })

从这里可以看出,是按照 EmbeddedTomcatEmbeddedJettyEmbeddedUndertowEmbeddedNetty 的顺序 Import 的,也就是:只要你的依赖中加入了任何 Web 容器(例如 Undertow),那么最后创建的就是基于那个 web 容器的异步容器,而不是基于 netty 的


为何 Web 容器换了就会有问题


首先, Spring Cloud Gateway 的官方文档中就说了:

Spring Cloud Gateway requires the Netty runtime provided by Spring Boot and Spring Webflux. It does not work in a traditional Servlet Container or when built as a WAR.

就是 Spring Cloud Gateway 只能在 Netty 的环境中运行。这是为什么呢。当初在设计的时候,就假定了容器只能是 Netty,后续开发各种 Spring Cloud Gateway 的内置 Filter 以及 Filter 插件的时候,有很多假设当前就是 Netty 的代码,例如缓存 Body 的 Filter 使用的工具类 ServerWebExchangeUtils

ServerWebExchangeUtils

private static <T> Mono<T> cacheRequestBody(ServerWebExchange exchange, boolean cacheDecoratedRequest,
      Function<ServerHttpRequest, Mono<T>> function) {
  ServerHttpResponse response = exchange.getResponse();
  //在这里,强制转换了 bufferFactory 为 NettyDataBufferFactory
  NettyDataBufferFactory factory = (NettyDataBufferFactory) response.bufferFactory();
  // Join all the DataBuffers so we have a single DataBuffer for the body
  return DataBufferUtils.join(exchange.getRequest().getBody())
      .defaultIfEmpty(factory.wrap(new EmptyByteBuf(factory.getByteBufAllocator())))
      .map(dataBuffer -> decorate(exchange, dataBuffer, cacheDecoratedRequest))
      .switchIfEmpty(Mono.just(exchange.getRequest())).flatMap(function);
}

从源码中可以看到,代码直接认为 response 中的 BufferFactory 就是 NettyDataBufferFactory,其实在其他 Web 容器的情况下,目前应该是 DefaultDataBufferFactory,这样就会有异常。不过在 v3.0.5 之后的版本,已经修复了这个强转,参考:https://github.com/spring-cloud/spring-cloud-gateway/commit/68dcc355119e057af1e4f664c81f77714c5a8a16

这其实也是为兼容所有的 Web 容器进行铺路。那么,究竟有计划兼容所有的 Web 容器么?是有计划的,还在做,已经做了快 4 年了,应该快做好了,相当于所有的单元测试要重新跑甚至重新设计,可以通过这个 ISSUE:Support running the gateway with other reactive containers besides netty #145

来查看兼容的进度。

相关文章
|
2月前
|
Java API 数据库
构建RESTful API已经成为现代Web开发的标准做法之一。Spring Boot框架因其简洁的配置、快速的启动特性及丰富的功能集而备受开发者青睐。
【10月更文挑战第11天】本文介绍如何使用Spring Boot构建在线图书管理系统的RESTful API。通过创建Spring Boot项目,定义`Book`实体类、`BookRepository`接口和`BookService`服务类,最后实现`BookController`控制器来处理HTTP请求,展示了从基础环境搭建到API测试的完整过程。
58 4
|
21天前
|
Java 开发者 微服务
Spring Boot 入门:简化 Java Web 开发的强大工具
Spring Boot 是一个开源的 Java 基础框架,用于创建独立、生产级别的基于Spring框架的应用程序。它旨在简化Spring应用的初始搭建以及开发过程。
38 6
Spring Boot 入门:简化 Java Web 开发的强大工具
|
2天前
|
XML Java 数据格式
Spring容器Bean之XML配置方式
通过对以上内容的掌握,开发人员可以灵活地使用Spring的XML配置方式来管理应用程序的Bean,提高代码的模块化和可维护性。
18 6
|
16天前
|
JavaScript Java Kotlin
深入 Spring Cloud Gateway 过滤器
Spring Cloud Gateway 是新一代微服务网关框架,支持多种过滤器实现。本文详解了 `GlobalFilter`、`GatewayFilter` 和 `AbstractGatewayFilterFactory` 三种过滤器的实现方式及其应用场景,帮助开发者高效利用这些工具进行网关开发。
|
18天前
|
安全 Java 开发者
Spring容器中的bean是线程安全的吗?
Spring容器中的bean默认为单例模式,多线程环境下若操作共享成员变量,易引发线程安全问题。Spring未对单例bean做线程安全处理,需开发者自行解决。通常,Spring bean(如Controller、Service、Dao)无状态变化,故多为线程安全。若涉及线程安全问题,可通过编码或设置bean作用域为prototype解决。
27 1
|
18天前
|
人工智能 Kubernetes Cloud Native
荣获2024年AI Cloud Native典型案例,阿里云容器产品技术能力获认可
2024全球数字经济大会云·AI·计算创新发展大会,阿里云容器服务团队携手客户,荣获“2024年AI Cloud Native典型案例”。
|
23天前
|
XML Java 网络架构
使用 Spring Boot 公开 SOAP Web 服务端点:详细指南
使用 Spring Boot 公开 SOAP Web 服务端点:详细指南
32 0
|
23天前
|
负载均衡 Java API
项目中用的网关Gateway及SpringCloud
Spring Cloud Gateway 是一个功能强大、灵活易用的API网关解决方案。通过配置路由、过滤器、熔断器和限流等功能,可以有效地管理和保护微服务。本文详细介绍了Spring Cloud Gateway的基本概念、配置方法和实际应用,希望能帮助开发者更好地理解和使用这一工具。通过合理使用Spring Cloud Gateway,可以显著提升微服务架构的健壮性和可维护性。
32 0
|
1月前
|
前端开发 Java Docker
使用Docker容器化部署Spring Boot应用程序
使用Docker容器化部署Spring Boot应用程序
|
1月前
|
Java Docker 微服务
利用Docker容器化部署Spring Boot应用
利用Docker容器化部署Spring Boot应用
49 0
下一篇
DataWorks