鼓捣这个是因为公司的发布系统目前还只支持以war的方式发布应用到Tomcat容器中, 又因为最近有项目需要用到webflux(因为严重的IO阻塞,使用这个框架可以带来可观的性能提升), 所以着手研究了一下如何适配这种发布方式.
让我们首先回顾一下Tomcat调起Spring Web应用的过程:
- tomcat 通过 spi 加载 ServletContainerInitializer
- spring-web 利用 spi 导入 SpringServletContainerInitializer
- 获取 SpringServletContainerInitializer上的 @HandlesTypes 注解的value(WebApplicationInitializer), 即代表onStartup方法接受的第一个参数类型列表, 并缓存
- 从已经扫描过的lib下的jar包中找出 WebApplicationInitializer 实现类并缓存(是一个Map, key是SpringServletContainerInitializer, value是实现类的Set)
- tomcat 调用 SpringServletContainerInitializer#onStartup 方法
- SpringServletContainerInitializer#onStartup 方法中调用了 WebApplicationInitializer 的onStartup(ServletContext)
- 我们自己的 SpringBoot 应用引导类在使用外置tomcat的情况下需要继承SpringBootServletInitializer, 而 SpringBootServletInitializer 实现了 WebApplicationInitializer. 所以我们的引导类也是一个WebApplicationInitializer, 至此, 进入了spring的领域
接下来开始着手鼓捣了.
首先先依赖 spring-boot-starter-webflux 以及 javax.servlet-api (provided).
然后, 在了解上面的过程后, 我们知道核心在于 WebApplicationInitializerInitializer. 我们找到它其中一个实现类:AbstractReactiveWebInitializer
这个类就相当于是启动我们的Spring应用的入口了.我们就在标注了@SpringBootApplication注解的主配置类上扩展这个类. 需要覆写2个方法, 一个是必须要覆写的 getConfigClasses()方法, 这个方法返回的是Spring的配置类, 就是标注了@Component 和 @Configuration 的类. 另一个是 createApplicationContext() 方法, 用于创建SpringBoot应用上下文, 注意是SpringBoot应用上下文, 而不是传统的上下文, 我们需要的是 AnnotationConfigReactiveWebServerApplicationContext, 所以才要覆写该方法, 因为本来它是有默认实现的, 只不过创建出的上下文并不是我们需要的.
看一下代码:
@Override
protected Class[] getConfigClasses() {
//这个是主配置类, 了解springboot的就知道核心在于@SpringBootApplication
return new Class[]{DemoApplication.class};
}
@Override
protected ApplicationContext createApplicationContext() {
//用主配置类起一个springboot应用
SpringApplication springApplication = new SpringApplication(getConfigClasses());
return springApplication.run();
}
还有一个关键, 就是一定要有这个东西:
@Bean
public NettyReactiveWebServerFactory nettyReactiveWebServerFactory() {
return new NettyReactiveWebServerFactory();
}
本来是用内嵌容器是不用关注这些的, 但是由于存在特殊性(外置的Tomcat使得优先装配内嵌的tomcat), 需要特殊处理一下. 这里稍微解释一下, 先看一下自动装配包里的 ReactiveWebServerFactoryConfiguration 的部分代码:
@Configuration
@ConditionalOnMissingBean(ReactiveWebServerFactory.class)
@ConditionalOnClass({ HttpServer.class })
static class EmbeddedNetty {
@Bean
public NettyReactiveWebServerFactory nettyReactiveWebServerFactory() {
return new NettyReactiveWebServerFactory();
}
}
@Configuration
@ConditionalOnMissingBean(ReactiveWebServerFactory.class)
@ConditionalOnClass({ org.apache.catalina.startup.Tomcat.class })
static class EmbeddedTomcat {
@Bean
public TomcatReactiveWebServerFactory tomcatReactiveWebServerFactory() {
return new TomcatReactiveWebServerFactory();
}
}
EmbeddedTomcat 的 @ConditionalOnClass({ org.apache.catalina.startup.Tomcat.class }) 这个条件是会pass的, 会优先装配它:
我们可以看到一旦条件满足, 第一个加载的就是它.
而在启动内嵌的tomcat的时候会报 TomcatEmbeddedWebappClassLoader 的 ClassNotFound 异常, 这就牵扯到了tomcat的类加载机制. 内嵌的tomcat的类加载器是 TomcatEmbeddedWebappClassLoader, 需要用此类加载器加载web应用的类, 而这个类加载器首先需要被 tomcat 的 URLClassLoader 加载, 但是URLClassLoader只加载catalina.properties中的*.loader的配置目录下的类, 因此 TomcatEmbeddedWebappClassLoader 无法加载, 在加载WEB-INF下的类之前就会抛出ClassNotFound异常. 要解决这个问题需要我们自己注入一个 NettyReactiveWebServerFactory 来打破 @ConditionalOnMissingBean(ReactiveWebServerFactory.class) 这个条件, 自主选择使用Netty而非内嵌的tomcat.
注意, server.port的配置是必要的,且与tomcat的端口不要冲突. 最后你会发现我们有2个web容器,分别绑定2个端口号, 而这2个端口号都是可以提供服务的, 因为spring提供了对servlet-api的适配,见 ServletHttpHandlerAdapter. 在 AbstractReactiveWebInitializer 的 onStartup方法中进行了适配, 将 HttpHandler 适配为 Servlet 添加进了 ServletContext. 但是, 在SpringCloud体系中, 选择的端口号仍然是netty绑定的端口号,也就是springboot配置的端口号.
至此, 就鼓捣完了.