先聊几句题外话。我见过太多项目在本地跑得好好的一上服务器就各种花式出问题时间差8小时、中文乱码、进程三天两头挂掉、日志不知道去哪了、升级一次心惊胆战。这些事见多了之后我慢慢意识到SpringBoot项目部署这个看似基础的话题其实比大多数人想的有嚼头。不是说会用java -jar启动就完事了部署背后是一整套体系环境准备、JVM参数、配置管理、进程托管、发布回滚、监控排查每一步都有值得展开的细节。这篇内容就把我在实际部署SpringBoot项目中沉淀下来的经验做个梳理适合刚接触部署的初学者也适合已经部署过但总在边缘问题上栽跟头的人对照着看看。1. 先理顺一件事部署到底在解决什么问题1.1 “进程起来了”和“服务可用了”之间隔着一整个工程很多初学者对部署的理解停留在“把jar包扔上去执行java -jar看到端口监听就完事了”。这个理解不能说错但它把部署这个事看得太简单了。我遇到过真实情况进程确实起来了日志也在刷但接口一调用就超时排查半天发现是时区不对导致缓存key错乱还有一次是服务器重启之后服务没跟着起来业务方半夜打电话才知道应用挂了几个小时没人发现。如果拆开看部署至少要回答这几个问题这个应用在什么环境下运行JDK版本是哪个参数怎么传同一份代码怎么在不同环境开发、测试、生产间切换配置进程挂了谁来拉起服务器重启了要不要自动恢复日志写到哪文件怎么切割、怎么清理不然磁盘满了怎么办发新版的时候怎么做到少停机、可回滚这些问题如果都处理好了部署才算真正完成。只把进程跑起来只是万里长征第一步。1.2 部署形态选型进程守护、容器化、编排各自适用哪里部署方案的选型往往决定了后面所有操作的手感。我自己用下来主流形态大致有三种各有各的适用场景没有绝对的好坏。部署形态上手难度适合场景主要短板jar systemd进程守护低中小项目、单机部署、团队规模小环境迁移依然要手动处理扩展靠堆机器单机容器化docker run中想在每台机器上统一运行环境容器本身不解决跨机器编排多节点还是要自己管容器编排k8s这类高多实例、高可用、弹性伸缩要求高的场景运维复杂度明显上升小团队容易撑不住就我的经验而言大多数团队从jar systemd起步是足够用的也是性价比最高的。它不需要额外引入一套容器体系systemd是Linux自带的服务管理工具配置一个service文件就能把SpringBoot应用托管得明明白白进程守护、开机自启、崩溃拉起全都覆盖了。等业务量真的大到需要横向扩展、需要滚动发布的时候再逐步过渡到容器化也不迟——到那时候你对JVM参数、配置管理、优雅停机这些底层细节的理解越扎实容器化改造反而越顺畅。2. 部署前的环境准备把服务器收拾成适合SpringBoot运行的样子2.1 用户、目录、权限一次规划好很多人习惯用root账号直接跑应用图省事。但这个习惯在出问题的时候特别坑一是安全上一旦应用被利用攻击者直接拿到root权限二是运维上如果哪天服务器上同时跑好几个应用都用root管理日志归属、文件权限会乱成一锅粥。我现在的标准做法是单独创建一个运行用户专门用来跑应用。目录结构大致长这样/opt/app/ ├── current/ # 软链指向当前发布版本 ├── releases/ # 存放历史发布版本比如 app-20240112-1015.jar ├── logs/ # 应用日志 ├── backup/ # 回滚前的备份 └── conf/ # 外部配置文件放敏感配置或动态配置这样规划的好处是应用包和日志分离发布时不会污染日志目录通过软链切换版本回滚只需要改一下软链再重启即可配置文件放在应用包外部升级程序包的时候不用重新配置。这个习惯帮我在后面几次紧急发布里省了很多事。创建好用户和目录之后记得把目录归属给那个运行用户避免出现“进程没权限写日志”这类低级问题。2.2 JVM参数模板与含义JVM参数是部署里的重头戏也是出错率最高的地方。我整理了一份自己常用的模板先贴出来再逐个解释为什么这么设置java -server \ -Xms1024m -Xmx1024m \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/app/logs/ \ -Xloggc:/opt/app/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps \ -Duser.timezone东八区 \ -Dfile.encodingUTF-8 \ -jar /opt/app/current/app.jar \ --spring.profiles.activeprod几个关键参数逐个说-Xms和-Xmx初始堆大小和最大堆大小。我习惯把两者设为一致避免运行期堆扩容带来的性能抖动。具体给多大得看机器内存和应用特性。我踩过的坑就是拍脑袋给一个大值结果部署机器上同时跑了好几个服务内存一起暴涨最后OOM。合理做法是估算应用的内存占用再留出给操作系统和buffer cache的空间比如机器总内存8G单个应用给2G比较稳妥别贪多。这不是精确的科学但多观察几次就心里有数了。-XX:MetaspaceSize和MaxMetaspaceSize元空间大小放类元数据。SpringBoot项目依赖多类多默认值在低配机器上容易触发扩容显式给一个初始值能减少启动期的Full GC概率。GC收集器JDK8默认的ParallelGC吞吐量好但延迟不稳定。JDK8以上的版本用G1已经很成熟我这边线上用的是G1GC停顿时间更可控适合大多数Web服务。现在JDK11和JDK17的G1表现都挺好不需要再做额外调优。OOM相关HeapDumpOnOutOfMemoryError和HeapDumpPath这两个参数强烈建议加上。等应用OOM之后再登录上去用jmap手工导dump往往已经晚了让JVM自己留下“案发现场”后面排查效率会高很多。时区和编码这个是老生常谈但也最容易犯的错。服务器默认时区可能是UTC而业务数据要求的是东八区时间。同样文件编码乱码的问题也是因为服务器默认字符集和代码假设不一致。我习惯在启动命令里直接显式指定不受环境变量影响。2.3 文件句柄与进程数量的隐藏限制还有两个容易被忽略的系统级限制文件句柄数和用户最大进程数。SpringBoot应用在运行时会打开大量文件句柄socket连接、日志文件等默认的ulimit -n在某些系统上只有1024并发稍微高一点就会出现“Too many open files”错误非常误事。我一般会在启动脚本里先查看一下或者直接在systemd服务配置里通过LimitNOFILE指定一个比较大的值比如65535。这个操作虽然不起眼但那些“应用运行几天后突然完全不可用”的线上故障有很大一部分就是文件句柄耗尽引起的。3. 构建与配置让一个jar包能装进任何环境3.1 Maven多环境Profile与打包命令部署的前提是能拿到一个合适环境的构建产物。实际项目里通常有开发、测试、生产等多个环境这些环境的数据库地址、Redis连接、接口地址都不一样。如果每次发版前手动改配置再打包太容易出错甚至出现过把测试环境的配置发到生产的事故。我的做法是在Maven里配置多Profile每个环境一套properties。比如profiles profile iddev/id propertiesenvdev/env/properties /profile profile idprod/id propertiesenvprod/env/properties /profile /profiles然后配合Spring Boot的application-{profile}.yml机制把环境差异放在各自的配置文件中公共配置留在application.yml。打包时用上-P参数mvn clean package -DskipTests -Pprod这里有两个细节容易踩坑。第一spring-boot-maven-plugin的repackage目标会把项目打成可执行jar插件版本要和SpringBoot版本匹配否则打出来的包可能只是个普通jar跑起来就是“no main manifest attribute”。第二打包机上的环境变量会影响Maven的行为编译前看一眼是否干净别让本机配置串进生产包。3.2 敏感信息不要写进配置文件数据库密码、密钥这类东西直接写在application-prod.yml里然后整个仓库打进去等于把钥匙放在门上。我项目里的做法是配置文件中只留占位符真正的值通过环境变量注入。SpringBoot的配置优先级是环境变量 外部配置文件 jar内的配置文件。也就是说运行环境里的环境变量天然能覆盖jar包内的默认值。实际操作时我在启动脚本或systemd配置里通过Environment或EnvironmentFile注入关键变量比如DB_PASSWORDxxx REDIS_PASSWORDxxx这样即使包被泄露敏感信息也还在可控范围内。如果情况更复杂还可以引入加密配置的框架但我建议先把环境变量这套用好它已经能解决绝大多数问题。3.3 配置文件的外部化技巧还有一类配置变化频繁不适合每次重新打包比如某些业务开关、路由规则。这类配置我建议放到jar包外部的/opt/app/conf/目录然后通过启动参数指定--spring.config.additional-location/opt/app/conf/这样修改外部配置后只需重启服务而不用重新构建整个应用。对运维来说这可太省事了。需要注意的是这个additional-location的优先级比jar内配置高比环境变量低用的时候心里有数就行。4. systemd托管让SpringBoot像系统服务一样被管理4.1 服务单元文件示例当你能用一行java -jar把应用跑起来下一步就是让它更“听话”。Linux自带的systemd就能把SpringBoot应用变成一个标准的系统服务享有开机自启、崩溃重启、日志统一管理等能力。下面是一个我打磨过的service文件[Unit] DescriptionSpringBoot App Afternetwork.target [Service] Userappuser Groupappuser WorkingDirectory/opt/app/current EnvironmentFile/opt/app/conf/app.env ExecStart/usr/bin/java -server -Xms1024m -Xmx1024m \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/app/logs/ \ -Duser.timezone东八区 \ -Dfile.encodingUTF-8 \ -jar /opt/app/current/app.jar \ --spring.profiles.activeprod ExecStop/bin/kill -TERM $MAINPID Restartalways RestartSec10 LimitNOFILE65535 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target这里有几个关键点ExecStop用kill -TERM而不是kill -KILL这关系到优雅停机。SpringBoot收到SIGTERM信号后会主动执行关闭流程等处理完当前请求再退出。如果直接KILL就可能中断用户请求造成数据不一致。Restartalways是给进程买的一份“意外险”进程因OOM或者异常退出时systemd会自动拉起它。EnvironmentFile用来注入敏感环境变量放在conf目录下的app.env里权限设为600避免其他用户读取。配置文件写好之后执行两步sudo systemctl daemon-reload sudo systemctl enable myapp.serviceenable是注册开机自启。这一步很多人会漏手动跑完发现一切正常结果服务器重启后服务还是没起来。4.2 日志怎么收集和切割日志是部署后唯一的“黑匣子”出了问题只能靠它。我刚接触systemd时习惯用journalctl -u myapp看日志确实方便。但journal的大小如果不控制时间久了会吃掉大量磁盘空间。更推荐的做法是应用日志交给logback自己管理通过logback-spring.xml配置滚动策略。比如按天滚动每份日志文件上限100MB最多保留30天这样磁盘空间可控而且日志文件是明文用tailing或者grep都顺手。systemd的journal则当作第二层兜底捕获应用启动早期还没初始化好logback时的一些输出。有一点要强调如果你用System.out.println打日志这些输出默认走的是标准输出会被systemd捞走但也会增加journal的存储量。开发阶段无所谓生产环境尽量统一走logback代码里别乱用System.out后面日子会好过很多。4.3 日常运维命令与健康检查托管到systemd之后日常操作就是几个命令的事systemctl start myapp systemctl status myapp systemctl restart myapp journalctl -u myapp -f配合健康检查使用更稳妥。SpringBoot如果引入了Actuator天然有/actuator/health端点。部署完成后用curl验证curl -f http://127.0.0.1:8080/actuator/healthcurl返回的退出码可以用在发布脚本里做自动化判断。记得生产环境要把这个健康检查端口只暴露给内网或本机别直接扔到公网上裸奔。5. 发布与回滚部署里真正见功力的一步5.1 发布目录结构与软链方案部署前规划好的目录现在派上用场了。我把新旧版本都放在/opt/app/releases/下命名带上时间戳然后在/opt/app/current做一个软链指向当前版本。比如/opt/app/releases/app-20250110-1430.jar /opt/app/releases/app-20250110-1600.jar /opt/app/current - /opt/app/releases/app-20250110-1600.jar发布新版本时把新包传到releases目录更新软链指向新包重启服务。整个过程不删除旧包万一新版有问题只要把软链改回去再重启就完成回滚。5.2 发布脚本的关键步骤我用的发布脚本思路大致是这样的上传新jar包到releases目录。通过/actuator/health确认当前服务正常避免带着半死不活的状态做发布。向进程发送SIGTERM信号等待优雅退出。SpringBoot的server.shutdowngraceful和spring.lifecycle.timeout-per-shutdown-phase这两个配置可以把停机的宽限期兜住给正在处理的请求一个体面的收尾时间。更新软链指向新包。启动服务。循环调用健康检查等返回200再继续。检查应用日志末尾是否有异常堆栈。这是一个简化的流程但核心思想是对的先确认旧的不坏再切新的最后验证新的可用。曾经我偷懒跳过第2步结果旧服务早就OOM挂了我却还在上面盲目操作最后排查了半天才发现问题根源。5.3 回滚与灰度把变化控制在最小范围回滚本质上就是把软链指回上一个版本然后重启。但这里有个隐蔽的坑如果新版启动时改了数据库表结构或者升级了配置回滚到旧版可能因为不兼容而继续报错。所以发布前对数据库变更要做兼容性评估这是经验不是脚本能解决的。灰度发布在大多数中小团队可以做得轻量一点先在一台实例上发布新版本观察日志和指标确认稳定后再逐步扩展到其他实例。这比一次全量替换要稳妥得多。我经历过一次不加灰度直接全量换结果新版本有一个隐蔽的连接泄漏问题半个小时后所有实例同时告警那叫一个手忙脚乱。6. 部署后的可观测性健康检查、监控与排障6.1 健康检查不只是“通不通”Actuator的health端点返回的只是UP/DOWN但生产环境的可用性比这复杂。我更习惯在部署后立刻验证几个核心依赖的状态数据库能不能连、Redis能不能通、消息队列是否正常。SpringBoot允许自定义health指示器把数据库、Redis、MQ都纳入检查范围。在此基础上很多监控系统都支持HTTP探针周期性请求health端点出现非200就告警。这套组合拳能有效缩短故障发现时间而不是等用户打电话来才知道系统挂了。6.2 日志排障的几个实用技巧日志文件落盘之后批量grep就成了最趁手的排查工具。比如看到某个任务今天没跑成功直接grep ERROR /opt/app/logs/app.log | grep 2025-01-10 14 | head -50我还会在应用里对关键业务打上唯一日志标记比如订单号、任务ID这样链路排查时从一个入口ID能带出整条处理日志。日志里包含这些上下文标记比一堆冗长堆栈有价值得多。6.3 基础监控指标CPU、内存、GC一个都不能少部署完成后还需要关注机器层面的指标否则进程活着不代表真的健康。我在实际运维中最常查看的是这么几项CPU使用率和平均负载观察是否存在计算热点内存使用量确认堆外内存有没有被滥用GC频率和停顿时间长时间Full GC会导致接口大面积超时磁盘空间日志写满磁盘是运维事故里最常见的一类。有个简单方法可以观察GC情况从日志文件里统计或者用JDK自带工具连接进程查看。实践下来GC数据能帮你提早预判系统容量瓶颈——在还没出大事之前就把问题处理掉比事后救火舒服太多。7. 几次真实部署踩坑后的经验沉淀7.1 JVM参数拍脑袋分配差点拖垮服务器有一回给某个服务配置JVM参数觉得机器内存大就给一次性分配了4个G堆。结果那台机器上还有其他服务在跑内存一上来就被榨干swap开始疯狂读写整个机器卡到连SSH都半天才响应。后来我总结出一个习惯给应用分配内存时先估算基础水位再留出至少20%的系统余量如果机器上跑多个应用总分配量要低于物理内存绝不做“每个应用都觉得自己独占整台机器”的美梦。7.2 发布脚本漏掉stop导致两个实例抢端口有一次写自动化发布脚本时先执行了start却把stop步骤放在了start后面。实际上因为脚本是分步执行的旧进程还在监听端口新进程启动时端口被占用直接start失败但旧进程也被回收了等于那一段服务彻底不可用。排查了很久才发现是脚本执行顺序混乱造成的。从那次之后我严格要求先发SIGTERM停旧进程、确认端口释放、再启动新进程每一步前后都要有检查动作绝不能让脚本“碰运气”。7.3 回滚后配置还是旧的还有一次发布新版后发现问题回滚到旧版却依旧报错。查了半天发现新版启动时修改了外部配置文件旧版读取的配置已经被带偏了。从那以后我意识到配置文件要放进版本控制里跟着走发布时通过软链的方式切换整个配置目录而不是“每个版本临时改一把”。配置和程序包做到同步版本化才能保证回滚是真正干净的。现在回看SpringBoot项目部署这件事表面上是几个命令的排列组合实际上是对运行环境、配置管理、进程生命周期、发布策略这些基本功的综合考验。它不像写业务代码那样能快速看到成果却决定了应用真正交到用户手里之后的每一秒体验。上面写到的这些方法和教训都是我一步步从踩坑里捡回来的。如果你正准备上线某个SpringBoot项目我建议先别急着敲启动命令花一天时间把环境、目录、systemd配置、发布脚本这几件事情理清楚后面会省下无数个焦头烂额的深夜。
先聊几句题外话。我见过太多项目在本地跑得好好的一上服务器就各种花式出问题时间差8小时、中文乱码、进程三天两头挂掉、日志不知道去哪了、升级一次心惊胆战。这些事见多了之后我慢慢意识到SpringBoot项目部署这个看似基础的话题其实比大多数人想的有嚼头。不是说会用java -jar启动就完事了部署背后是一整套体系环境准备、JVM参数、配置管理、进程托管、发布回滚、监控排查每一步都有值得展开的细节。这篇内容就把我在实际部署SpringBoot项目中沉淀下来的经验做个梳理适合刚接触部署的初学者也适合已经部署过但总在边缘问题上栽跟头的人对照着看看。1. 先理顺一件事部署到底在解决什么问题1.1 “进程起来了”和“服务可用了”之间隔着一整个工程很多初学者对部署的理解停留在“把jar包扔上去执行java -jar看到端口监听就完事了”。这个理解不能说错但它把部署这个事看得太简单了。我遇到过真实情况进程确实起来了日志也在刷但接口一调用就超时排查半天发现是时区不对导致缓存key错乱还有一次是服务器重启之后服务没跟着起来业务方半夜打电话才知道应用挂了几个小时没人发现。如果拆开看部署至少要回答这几个问题这个应用在什么环境下运行JDK版本是哪个参数怎么传同一份代码怎么在不同环境开发、测试、生产间切换配置进程挂了谁来拉起服务器重启了要不要自动恢复日志写到哪文件怎么切割、怎么清理不然磁盘满了怎么办发新版的时候怎么做到少停机、可回滚这些问题如果都处理好了部署才算真正完成。只把进程跑起来只是万里长征第一步。1.2 部署形态选型进程守护、容器化、编排各自适用哪里部署方案的选型往往决定了后面所有操作的手感。我自己用下来主流形态大致有三种各有各的适用场景没有绝对的好坏。部署形态上手难度适合场景主要短板jar systemd进程守护低中小项目、单机部署、团队规模小环境迁移依然要手动处理扩展靠堆机器单机容器化docker run中想在每台机器上统一运行环境容器本身不解决跨机器编排多节点还是要自己管容器编排k8s这类高多实例、高可用、弹性伸缩要求高的场景运维复杂度明显上升小团队容易撑不住就我的经验而言大多数团队从jar systemd起步是足够用的也是性价比最高的。它不需要额外引入一套容器体系systemd是Linux自带的服务管理工具配置一个service文件就能把SpringBoot应用托管得明明白白进程守护、开机自启、崩溃拉起全都覆盖了。等业务量真的大到需要横向扩展、需要滚动发布的时候再逐步过渡到容器化也不迟——到那时候你对JVM参数、配置管理、优雅停机这些底层细节的理解越扎实容器化改造反而越顺畅。2. 部署前的环境准备把服务器收拾成适合SpringBoot运行的样子2.1 用户、目录、权限一次规划好很多人习惯用root账号直接跑应用图省事。但这个习惯在出问题的时候特别坑一是安全上一旦应用被利用攻击者直接拿到root权限二是运维上如果哪天服务器上同时跑好几个应用都用root管理日志归属、文件权限会乱成一锅粥。我现在的标准做法是单独创建一个运行用户专门用来跑应用。目录结构大致长这样/opt/app/ ├── current/ # 软链指向当前发布版本 ├── releases/ # 存放历史发布版本比如 app-20240112-1015.jar ├── logs/ # 应用日志 ├── backup/ # 回滚前的备份 └── conf/ # 外部配置文件放敏感配置或动态配置这样规划的好处是应用包和日志分离发布时不会污染日志目录通过软链切换版本回滚只需要改一下软链再重启即可配置文件放在应用包外部升级程序包的时候不用重新配置。这个习惯帮我在后面几次紧急发布里省了很多事。创建好用户和目录之后记得把目录归属给那个运行用户避免出现“进程没权限写日志”这类低级问题。2.2 JVM参数模板与含义JVM参数是部署里的重头戏也是出错率最高的地方。我整理了一份自己常用的模板先贴出来再逐个解释为什么这么设置java -server \ -Xms1024m -Xmx1024m \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/app/logs/ \ -Xloggc:/opt/app/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps \ -Duser.timezone东八区 \ -Dfile.encodingUTF-8 \ -jar /opt/app/current/app.jar \ --spring.profiles.activeprod几个关键参数逐个说-Xms和-Xmx初始堆大小和最大堆大小。我习惯把两者设为一致避免运行期堆扩容带来的性能抖动。具体给多大得看机器内存和应用特性。我踩过的坑就是拍脑袋给一个大值结果部署机器上同时跑了好几个服务内存一起暴涨最后OOM。合理做法是估算应用的内存占用再留出给操作系统和buffer cache的空间比如机器总内存8G单个应用给2G比较稳妥别贪多。这不是精确的科学但多观察几次就心里有数了。-XX:MetaspaceSize和MaxMetaspaceSize元空间大小放类元数据。SpringBoot项目依赖多类多默认值在低配机器上容易触发扩容显式给一个初始值能减少启动期的Full GC概率。GC收集器JDK8默认的ParallelGC吞吐量好但延迟不稳定。JDK8以上的版本用G1已经很成熟我这边线上用的是G1GC停顿时间更可控适合大多数Web服务。现在JDK11和JDK17的G1表现都挺好不需要再做额外调优。OOM相关HeapDumpOnOutOfMemoryError和HeapDumpPath这两个参数强烈建议加上。等应用OOM之后再登录上去用jmap手工导dump往往已经晚了让JVM自己留下“案发现场”后面排查效率会高很多。时区和编码这个是老生常谈但也最容易犯的错。服务器默认时区可能是UTC而业务数据要求的是东八区时间。同样文件编码乱码的问题也是因为服务器默认字符集和代码假设不一致。我习惯在启动命令里直接显式指定不受环境变量影响。2.3 文件句柄与进程数量的隐藏限制还有两个容易被忽略的系统级限制文件句柄数和用户最大进程数。SpringBoot应用在运行时会打开大量文件句柄socket连接、日志文件等默认的ulimit -n在某些系统上只有1024并发稍微高一点就会出现“Too many open files”错误非常误事。我一般会在启动脚本里先查看一下或者直接在systemd服务配置里通过LimitNOFILE指定一个比较大的值比如65535。这个操作虽然不起眼但那些“应用运行几天后突然完全不可用”的线上故障有很大一部分就是文件句柄耗尽引起的。3. 构建与配置让一个jar包能装进任何环境3.1 Maven多环境Profile与打包命令部署的前提是能拿到一个合适环境的构建产物。实际项目里通常有开发、测试、生产等多个环境这些环境的数据库地址、Redis连接、接口地址都不一样。如果每次发版前手动改配置再打包太容易出错甚至出现过把测试环境的配置发到生产的事故。我的做法是在Maven里配置多Profile每个环境一套properties。比如profiles profile iddev/id propertiesenvdev/env/properties /profile profile idprod/id propertiesenvprod/env/properties /profile /profiles然后配合Spring Boot的application-{profile}.yml机制把环境差异放在各自的配置文件中公共配置留在application.yml。打包时用上-P参数mvn clean package -DskipTests -Pprod这里有两个细节容易踩坑。第一spring-boot-maven-plugin的repackage目标会把项目打成可执行jar插件版本要和SpringBoot版本匹配否则打出来的包可能只是个普通jar跑起来就是“no main manifest attribute”。第二打包机上的环境变量会影响Maven的行为编译前看一眼是否干净别让本机配置串进生产包。3.2 敏感信息不要写进配置文件数据库密码、密钥这类东西直接写在application-prod.yml里然后整个仓库打进去等于把钥匙放在门上。我项目里的做法是配置文件中只留占位符真正的值通过环境变量注入。SpringBoot的配置优先级是环境变量 外部配置文件 jar内的配置文件。也就是说运行环境里的环境变量天然能覆盖jar包内的默认值。实际操作时我在启动脚本或systemd配置里通过Environment或EnvironmentFile注入关键变量比如DB_PASSWORDxxx REDIS_PASSWORDxxx这样即使包被泄露敏感信息也还在可控范围内。如果情况更复杂还可以引入加密配置的框架但我建议先把环境变量这套用好它已经能解决绝大多数问题。3.3 配置文件的外部化技巧还有一类配置变化频繁不适合每次重新打包比如某些业务开关、路由规则。这类配置我建议放到jar包外部的/opt/app/conf/目录然后通过启动参数指定--spring.config.additional-location/opt/app/conf/这样修改外部配置后只需重启服务而不用重新构建整个应用。对运维来说这可太省事了。需要注意的是这个additional-location的优先级比jar内配置高比环境变量低用的时候心里有数就行。4. systemd托管让SpringBoot像系统服务一样被管理4.1 服务单元文件示例当你能用一行java -jar把应用跑起来下一步就是让它更“听话”。Linux自带的systemd就能把SpringBoot应用变成一个标准的系统服务享有开机自启、崩溃重启、日志统一管理等能力。下面是一个我打磨过的service文件[Unit] DescriptionSpringBoot App Afternetwork.target [Service] Userappuser Groupappuser WorkingDirectory/opt/app/current EnvironmentFile/opt/app/conf/app.env ExecStart/usr/bin/java -server -Xms1024m -Xmx1024m \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/app/logs/ \ -Duser.timezone东八区 \ -Dfile.encodingUTF-8 \ -jar /opt/app/current/app.jar \ --spring.profiles.activeprod ExecStop/bin/kill -TERM $MAINPID Restartalways RestartSec10 LimitNOFILE65535 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target这里有几个关键点ExecStop用kill -TERM而不是kill -KILL这关系到优雅停机。SpringBoot收到SIGTERM信号后会主动执行关闭流程等处理完当前请求再退出。如果直接KILL就可能中断用户请求造成数据不一致。Restartalways是给进程买的一份“意外险”进程因OOM或者异常退出时systemd会自动拉起它。EnvironmentFile用来注入敏感环境变量放在conf目录下的app.env里权限设为600避免其他用户读取。配置文件写好之后执行两步sudo systemctl daemon-reload sudo systemctl enable myapp.serviceenable是注册开机自启。这一步很多人会漏手动跑完发现一切正常结果服务器重启后服务还是没起来。4.2 日志怎么收集和切割日志是部署后唯一的“黑匣子”出了问题只能靠它。我刚接触systemd时习惯用journalctl -u myapp看日志确实方便。但journal的大小如果不控制时间久了会吃掉大量磁盘空间。更推荐的做法是应用日志交给logback自己管理通过logback-spring.xml配置滚动策略。比如按天滚动每份日志文件上限100MB最多保留30天这样磁盘空间可控而且日志文件是明文用tailing或者grep都顺手。systemd的journal则当作第二层兜底捕获应用启动早期还没初始化好logback时的一些输出。有一点要强调如果你用System.out.println打日志这些输出默认走的是标准输出会被systemd捞走但也会增加journal的存储量。开发阶段无所谓生产环境尽量统一走logback代码里别乱用System.out后面日子会好过很多。4.3 日常运维命令与健康检查托管到systemd之后日常操作就是几个命令的事systemctl start myapp systemctl status myapp systemctl restart myapp journalctl -u myapp -f配合健康检查使用更稳妥。SpringBoot如果引入了Actuator天然有/actuator/health端点。部署完成后用curl验证curl -f http://127.0.0.1:8080/actuator/healthcurl返回的退出码可以用在发布脚本里做自动化判断。记得生产环境要把这个健康检查端口只暴露给内网或本机别直接扔到公网上裸奔。5. 发布与回滚部署里真正见功力的一步5.1 发布目录结构与软链方案部署前规划好的目录现在派上用场了。我把新旧版本都放在/opt/app/releases/下命名带上时间戳然后在/opt/app/current做一个软链指向当前版本。比如/opt/app/releases/app-20250110-1430.jar /opt/app/releases/app-20250110-1600.jar /opt/app/current - /opt/app/releases/app-20250110-1600.jar发布新版本时把新包传到releases目录更新软链指向新包重启服务。整个过程不删除旧包万一新版有问题只要把软链改回去再重启就完成回滚。5.2 发布脚本的关键步骤我用的发布脚本思路大致是这样的上传新jar包到releases目录。通过/actuator/health确认当前服务正常避免带着半死不活的状态做发布。向进程发送SIGTERM信号等待优雅退出。SpringBoot的server.shutdowngraceful和spring.lifecycle.timeout-per-shutdown-phase这两个配置可以把停机的宽限期兜住给正在处理的请求一个体面的收尾时间。更新软链指向新包。启动服务。循环调用健康检查等返回200再继续。检查应用日志末尾是否有异常堆栈。这是一个简化的流程但核心思想是对的先确认旧的不坏再切新的最后验证新的可用。曾经我偷懒跳过第2步结果旧服务早就OOM挂了我却还在上面盲目操作最后排查了半天才发现问题根源。5.3 回滚与灰度把变化控制在最小范围回滚本质上就是把软链指回上一个版本然后重启。但这里有个隐蔽的坑如果新版启动时改了数据库表结构或者升级了配置回滚到旧版可能因为不兼容而继续报错。所以发布前对数据库变更要做兼容性评估这是经验不是脚本能解决的。灰度发布在大多数中小团队可以做得轻量一点先在一台实例上发布新版本观察日志和指标确认稳定后再逐步扩展到其他实例。这比一次全量替换要稳妥得多。我经历过一次不加灰度直接全量换结果新版本有一个隐蔽的连接泄漏问题半个小时后所有实例同时告警那叫一个手忙脚乱。6. 部署后的可观测性健康检查、监控与排障6.1 健康检查不只是“通不通”Actuator的health端点返回的只是UP/DOWN但生产环境的可用性比这复杂。我更习惯在部署后立刻验证几个核心依赖的状态数据库能不能连、Redis能不能通、消息队列是否正常。SpringBoot允许自定义health指示器把数据库、Redis、MQ都纳入检查范围。在此基础上很多监控系统都支持HTTP探针周期性请求health端点出现非200就告警。这套组合拳能有效缩短故障发现时间而不是等用户打电话来才知道系统挂了。6.2 日志排障的几个实用技巧日志文件落盘之后批量grep就成了最趁手的排查工具。比如看到某个任务今天没跑成功直接grep ERROR /opt/app/logs/app.log | grep 2025-01-10 14 | head -50我还会在应用里对关键业务打上唯一日志标记比如订单号、任务ID这样链路排查时从一个入口ID能带出整条处理日志。日志里包含这些上下文标记比一堆冗长堆栈有价值得多。6.3 基础监控指标CPU、内存、GC一个都不能少部署完成后还需要关注机器层面的指标否则进程活着不代表真的健康。我在实际运维中最常查看的是这么几项CPU使用率和平均负载观察是否存在计算热点内存使用量确认堆外内存有没有被滥用GC频率和停顿时间长时间Full GC会导致接口大面积超时磁盘空间日志写满磁盘是运维事故里最常见的一类。有个简单方法可以观察GC情况从日志文件里统计或者用JDK自带工具连接进程查看。实践下来GC数据能帮你提早预判系统容量瓶颈——在还没出大事之前就把问题处理掉比事后救火舒服太多。7. 几次真实部署踩坑后的经验沉淀7.1 JVM参数拍脑袋分配差点拖垮服务器有一回给某个服务配置JVM参数觉得机器内存大就给一次性分配了4个G堆。结果那台机器上还有其他服务在跑内存一上来就被榨干swap开始疯狂读写整个机器卡到连SSH都半天才响应。后来我总结出一个习惯给应用分配内存时先估算基础水位再留出至少20%的系统余量如果机器上跑多个应用总分配量要低于物理内存绝不做“每个应用都觉得自己独占整台机器”的美梦。7.2 发布脚本漏掉stop导致两个实例抢端口有一次写自动化发布脚本时先执行了start却把stop步骤放在了start后面。实际上因为脚本是分步执行的旧进程还在监听端口新进程启动时端口被占用直接start失败但旧进程也被回收了等于那一段服务彻底不可用。排查了很久才发现是脚本执行顺序混乱造成的。从那次之后我严格要求先发SIGTERM停旧进程、确认端口释放、再启动新进程每一步前后都要有检查动作绝不能让脚本“碰运气”。7.3 回滚后配置还是旧的还有一次发布新版后发现问题回滚到旧版却依旧报错。查了半天发现新版启动时修改了外部配置文件旧版读取的配置已经被带偏了。从那以后我意识到配置文件要放进版本控制里跟着走发布时通过软链的方式切换整个配置目录而不是“每个版本临时改一把”。配置和程序包做到同步版本化才能保证回滚是真正干净的。现在回看SpringBoot项目部署这件事表面上是几个命令的排列组合实际上是对运行环境、配置管理、进程生命周期、发布策略这些基本功的综合考验。它不像写业务代码那样能快速看到成果却决定了应用真正交到用户手里之后的每一秒体验。上面写到的这些方法和教训都是我一步步从踩坑里捡回来的。如果你正准备上线某个SpringBoot项目我建议先别急着敲启动命令花一天时间把环境、目录、systemd配置、发布脚本这几件事情理清楚后面会省下无数个焦头烂额的深夜。
优化)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
