本文详解多模块 spring boot 项目的正确构建与独立部署策略，涵盖模块间依赖处理、各模块独立启动（不同端口）、生成多个可执行 jar 包，以及在 aws 等云平台上的主流部署方案。
在典型的多模块 Spring Boot 项目中（如 Module-A、Module-B、Module-C），每个子模块均标注 @SpringBootApplication 并配置独立端口（如 8080/8200/8300），且存在显式依赖关系（例如 Module-B 依赖 Module-A），这本质上是多个逻辑解耦的微服务应用，而非单体聚合应用。因此，不应也不可打包为“一个 JAR 并同时启动所有主类”——Spring Boot 不支持单个 JVM 中并行运行多个 SpringApplication.run() 实例（会引发端口冲突、上下文重名、Bean 注册冲突等严重问题）。
✅ 正确构建方式：模块化打包，各自为政
父 POM（Main-Module/pom.xml）应声明为 <packaging>pom</package>，并使用 <modules> 显式声明子模块：
<!-- Main-Module/pom.xml -->
<packaging>pom</packaging>
<modules>
<module>Module-A</module>
<module>Module-B</module>
<module>Module-C</module>
</modules>各子模块（如 Module-B）需继承父 POM，并显式声明 spring-boot-starter-parent 作为 parent 或通过 <dependencyManagement> 统一版本，同时添加 spring-boot-maven-plugin：
<!-- Module-B/pom.xml -->
<parent>
<groupId>com.example</groupId>
<artifactId>Main-Module</artifactId>
<version>1.0.0</version>
</parent>
<artifactId>Module-B</artifactId>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>Module-A</artifactId>
<version>${project.version}</version> <!-- 注意：依赖同版本的 Module-A -->
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>执行 mvn clean package 后，将在各子模块的 target/ 目录下生成三个独立的可执行 JAR 文件（如 Module-A-1.0.0.jar、Module-B-1.0.0.jar、Module-C-1.0.0.jar），每个均可通过 java -jar 单独启动：
# 分别启动（确保端口不冲突） java -jar Module-A/target/Module-A-1.0.0.jar # 默认或配置端口 8080 java -jar Module-B/target/Module-B-1.0.0.jar # 配置端口 8200 java -jar Module-C/target/Module-C-1.0.0.jar # 配置端口 8300
⚠️ 关键注意事项： 禁止在父模块中添加 spring-boot-maven-plugin —— 否则会导致构建失败或生成空/无效包；插件必须置于每个含 @SpringBootApplication 的子模块中。 子模块间依赖应使用 <scope>compile</scope>（默认），避免 provided 或 test 导致运行时类缺失。 各模块的 application.yml/application.properties 必须独立配置 server.port，推荐通过 application-{profile}.yml + 激活 profile 实现环境隔离。
☁️ 云平台部署推荐方案（以 AWS 为例）
由于是多个独立服务，部署必须按服务粒度进行，而非整体打包。AWS 提供多种成熟路径：
| 方案 | 适用场景 | 关键优势 | 参考文档 |
|---|---|---|---|
| AWS Fargate (ECS) | 推荐首选。容器化部署，免运维集群 | 无需管理 EC2 实例；自动扩缩容；天然支持多服务隔离与网络通信 | Deploy Java Microservices on ECS with Fargate |
| Elastic Beanstalk | 快速验证、CI/CD 初期 | 托管 Tomcat/Java SE 运行时；一键部署单个 JAR；支持负载均衡与健康检查 | Deploy Spring Boot on Elastic Beanstalk |
| EC2 自托管 | 需完全控制 OS/网络/安全策略 | 灵活性最高；可配合 systemd 管理多进程（如 systemd service files 分别守护各 JAR） | 需自行编写部署脚本与监控 |
? 实践提示：无论选择哪种云方案，务必为每个模块构建独立的部署单元（Fargate Task Definition、EB Application Version、EC2 Systemd Service）。切勿尝试将三个 JAR 打包进同一容器或同一 EB 应用——这违背微服务设计原则，且极易引发端口、日志、配置混乱。
✅ 总结
- 多 @SpringBootApplication 子模块 = 多个独立 Spring Boot 应用，必须分别构建、分别部署、分别运行；
- 父 POM 仅作依赖/版本协调，子模块各自启用 spring-boot-maven-plugin 生成可执行 JAR；
- 云部署应基于服务维度选型：Fargate 适合生产级容器编排，Elastic Beanstalk 适合快速上手，EC2 适合深度定制；
- 始终遵循 “Single Responsibility” 原则——一个 JAR，一个进程，一个端口，一个职责。
遵循此范式，即可稳健支撑从本地开发到云上生产的全链路多模块 Spring Boot 微服务部署。
