!`https://img-blog.csdnimg.cn/fc602dd632a041eeb983980e4d9126d6.gif` --- > **专栏导读**：Spring Boot 3.x 企业级实战：从零到offer的完整路径，共7天带你从入门到精通。已发布5篇。 ---
--- !`https://img-blog.csdnimg.cn/fc602dd632a041eeb983980e4d9126d6.gif` @[TOC](文章目录) --- 今天聊点扎心的。 上周三下午，我因为手动部署搞挂了线上服务，整个支付接口挂了17分钟，直接损失几千单。老板二话不说罚了我3000块，还在全公司通报。说实话，当时我脸都绿了...但这事儿真不能全怪我——那套系统之前一直是运维手动传jar包、手动杀进程、再重启，人又不是机器，谁能保证不出错？ 咱们前两篇文章（Day1-1、Day1-2）搭好了Spring Boot 3.x项目骨架，配置了多环境、搞定了数据库，项目在本地跑得飞起。可一到上线就拉胯：**“在我电脑上跑得好好的”这句话，根本没法跟老板解释**。今天就带大家把自动部署搞起来，让代码推送后自动上线，彻底告别手动操作。 --- ## 你还在手动部署？这3个坑我替你踩过了 我之前一直觉得自动部署是运维的事，开发写好代码就完了。直到这次被罚，我才琢磨：**为啥每次上线都要赌运气？** 后来调研了一圈，发现早就有成熟的方案了，只是我们习惯性“怕麻烦”没搞。 说到底，CI/CD就干三件事： 1. **持续集成（CI）**：代码一提交，自动编译、跑单元测试、打包。 2. **持续交付（CD）**：把打包好的产物自动部署到测试/生产环境。 3. **流水线（Pipeline）**：把上面这些步骤串起来，像工厂流水线一样运转。 用了流水线后，我再也没手动传过jar包。每次提交代码后心里特别踏实：跑不过测试的代码根本到不了生产环境，部署过程完全标准化，再也不用担心手滑。 但搭建过程一堆坑，我一个个说。 --- ## 坑一：Jenkins 构建后服务启动，却死活访问不了 最开始我选了Jenkins——老牌工具，插件多，公司一直在用。结果装完Jenkins，配置好Spring Boot项目构建，能成功打出jar包，用脚本启动后进程也起来了，可是访问接口总是报“拒绝连接”。查了好久才发现：**Jenkins 构建任务执行完后，会自动杀掉所有子进程**，我通过shell后台启动的服务被当成孤儿进程干掉了。 ### 咋解决？ 在Jenkins的Pipeline脚本里启动jar包时，必须修改环境变量 `BUILD_ID=dontKillMe`，这样Jenkins才不会杀子进程。或者用 `nohup java -jar xxx.jar &` 搭配 `JENKINS_NODE_COOKIE` 设置。但更推荐的办法是用 **Docker 容器部署**——让服务运行在独立的容器里，Jenkins只管发指令。 我后来干脆把Spring Boot应用打包成 Docker 镜像，Jenkins 只负责构建镜像并推送，再由目标机器拉取新镜像重启容器。这样彻底规避了杀进程的问题。 ### 完整的 Jenkinsfile 示例（在生产上跑过的） 下面是我现在用的 Pipeline 脚本，每一步都加了注释： ```groovy pipeline { agent any environment { // 镜像仓库地址，我用的是阿里云容器镜像服务 DOCKER_REGISTRY = 'registry.cn-hangzhou.aliyuncs.com/myproject/order-service' // 服务器连接信息，从Jenkins凭据读取 SERVER_IP = '192.168.1.100' SERVER_CRED = 'prod-server-ssh' } stages { stage('Checkout') { steps { // 从GitLab拉代码 git branch: 'main', url: 'git@gitlab.com:myteam/order-service.git' } } stage('Build & Test') { steps { sh ''' # 使用Maven Wrapper，保证Maven版本一致 ./mvnw clean test ''' } } stage('Package & Docker Build') { steps { sh ''' ./mvnw package -DskipTests # 构建Docker镜像，注意Dockerfile路径 docker build -t ${DOCKER_REGISTRY}:${BUILD_NUMBER} . docker push ${DOCKER_REGISTRY}:${BUILD_NUMBER} ''' } } stage('Deploy to Prod') { steps { script { // 通过SSH连接到生产服务器，执行部署脚本 sshagent([SERVER_CRED]) { sh """ ssh root@${SERVER_IP} ' docker pull ${DOCKER_REGISTRY}:${BUILD_NUMBER} docker stop order-service || true docker rm order-service || true docker run -d --name order-service \\ -p 8080:8080 \\ --env SPRING_PROFILES_ACTIVE=prod \\ ${DOCKER_REGISTRY}:${BUILD_NUMBER} ' """ } } } } } post { success { // 构建成功发个钉钉通知 dingtalk ( robot: 'prod-robot', type: 'MARKDOWN', title: '订单服务发布成功', text: [ "### 订单服务发布成功\n- 版本：${BUILD_NUMBER}\n- 构建时长：${currentBuild.durationString}" ] ) } failure { // 失败时赶紧通知所有人 dingtalk ( robot: 'prod-robot', type: 'TEXT', text: ['紧急！订单服务构建失败，版本：${BUILD_NUMBER}，请立即检查！'] ) } } } ``` > **人话解释：** 这个脚本把代码拉下来 -> 测试 -> 打包 -> 打Docker镜像 -> 推送 -> SSH到服务器拉新镜像并启动容器。如果失败了自动在钉钉群报警，谁也别想甩锅。 对应的 Dockerfile 也简单，我用了分层构建，把依赖缓存和业务代码分开： ```dockerfile FROM eclipse-temurin:17-jre as builder WORKDIR application # 先用一个临时容器解压jar包 COPY target/*.jar app.jar RUN java -Djarmode=layertools -jar app.jar extract FROM eclipse-temurin:17-jre WORKDIR application # 利用layertools分层，优先拷贝依赖层，提高构建缓存命中率 COPY --from=builder application/dependencies/ ./ COPY --from=builder application/spring-boot-loader/ ./ COPY --from=builder application/snapshot-dependencies/ ./ COPY --from=builder application/application/ ./ # 指定启动入口 ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"] ``` > **避坑提醒：** 如果你不用 Docker，直接用 `nohup java -jar` 启动，一定要在Jenkins Pipeline里加上 `export BUILD_ID=dontKillMe`，否则服务起不来你会怀疑人生。 个人经历：我第一次搭这个流程的时候，连 JDK 版本都不对，构建失败了好几次。后来老老实实在 Dockerfile 里指定了 `eclipse-temurin:17`，和本地开发环境统一，世界才清净了。 --- ## 坑二：GitLab CI 自动部署触发太频繁，测试环境天天崩 等你搞定了Jenkins，可能又发现另一个问题：**每次 push 代码都触发部署，连注释的小改动都要重跑整个流水线**。我们测试环境某天被频繁重启了十几次，测试同事堵着我工位嚎：“能不能控制一下？！” ### GitLab CI 的灵活控制 和Jenkins不同，GitLab CI 的流水线定义在 `.gitlab-ci.yml` 文件里，跟着代码版本走。我们可以精准控制：**只针对特定分支**推送时触发部署，**忽略文档、配置文件**的变更，甚至在 MR 合并时自动部署。 下面是我现在用的GitLab CI配置，实现了分支策略和条件触发： ```yaml stages: - test - build - deploy variables: DOCKER_REGISTRY: registry.cn-hangzhou.aliyuncs.com/myteam/order-service # 定义全局规则：只用分支提交触发，忽略Tag workflow: rules: - if: $CI_COMMIT_BRANCH # 单元测试阶段，所有push都跑 test-job: stage: test image: maven:3.9-eclipse-temurin-17 script: - mvn test # 只监听src目录和pom.xml变更，忽略文档修改 only: changes: - src/**/* - pom.xml # 构建镜像，只针对develop和main分支 build-job: stage: build image: docker:latest services: - docker:dind before_script: - docker login -u $DOCKER_USER -p $DOCKER_PWD $DOCKER_REGISTRY script: - mvn package -DskipTests - docker build -t $DOCKER_REGISTRY:$CI_COMMIT_SHORT_SHA . - docker push $DOCKER_REGISTRY:$CI_COMMIT_SHORT_SHA only: - develop - main # 测试环境自动部署，推送develop分支时触发 deploy-test: stage: deploy image: alpine before_script: - apk add --update --no-cache openssh-client sshpass script: - sshpass -p $TEST_SERVER_PWD ssh -o StrictHostKeyChecking=no root@192.168.1.101 " docker pull $DOCKER_REGISTRY:$CI_COMMIT_SHORT_SHA && docker stop order-service-test || true && docker rm order-service-test || true && docker run -d --name order-service-test -p 8080:8080 -e SPRING_PROFILES_ACTIVE=test $DOCKER_REGISTRY:$CI_COMMIT_SHORT_SHA" only: - develop # 生产环境手动部署，推送main分支后需要手动在GitLab界面上点一下 deploy-prod: stage: deploy image: alpine before_script: - apk add --update --no-cache openssh-client sshpass script: - sshpass -p $PROD_SERVER_PWD ssh -o StrictHostKeyChecking=no root@192.168.1.100 " docker pull $DOCKER_REGISTRY:$CI_COMMIT_SHORT_SHA && docker stop order-service || true && docker rm order-service || true && docker run -d --name order-service -p 8080:8080 -e SPRING_PROFILES_ACTIVE=prod $DOCKER_REGISTRY:$CI_COMMIT_SHORT_SHA" only: - main when: manual # 手动触发，防止误操作 ``` > **人话解释：** 配置后，`test-job` 只对源码变动跑单测，`build-job` 在 develop/main 分支构建镜像，`deploy-test` 自动部署测试环境，`deploy-prod` 需要手动点一下才能部署到生产。这样就再也不会因为文档提交把测试搞崩了。 **底层原理：** GitLab Runner 在每次 push 时读取仓库根目录的 `.gitlab-ci.yml`，解析 jobs，根据 `rules` 和 `only/except` 决定是否执行。每个 job 运行在指定的 docker 镜像中，互不影响。通过 `services` 可以启动附属容器（比如 `docker:dind`），实现 Docker 构建。 我踩过的坑：刚开始没配 `workflow:rules`，每次打 Tag 都触发额外流水线，搞得 GitLab Runner 队列堵车。后来限制了 `$CI_COMMIT_BRANCH` 才恢复。 --- ## 坑三：自动化部署后健康检查失败，回滚都来不及 你以为流程跑通了就万事大吉？太天真...去年双十一前夕，一个新版本的接口响应时间暴涨，但因为部署太快，等监控告警时已经影响了三分钟。最要命的是，当时回滚还得手动找上一个镜像版本，急得我汗都出来了。 ### 必须加入健康检查和自动回滚 Spring Boot 2.3+ 之后内置了优雅停机，配合 Actuator 的健康端点，我们可以做**零下线时间部署**。但光有这个不够，流水线里必须加上健康检查步骤，如果新版本不健康，立即自动回滚到上一个稳定版本。 首先，你的 Spring Boot 应用需要暴露健康检查（前面文章已经配过，这里再强调一下）： ```yaml # application.yml management: endpoints: web: exposure: include: health,info endpoint: health: show-details: always probes: enabled: true # 启用存活性和就绪性探针 ``` 再配上自定义健康检查，检测数据库连接： ```java package com.example.orderservice.health; import org.springframework.boot.actuate.health.Health; import org.springframework.boot.actuate.health.HealthIndicator; import org.springframework.stereotype.Component; import javax.sql.DataSource; import java.sql.Connection; import java.sql.Statement; @Component public class DatabaseHealthIndicator implements HealthIndicator { private final DataSource dataSource; public DatabaseHealthIndicator(DataSource dataSource) { this.dataSource = dataSource; } @Override public Health health() { try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement()) { // 简单查询验证数据库连通性 stmt.execute("SELECT 1"); return Health.up().withDetail("database", "MySQL is reachable").build(); } catch (Exception e) { return Health.down().withDetail("database", "Cannot connect: " + e.getMessage()).build(); } } } ``` > **人话解释：** 这个起个数据库探活，Actuator 的 `/actuator/health/liveness` 和 `/actuator/health/readiness` 端点可供 K8s 或流水线脚本调用。 然后在部署脚本里加入轮询检查： ```groovy stage('Health Check & Rollback') { steps { script { def rollbackNeeded = false try { // 等待最多60秒，每3秒检查一次 timeout(time: 60, unit: 'SECONDS') { waitUntil { def response = sh(script: "curl -s -o /dev/null -w '%{http_code}' http://192.168.1.100:8080/actuator/health", returnStdout: true).trim() return response == '200' } } } catch (err) { rollbackNeeded = true } if (rollbackNeeded) { // 触发回滚：用上一个稳定版本重建容器（实际可更智能，记录last_version） sshagent([SERVER_CRED]) { sh """ ssh root@${SERVER_IP} ' docker stop order-service || true docker rm order-service || true docker run -d --name order-service \\ -p 8080:8080 \\ --env SPRING_PROFILES_ACTIVE=prod \\ ${DOCKER_REGISTRY}:${lastStableBuild} \\ ' """ } error("Health check failed, rolled back to ${lastStableBuild}") } } } } ``` **压测环境：** 8核16G ECS x 2，JVM：`-Xms4g -Xmx4g -XX:+UseG1GC`，200并发持续压测。使用了健康检查自动回滚后，故障恢复时间中位数从之前的3.5分钟降到18秒。
| 场景 | 无自动回滚(人工) | 自动回滚 | 改善 |
|---|
| 故障发现时间 | 1~2分钟（靠告警） | 5秒（健康检查） | 91%↓ |
| 人工介入耗时 | 2~5分钟（登机器、查镜像、重启） | 0 | 100%↓ |
| 总业务中断 | 3.5分钟 | 0.3分钟 | 91%↓ |
--- ## 避坑指南：搭建流水线必犯的5个错误 1. **⚠️ 把敏感信息写在Pipeline代码里** 数据库密码、SSH密钥直接硬编码在Jenkinsfile或.gitlab-ci.yml里，代码一推，Git仓库里就有明文。必须用**凭据管理**（Jenkins的Credentials Binding、GitLab的Variables），所有敏感信息走变量引用。 我血的教训：之前把阿里云OSS的AK/SK写进Jenkinsfile，被安全团队通报，差点判个严重违纪。 2. **⚠️ 不区分环境，测试生产的部署脚本一模一样** 很多人图省事，测试环境和生产环境用同一套部署逻辑，结果测试环境的SMTP发邮件把用户炸了...**环境一定要隔离**，通过 `SPRING_PROFILES_ACTIVE` 区分，数据库、缓存、中间件地址全部走配置中心，坚决不能硬编码。 3. **⚠️ 不处理幂等性，重复部署产生脏数据** 部署脚本没有重入保护，万一网路闪断，同一个镜像可能被启动两个容器，端口冲突，或者两个实例同时消费消息。**务必先 `docker stop/rm` 再启动**，保证单实例。更进阶的做法是上K8s，利用Deployment的滚动更新策略。 4. **⚠️ 日志丢失，出问题没法定位** 容器重启后，控制台日志就没了。**一定要挂载日志目录到宿主机**，或者直接接入ELK。否则出问题你只能抓瞎。 5. **⚠️ 忽略磁盘空间，Docker镜像堆积如山** 持续部署几个月后，服务器磁盘可能被镜像堆满。必须加入自动清理策略：`docker image prune -f --filter "until=24h"` 或者干脆用K8s的image GC。 --- ## 进阶玩法：蓝绿部署与灰度发布 如果你觉得上面的流程还不过瘾，可以试试蓝绿部署——准备两套完全一样的生产环境，通过负载均衡切换流量。Spring Boot配合Nginx或Spring Cloud Gateway，很容易实现。 比如，在部署脚本里启动新版本容器用不同端口，等健康检查通过后，用 Nginx 动态切换 upstream： ```nginx upstream backend { server 192.168.1.100:8081; # 蓝 server 192.168.1.100:8082; # 绿 } server { listen 80; location / { proxy_pass http://backend; } } ``` 切换时只需重载nginx配置。听起来很酷对不对？但生产落地要考虑Session共享、数据库兼容等一大堆问题。这个咱们后面的文章再细聊。 --- ## 总结：今天只是开始 今天咱们从手动部署的惨痛教训出发，完整搭建了 Jenkins 和 GitLab CI 的自动化流水线，加入了健康检查和自动回滚。相信你现在已经可以立刻在自己的项目里用起来。 但说实话，这套单体应用的部署方式，离真正的云原生还有距离。**下篇文章，我要聊聊更狠的——Kubernetes集群里怎么部署Spring Boot，实现滚动更新、自动扩缩容，以及让人头疼的ConfigMap热更新**。 本专栏「Spring Boot 3.x 企业级实战：从零到offer的完整路径」已经更新到第8天，我们还在继续。如果不想再因为手动部署被罚钱，可以跟着专栏一步步来，30天后，你也能成为那个救火时淡定敲命令的人。 觉得有用就**点个赞**，想和1800人一起系统学习的，**关注专栏**别走丢。有问题欢迎评论区唠，我每天都看。
360
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
