17370845950

在spring boot多模块应用中，当一个依赖模块（如module 2）本身是一个spring boot应用，并被另一个主应用模块（如module 3）作为依赖引入并打包为war部署时，可能出现依赖模块意外启动的问题。本文将深入探讨此问题的原因，并提供两种主要解决方案：推荐的模块重构方法，以及通过maven配置显式指定主类的替代方案，旨在帮助开发者构建更清晰、更可控的多模块spring boot应用。

问题描述

在复杂的企业级应用开发中，采用多模块结构是一种常见的实践。例如，一个典型的Spring Boot项目可能包含以下结构：

• root
  • module 1 (纯粹的类库，无Spring Boot应用特性)
  • module 2 (一个独立的Spring Boot应用，可能包含服务、控制器等)
  • module 3 (主Spring Boot应用，依赖于module 2)

当我们将module 3打包成WAR文件并部署到如Tomcat这样的Servlet容器时，预期的行为是只有module 3作为主应用启动。然而，有时module 2这个依赖模块也会意外地作为自己的Spring Boot应用启动。这不仅可能导致资源浪费、端口冲突，还会使应用行为变得不可预测。开发者通常希望module 3仅仅使用module 2中定义的类和组件，而不是启动module 2作为一个独立的应用实例。

问题根源分析

Spring Boot应用通过@SpringBootApplication注解或包含main方法的类来标识其启动入口。当spring-boot-maven-plugin或其他构建工具处理项目时，它会扫描classpath来查找这些入口点。在多模块项目中，如果一个依赖模块（如module 2）自身也是一个完整的Spring Boot应用，其@SpringBootApplication注解或main方法会存在于最终打包的WAR文件的classpath中。

当WAR文件部署到Servlet容器时，Spring Boot的自动配置机制可能会发现并尝试启动所有它能识别的Spring Boot应用上下文。如果module 3没有明确地指定其主类，或者配置不当，容器可能会“看到”module 2的启动类，并尝试将其也初始化为一个独立的Spring Boot应用。

解决方案一：模块重构（推荐）

最清晰、最符合“关注点分离”原则的解决方案是将依赖模块进行重构。如果module 2既包含可复用的核心业务逻辑/类，又包含一个独立的Spring Boot应用（例如，它自身可以独立运行一个服务），那么应该将其拆分为两个独立的模块：

1. module 2-core: 包含纯粹的Java类、接口、模型、服务接口、工具类等，不包含任何Spring Boot应用相关的注解（如@SpringBootApplication、@RestController等，除非它们是接口定义）。
2. module 2-app: 包含module 2-core的依赖，并实现module 2-core中的接口，同时包含@SpringBootApplication注解、控制器、配置类以及任何使它成为一个独立Spring Boot应用的代码。

重构后的依赖关系：

• root
  • module 1 (纯粹的类库)
  • module 2-core (纯粹的类库，包含核心逻辑)
  • module 2-app (Spring Boot应用，依赖于 module 2-core)
  • module 3 (主Spring Boot应用，仅依赖于 module 2-core)

Maven配置示例：

在module 3的pom.xml中，仅引入module 2-core作为依赖：

    com.company
    module2-core
    1.0.0-SNAPSHOT
    compile

优点：

• 清晰的职责分离： module 2-core只提供可复用的组件，module 2-app和module 3则分别作为独立的应用程序。
• 避免冲突： module 3的classpath中不再包含module 2-app的Spring Boot启动类，从而彻底避免了意外启动的问题。
• 更好的可维护性： 模块结构更易于理解和管理。

解决方案二：Maven配置显式指定主类（替代方案）

如果模块重构在短期内不可行，或者由于历史原因难以实施，可以通过Maven配置来明确告诉Spring Boot哪个类是主应用程序的启动类。这通常涉及到在module 3的pom.xml中配置spring-boot-maven-plugin，显式指定其mainClass。

当使用spring-boot-maven-plugin打包WAR文件时，它可以生成一个可执行的WAR，其中包含应用程序的元数据，包括主类信息。通过明确指定module 3的主类，可以确保只有module 3的Spring Boot上下文被初始化。

Maven配置示例：

在module 3的pom.xml中，找到或添加spring-boot-maven-plugin配置，并设置mainClass：

    
        
            org.springframework.boot
            spring-boot-maven-plugin
            
                
                com.company.module3.Module3Application
            
            
                
                    
                        repackage
                    
                
            
        
        
        
            maven-war-plugin
            3.2.3
            
                true
                classes
                
            
        
    

注意事项：

• mainClass的准确性： 确保com.company.module3.Module3Application是module 3中带有@SpringBootApplication注解的实际启动类。
• repackage目标： spring-boot-maven-plugin的repackage目标会创建一个可执行的JAR或WAR，并嵌入必要的元数据。
• 依赖排除： 虽然在module 3中排除module 2的spring-boot-starter-tomcat（如问题描述中尝试的）有助于避免module 2引入其自身的嵌入式Tomcat，但这并不能阻止module 2的Spring应用上下文被初始化。它只是避免了端口冲突等问题，但应用逻辑仍然可能启动。因此，排除Starter通常不是解决此问题的根本方法。

总结与最佳实践

处理Spring Boot多模块应用中依赖模块意外启动的问题，核心在于明确各个模块的职责和启动意图。

• 推荐策略：模块重构。 将包含独立应用功能的模块拆分为核心库模块和应用模块。主应用只依赖核心库模块。这是最干净、最符合软件工程原则的解决方案，能够从根本上消除问题，并提升项目的可维护性和可扩展性。
• 替代策略：Maven配置。 如果重构不可行，通过在主应用的spring-boot-maven-plugin中显式指定mainClass，可以强制Spring Boot只启动预期的主应用。这种方法虽然有效，但可能不如模块重构那样彻底和优雅。

在设计多模块Spring Boot应用时，始终牢记“关注点分离”原则，并仔细规划模块间的依赖关系，将有助于避免此类问题的发生，并构建出健壮、易于管理的应用系统。