Spring Cloud Gateway容器切换大坑

2024-01-21 16:29:47

使用 Spring Cloud Gateway 时的 Web 容器变更：避免一个微妙的陷阱

更换 Web 容器可能会导致 Spring Cloud Gateway 故障：一个棘手的问题

在近期的一个项目中，我遇到了一个棘手的难题：将微服务使用的 Web 容器从 Tomcat 切换到 Undertow 后，Spring Cloud Gateway 无法正常运行。我一开始百思不得其解，直到深入排查后，才发现罪魁祸首竟是 Web 容器的更换。

罪魁祸首：Undertow 依赖的意外影响

问题的根源在于我们团队成员在依赖中添加了 Undertow 容器的依赖。此举旨在针对我们的微服务定制 Undertow。然而，正是这个看似简单的依赖添加，导致了 Spring Cloud Gateway 的崩溃。当我尝试重新启动服务时，它抛出了一个错误：

Caused by: java.lang.ClassNotFoundException: io.undertow.UndertowOptions

我百思不得其解，明明已经添加了 Undertow 的依赖，为什么还会找不到这个类？深入研究 Spring Cloud Gateway 的源码后，我找到了问题的症结所在。

Spring Cloud Gateway 的自动配置机制：一把双刃剑

Spring Cloud Gateway 利用了 Spring Boot 的自动配置功能。其中包含一个名为 UndertowAutoConfiguration 的类，负责检测系统中是否存在 Undertow 依赖，并自动配置 Spring Cloud Gateway 使用 Undertow 作为 Web 容器。

@Configuration
@ConditionalOnClass(UndertowOptions.class)
public class UndertowAutoConfiguration {

    // 省略代码 ...

}

当添加了 Undertow 的依赖后，UndertowAutoConfiguration 类便会被加载，自动配置 Spring Cloud Gateway 使用 Undertow 作为 Web 容器。然而，如果使用的是 Tomcat 容器，该类就不会被加载，也不会自动配置 Undertow。

这就是为什么在更换 Web 容器后，Spring Cloud Gateway 无法正常工作的原因。为了解决这个问题，我们需要手动配置 Spring Cloud Gateway 使用 Tomcat 作为 Web 容器。

@Configuration
public class TomcatConfiguration {

    @Bean
    public TomcatServletWebServerFactory tomcatServletWebServerFactory() {
        return new TomcatServletWebServerFactory();
    }

}

通过这个配置，我们明确告诉 Spring Cloud Gateway 使用 Tomcat 作为 Web 容器，从而解决了问题。

教训：依赖管理的谨慎之路

这次经历让我深刻体会到，管理依赖时务必谨慎。看似简单的依赖添加，可能会对系统产生意想不到的影响。在修改依赖之前，一定要仔细考虑其潜在影响，并做好充分的测试。

解决常见问题的 5 个技巧

如果您在使用 Spring Cloud Gateway 时更换 Web 容器时遇到问题，以下 5 个技巧可以帮助您解决问题：