无入口类的Spring Boot微服务运行方式、选型原因及优势咨询

一、启用方式 #

这类项目不会单独启动，通常通过以下几种方式运行：

• 作为依赖模块嵌入主服务：项目本身是业务模块，依赖它的主项目带有@SpringBootApplication注解和main方法，主项目启动时会自动扫描该模块的组件（controller、service、repository等），完成上下文初始化
• 打包为WAR包部署到外部Servlet容器：pom.xml中会配置<packaging>war</packaging>，同时移除Spring Boot自带的嵌入式容器依赖（比如排除spring-boot-starter-tomcat），将WAR包部署到Tomcat、Jetty等容器中，由容器负责启动加载Spring上下文
• Docker镜像集成启动逻辑：镜像可能基于官方Spring Boot镜像，或者在构建时引入了包含启动类的父模块/依赖，镜像启动时会调用统一的入口类来加载该模块的业务组件

二、运行逻辑 #

• 组件扫描机制：如果是被主项目依赖，主项目的@SpringBootApplication默认开启组件扫描，只要该模块的包路径在主项目的扫描范围内，或者主项目通过@ComponentScan显式指定扫描路径，就能加载模块内的所有Spring组件
• 容器托管初始化：如果是WAR包部署，Servlet容器启动时会触发Spring的ContextLoaderListener，初始化Spring应用上下文，加载模块内的配置、Bean和业务逻辑，处理外部请求
• 父pom的核心作用：父pom会统一管理Spring Boot版本、依赖版本，还可能包含通用配置（比如组件扫描规则、全局配置项），甚至引入了带有启动逻辑的通用starter，确保模块能被正确加载

三、采用该架构的原因与优势 #

• 模块化复用：将业务逻辑拆分为独立模块，多个微服务可以直接依赖该模块，避免重复开发相同的业务流程，提升代码复用率
• 低耦合拆分：业务模块只专注于实现核心MVC业务逻辑，启动、配置等通用逻辑交给主项目或容器处理，降低模块间的耦合度，便于单独维护和迭代
• 部署灵活性：既可以作为嵌入模块随主服务一起启动，也可以单独打包为WAR包部署到外部容器，适配不同的部署场景和运维要求
• 版本统一管控：通过父pom统一管理所有依赖的版本，避免版本冲突问题，简化项目的依赖维护工作

内容的提问来源于stack exchange，提问作者rentox98