如果你在线上维护过SpringCloud微服务大概率有这种经历某个需求明明只改了几行代码push之后构建出来的可执行jar却依然是几百MB传到服务器动不动一两分钟十几个服务排队等着更新一次发布窗口硬生生被拖到几十分钟。问题不在网络带宽而在打包粒度。SpringBoot/SpringCloud项目的默认maven打包方式会把所有依赖全部塞进同一个可执行jar业务代码和第三方依赖永远绑定在一起。近两年我一直在折腾maven分离打包目标很朴素让业务代码、依赖库、配置文件各自独立谁变化谁重建发布体积能缩到原来的零头。这篇文章把我从实践中验证过的拆包思路、多模块工程分工、pom配置、发布目录结构以及那些只有踩过坑才知道的排查细节完整写出来希望对做SpringBoot/SpringCloud服务治理的同学有帮助。1. 生产发布的一个真实场景几百MB大jar包卡住了谁1.1 一次普通的订单中心服务升级我这边负责过一个订单中心的服务集群一共六个微服务各自承担用户、商品、订单、支付回调、对账、消息推送的职责。刚开始大家没在意打包方式所有服务都是标准的spring-boot-maven-plugin repackagepom里有什么依赖最终就生成一个几百MB的fat jar。一次常规需求迭代支付回调服务改了一个金额精度问题代码变动不超过几十行。构建机上跑完测试后产出了一个430MB的可执行jar。传到测试环境等待上传大概用了50秒启动注册又花了一分钟左右。这还只是一个服务六个服务如果所有模块都重新构建整个发布窗口接近半小时而且传输过程一旦中断还得重传整个文件。当时我做了个统计那个430MB的jar里去掉Spring框架和中间件客户端依赖业务代码的class文件压缩后只有不到8MB。也就是每次发版95%以上的传输内容其实根本没有变化全在为“依赖绑定”买单。1.2 分离打包分出的不是文件是变化频率后来我总结分离打包真正意义上的核心是把变化频率不同的东西分开管理。依赖库可能几个月才升一次版本业务代码几乎每次迭代都在变配置在不同环境永远不一样前端资源又有自己独立的发布节奏。这四个东西如果全部耦合在一个jar里任何一方的变化都会触发整包的重新构建和全量传输。把它们拆开之后发布就变成了“谁变了发谁”内容变化频率打包前打包后第三方依赖lib低打进jar胀大体积外置目录几乎不传业务代码业务jar高藏进boot-inf独立jar体积很小配置文件按环境打进jar环境不透明外置conf目录前端静态资源独立节奏打进jar和重启绑定外置目录独立更新这个表格基本就是我后面所有配置的指导思想。分离不是目的减少不必要的变化传递才是目的。2. 可执行jar的内部结构和加载机制先搞清楚再决定怎么拆2.1 一个可执行jar里其实藏了三层网上很多人直接拿工具解压SpringBoot的可执行jar看到里面有个BOOT-INF目录就以为“不过如此”。实际上要真正理解怎么拆得先知道这个jar的内部结构。我用一个标准SpringBoot 2.7版本的业务应用举例解压后大致是这样order-app.jar ├── BOOT-INF/ │ ├── classes/ # 业务class和打包时的resources │ └── lib/ # 所有第三方依赖jar都在这里 ├── META-INF/ │ ├── MANIFEST.MF # 启动入口声明 │ └── ... ├── org/ │ └── springframework/ │ └── boot/ │ └── loader/ # spring-boot-loader的类其中最关键的是META-INF/MANIFEST.MF它里面有两个属性Main-Class: org.springframework.boot.loader.JarLauncher Start-Class: com.example.order.OrderApplicationMain-Class是JVM在执行java -jar时真正加载的入口类也就是JarLauncher。它做的事情非常像一个大管家先读取MANIFEST里的Start-Class再构造一个自定义的类加载器把BOOT-INF/classes和BOOT-INF/lib里每一个jar都挂到这个类加载器上最后反射调用业务启动类的main方法。用生活化的类比来说BOOT-INF/classes是营业现场BOOT-INF/lib是仓库JarLauncher就是把仓库里的货物按清单搬到营业现场的搬运工。默认情况下搬运工只认“现场仓库”两个位置所以一切都被绑在一个jar里。2.2 PropertiesLauncher带来的loader.path外置依赖的钥匙SpringBoot的loader其实不止JarLauncher一种还有WarLauncher和PropertiesLauncher。当MANIFEST中的Main-Class被替换为org.springframework.boot.loader.PropertiesLauncher时它的行为就变了除了读取BOOT-INF/classes和BOOT-INF/lib它还会去指定的外部目录加载jar。这个外部目录就是loader.path。比如你有一个可执行jar想把依赖放到/opt/order/lib目录启动命令可以写成java -jar order-app.jar --loader.path/opt/order/libPropertiesLauncher会把这个外部目录加入类加载路径。这就是“依赖外置”的官方通道也是所有分离打包方案能成立的根本原因。需要特别提醒的是如果你打算完全外置依赖那么打包时就要避免依赖同时出现在BOOT-INF/lib里否则同一个机器上有两份相同GAV的jar启动时会看到很多奇怪的类冲突。这一点我在第4章会给出具体的处理方式。2.3 为什么不能让每个模块都生成可执行jar很多多模块项目在初期容易犯一个错为了“每个模块都能独立启动”给所有模块都配了spring-boot-maven-plugin。于是common模块打出一个可执行jarservice模块也打出一个可执行jar这些jar每个都自带一个完整的SpringBoot loader和全套依赖。实际结果往往是依赖重复、构建时间爆炸甚至在工程内部互相引用时出现类加载诡异问题。因为可执行jar的类路径是嵌套结构普通jar的加载方式并不兼容它。正确的角色划分是只有真正包含main方法的启动器模块才能打包成可执行jar其他模块一律是普通jar作为依赖被组合。这个边界划清楚之后第3章的多模块分工才有意义。3. 多模块工程重新分工公共层、业务层、启动器各管什么3.1 模块边界和依赖方向的约定我当时重构订单中心时把原来的一坨单模块工程拆成了三个基础模块order-common纯工具类、常量、公共DTO、异常定义尽量不依赖Spring容器。order-service业务实现领域服务、仓储接口、消息处理逻辑都在这层依赖common。order-app启动器只放启动类、少量全局配置依赖service。依赖方向是严格单向的order-app - order-service - order-common任何下层模块不允许反向依赖上层。这条铁律在打包时特别重要如果出现循环依赖maven会在构建阶段直接报错而到了分离打包阶段错误的依赖关系还会让外置lib目录里出现莫名其妙的jar。3.2 父pom如何把版本和插件管起来多模块工程统一管理版本靠的是父pom里的dependencyManagement和pluginManagement。dependencyManagement只管理版本不实际引入依赖。子模块声明依赖时即使不写版本号也会从父pom继承。这样所有模块的SpringBoot版本、common模块版本、中间件客户端版本都被钉在同一个地方。dependencyManagement dependencies dependency groupIdcom.example/groupId artifactIdorder-common/artifactId version${revision}/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version2.7.18/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement build pluginManagement plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version2.7.18/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version3.6.1/version /plugin /plugins /pluginManagement /build这里用${revision}还有一个好处配合flatten-maven-plugin可以让整个工程的版本号只维护一次子模块不用各自写死版本。这个技巧对多模块打包的场景非常有用避免“改了公共模块版本几个子模块没同步”的尴尬。3.3 哪些模块必须跳过spring-boot-maven-plugincommon和service模块的pom里不需要声明spring-boot-maven-plugin它们产出普通jar即可。如果不小心继承了父pom里已经配置好的插件又不想让某个模块参与可执行jar打包可以在该模块的pom里显式跳过build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration skiptrue/skip /configuration /plugin /plugins /build而order-app模块才真正执行repackage目标并把finalName固定成一个不带版本号的名字方便发布脚本通配build finalNameorder-app/finalName plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration mainClasscom.example.order.OrderApplication/mainClass /configuration executions execution goals goalrepackage/goal /goals /execution /executions /plugin /plugins /build很多刚接触分离打包的同学在这里会有一个疑惑既然要分离打包为什么还保留repackage因为order-app模块生成的仍然是一个标准可执行jar它保证开发环境和测试环境可以一键java -jar启动真正的“分离”发生在发布环节由第4章的两种方式接管。4. 依赖外置的两种落地方式目录化发布和PropertiesLauncher实战4.1 方式一把可执行jar拆成标准目录用java -cp启动这是我在生产环境里最常推荐的方式。它完全抛弃了“可执行jar是唯一部署单位”的思路改为构建一个标准发布目录发布系统直接分发目录的压缩包。实现它只需要三步第一步在order-app模块的pom中用maven-jar-plugin把启动器本身打成普通jar这一步确保产物是标准jar内部没有BOOT-INF嵌套结构plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest mainClasscom.example.order.OrderApplication/mainClass /manifest /archive /configuration /plugin第二步用maven-dependency-plugin把运行时依赖全部复制到发布目录的lib文件夹。这一步是把几百MB依赖从“jar内部”挪到“jar外部”的关键plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId executions execution idcopy-dependencies/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration outputDirectory${project.build.directory}/release/lib/outputDirectory includeScoperuntime/includeScope /configuration /execution /executions /pluginincludeScope这里我特意设成runtime因为compile和runtime范围内的依赖才需要在运行期间出现像test和provided范围的依赖不需要进发布目录。第三步编写启动脚本用java -cp直接拉起启动类#!/bin/bash APP_NAMEorder-app BASE_DIR$(cd $(dirname $0)/.. pwd) CONF_DIR$BASE_DIR/conf LIB_DIR$BASE_DIR/lib APP_JAR$BASE_DIR/app/$APP_NAME.jar nohup java $JAVA_OPTS -Dspring.config.location$CONF_DIR/application.yml \ -cp $CONF_DIR:$APP_JAR:$LIB_DIR/* \ com.example.order.OrderApplication \ $BASE_DIR/logs/startup.log 21 最终生成的发布目录是这样的release/ ├── bin/start.sh ├── conf/application.yml ├── lib/ # 所有第三方依赖约几百MB ├── app/order-app.jar # 业务代码很小 └── logs/这套结构最大的好处是发布时只需要替换app目录下的业务jar和conf目录下的配置文件lib目录除非依赖升级否则几个月都不用动。配合CI构建产物从几百MB缩到了十几MB传输时间直接降到十秒内。4.2 方式二保留java -jar用loader.path指向外部lib有些团队的运维脚本已经固化了java -jar命令不愿意改成java -cp。这种情况可以走PropertiesLauncher这条路。做法是让order-app模块的repackage采用ZIP layout这样生成的MANIFEST里Main-Class会是PropertiesLauncherconfiguration mainClasscom.example.order.OrderApplication/mainClass layoutZIP/layout /configuration启动命令变成java -jar order-app.jar --loader.path/opt/order/lib这里有一个绕不开的问题默认repackage时所有非provided的依赖仍然会打进BOOT-INF/lib如果外置lib目录里也放一份Classes加载时可能会出现同一个类的两套版本。我的处理方式是业务模块相关的依赖用provided scope保证它们不进jar只出现在外置lib目录第三方框架依赖保留默认让jar自己携带。这样调整之后业务代码更新时只替换外置lib里的业务jar第三方依赖仍然留在jar里不动传输体积同样能控制在几十MB以内又保留了java -jar的启动习惯。4.3 两条路怎么选从实操角度看两种方式没有绝对优劣主要看团队的发布脚本和运维习惯对比项目录化发布java -cploader.pathjava -jar启动方式脚本控制classpath标准java -jar依赖控制外置目录全量控制直观可能发生jar内与外置目录重复配置文件外置通过-classpath指定灵活靠SpringBoot外部配置优先级构建复杂度略高需要写脚本只需改layout配置适合场景运维自己管理发布目录已有标准化java -jar流程我个人会把目录化发布作为默认选项因为它把classpath完全交给脚本排查问题的时候一眼能看清加载了什么不用去猜jar里藏了什么依赖。5. 配置和前端资源的分手现场外置策略和权限细节5.1 外部配置的加载顺序和边界依赖拆完之后下一步就是配置文件外置。SpringBoot默认的外部配置加载顺序中jar包同级目录下的config文件夹优先级最高其次是jar包同级目录再往下才是classpath内的配置文件。这就是为什么很多生产环境把application.yml放在jar旁边的config目录里靠的是规则而不是硬编码。如果你用目录化发布则可以在启动脚本里显式指定位置-Dspring.config.location$BASE_DIR/conf/application.yml注意spring.config.location一旦指定它会替换默认的加载位置也就是说jar内的application.yml不会再被读取。如果你希望“外部配置优先jar内配置兜底”应该用另一个参数-Dspring.config.additional-location$BASE_DIR/conf/这两个参数的区别我踩过一次坑之后才彻底记住前者是“覆盖”后者是“追加”。生产环境里做配置收敛时用spring.config.location更严格开发环境为了保持灵活性用spring.config.additional-location更舒服。5.2 SpringCloud配置中心和本地配置的分工在SpringCloud场景下配置文件外置还要多考虑一层哪些配置留本地哪些进配置中心。我的做法是本地conf/application.yml只保留启动阶段必须的东西——服务名、端口、注册中心地址、配置中心地址。剩下所有业务开关、数据源参数、熔断阈值全部放到配置中心。这样“启动引导”和“业务参数”彻底分离打包时再也不用为了某个环境变量的差异准备多套yaml。配置中心的地址本身也不能写死否则换一套环境又得改jar配置。我会在启动脚本里通过环境变量注入export CONFIG_SERVER_ADDR${CONFIG_SERVER_ADDR:-http://config:8888}这里的环境变量默认值可以保证本地开发、测试环境、生产环境共用同一份启动包真正实现“一次构建到处运行”。5.3 前端静态资源外置不发后端版本的前端更新SpringBoot默认的静态资源路径是classpath:/static/如果前端把构建产物打进后端jar那么前端改版就意味着后端重新发版跨部门协作的成本很高。分离打包的后期我直接把前端产物放到服务外部并通过配置指向它spring: web: resources: static-locations: file:/data/order/static/这样前端只需要把dist目录同步到服务器后端服务完全不需要重启。需要提醒的是这种外置静态目录要做好访问权限控制避免出现路径遍历之类的低级安全风险目录的读权限给到运行用户就够了不要给整个服务账号放开过大权限。6. 打包完成之后的启动验证、经典踩坑与容器化分层对照6.1 发布前的本地验证三板斧分离打包之后手工作坊式的“构建-上传-启动”必须升级成标准化的验证流程。我在每次发布前固定做三件事第一步检查发布包内容。用jar tf或者直接解压确认app/order-app.jar里没有多余的BOOT-INF目录lib目录里依赖齐全jar tf order-app.jar | grep -E OrderApplication|BOOT-INF | head -20第二步本地模拟启动。用和发布脚本完全一致的命令在测试机跑一次重点看启动日志里的classpath确认lib目录被正确加载。第三步检查配置加载。启动完成后查看/actuator/env里application.yml的来源路径或者直接看配置中心是否连上排除配置给到旧文件的情况。这三板斧看着简单却能提前拦截掉80%的发布事故。6.2 三个高频踩坑和完整排查链路我把自己经历过的三个典型问题整理成完整排查链路希望对你有参考价值。第一个启动直接报ClassNotFoundException。这是分离打包最常踩的坑。我当时的排查顺序是先看lib目录里到底有没有这个类对应的jar执行find lib -name *.jar | xargs -I{} unzip -l {} 2/dev/null | grep 具体类名如果发现没有说明maven-dependency-plugin的includeScope过滤太严了或者该依赖被标成了provided但运行时又需要。解决办法是把依赖scope调整成runtime或者把includeScope放宽后再打包。第二个配置改了却不生效。这个问题的典型特征是外置conf/application.yml改了端口重启后原端口还在。根因通常是启动脚本里忘加了spring.config.location或者同时开了config目录又没有加additional-location导致加载顺序错乱。排查链路很简单先查进程的启动参数再查配置中心对应服务的配置版本最后看actuator/env显示的来源。第三个NoSuchMethodError或者类冲突。这往往是因为外置lib目录里的某个jar和BOOT-INF/lib里重复但版本不一致。排查时用mvn dependency:tree锁定冲突来源然后在外置lib里删掉多余的一份保证一台机器上同一个GAV只出现一次。6.3 容器化场景下的分层分离对照如果你的服务已经容器化那么“分离打包”的思路在Docker世界里同样成立只是换了一种表现形式。SpringBoot 2.3开始提供了layertools可以把可执行jar按依赖层和业务层拆分Docker构建时利用镜像分层缓存只有业务层变化时重建依赖层可以复用FROM builder AS builder WORKDIR /app RUN java -Djarmodetools -jar order-app.jar extract FROM runtime COPY --frombuilder /app/dependencies/ ./ COPY --frombuilder /app/snapshot-dependencies/ ./ COPY --frombuilder /app/spring-boot-loader/ ./ COPY --frombuilder /app/application/ ./ ENTRYPOINT [java, org.springframework.boot.loader.launch.JarLauncher]这个手法的思想和maven分离打包完全一致把变化频率低的依赖层留在镜像缓存里只有业务层变化才重新构建。区别在于maven分离打包针对的是传统服务器发布而layertools针对的是容器镜像体积和构建缓存。无论是哪种方式底层的原则都是同一句话把变化慢的和变化快的东西分开让一次简单的代码变更不需要背负全量依赖的传输成本。我自己在实际项目中的体会是分离打包的第一步永远不是去改pom而是先想清楚哪个模块在什么频率下变化。模块边界清楚了pom配置只是执行层面的水到渠成。如果你现在正被几百MB的大jar包困扰建议先挑一个流量最小的服务试点把目录化发布跑通再逐步推广到整个服务集群别一口气全推倒重来。