部署时间 = 制品构建时间 + 镜像打包时间 + 传输时间 + 环境准备 + 应用启动就绪时间。优化思路从CI 构建、制品分发、容器 / 运行时、应用本身、部署策略、基础设施六个维度落地，核心目标：减少重复工作、缩小包体积、并行化、预加载、拆分就绪检查。
适用场景：K8s/Docker、微服务、Java/SpringBoot、Node/Python 等，兼顾流水线 CI（Jenkins/GitLab CI/GitHub Actions）。
一、CI 构建阶段优化（最容易见效）
1. 缓存依赖，避免每次重新下载
大部分耗时来自依赖拉取（Maven/Gradle/npm/pip）
Maven/Gradle：缓存
~/.m2/repository、~/.gradle/cachesNode：缓存
node_modules注意：缓存 key 按 lock 文件（pom.xml/lockfile）做 hash，依赖不变就复用缓存。
Gradle 额外开启：
--daemon --parallel，并行编译子模块。
2. 源码编译：增量编译 + 并行编译
增量编译：只编译改动模块，不做全量构建（多模块微服务重点）
并行编译：多核并行，
-T参数（Maven）静态代码检查、单元测试：拆分到独立 job，不要阻塞制品打包；测试失败终止，测试通过再打包镜像。
3. 精简编译产物，剔除无用文件
Java：打包时排除源码、测试类、文档、本地开发配置；使用
spring-boot-layertools分层打包Node：
npm ci代替 npm install，生产打包--production，删除 devDependencies通用：
.dockerignore，不要把.git、日志、本地配置、IDE 文件打进镜像
二、容器镜像优化（镜像大小直接影响拉取耗时）
1. 多阶段构建（Multi-stage build）
构建环境和运行环境分离：编译在 build 镜像，仅把最终产物拷贝到轻量运行镜像，不携带编译器、maven、git 等工具。
示例：Java 用
maven:3.9-openjdk17构建，产物复制到openjdk:jre-slim或distroless。
2. 分层镜像 + 镜像缓存
Docker 镜像按层存储，不变的层放前面：
安装依赖（很少变动）
拷贝依赖包
拷贝业务代码（经常变动） 镜像拉取时，只有变动层才下载。 SpringBoot 推荐分层 jar：把依赖 jar、配置、业务代码拆成不同层，业务代码变更只更新最小层。
3. 选用更小基础镜像
alpine /slim/distroless 替代完整 ubuntu/centos
不要用 JDK 镜像运行，只用 JRE；GraalVM 原生镜像可以进一步缩减体积、大幅缩短启动时间
4. 镜像预推送、镜像仓库就近部署
内网镜像仓库（Harbor），避免公网拉取；K8s 节点和仓库同机房
镜像预热：提前把镜像拉取到目标节点（大规模集群滚动发布时）
镜像压缩：开启镜像仓库压缩，使用 OCI 标准格式
三、基础设施与制品传输优化
并行部署：多个微服务互不依赖时，流水线并行发布，不要串行。
制品就近：CI 构建产物直接上传内网仓库，跨地域部署用镜像仓库代理 / 镜像同步。
资源配额：CI runner、K8s 节点给足够 CPU / 内存，不要资源压满导致构建 / 拉取变慢。
网络优化：内网私有仓库，关闭不必要 TLS 校验（内网可信环境）；配置镜像加速器。
四、应用启动 & 就绪探针优化（很多人忽略）
部署完成不等于可用，就绪时间也是部署耗时
1. 减少应用启动耗时
SpringBoot：关闭自动扫描、剔除不需要的 AutoConfiguration；懒加载 Bean；减少数据库连接池初始化预热
静态资源外置，不要打包进应用
GraalVM 原生镜像：AOT 编译，去掉 JVM 启动开销（代价：构建时间变长，适合生产部署加速）
2. 就绪探针（readinessProbe）合理配置
不要用存活探针 liveness 判断就绪；readiness 只检查业务端口 / 健康接口
调整
initialDelaySeconds、periodSeconds，不要过长轮询等待；避免反复重试拉长部署时间健康检查接口轻量化，不要在健康接口查询数据库
3. 拆分重初始化逻辑
数据库全量预热、大量缓存加载：放到后台异步执行，不要阻塞应用就绪。
五、部署策略优化（K8s）
滚动更新参数调优
strategy:
rollingUpdate:
maxSurge: 25% # 同时新增Pod数量
maxUnavailable: 0 # 不杀死旧Pod直到新Pod就绪
maxSurge 调高，可以并行启动更多 Pod，缩短整体发布时间。
避免每次部署重新创建 PVC、Service、ConfigMap 不变资源单独维护，不要放在 Deployment 模板每次 apply。
预加载 / 预热
热点缓存提前预热
JVM：JIT 预热（适合长时间运行服务；如果频繁发布可考虑 C2 分层编译）
部署原子化：使用 ArgoCD / FluxCD 做 GitOps，复用已存在资源，避免 helm 重复渲染大模板。
六、高级优化方案
蓝绿部署：提前部署完整新版本，切换 Service 即可，发布耗时几乎只等于流量切换；缺点是双倍资源。
金丝雀 / 灰度：不优化整体部署时间，用于降低风险。
制品版本化 + 增量发布：不完整包发布，只更新变更文件（适合静态资源；容器场景一般不推荐，镜像优先）
构建与部署分离：CI 只负责构建制品；部署阶段只做分发 + 启动，不重新编译。
并行测试：单元测试、集成测试、代码扫描并行执行。
七、排查定位方法（找到瓶颈）
打开流水线每个阶段耗时统计：构建→镜像打包→推送→部署→就绪，绘制耗时链路。
镜像分析：
docker history查看每层大小，找出大文件。K8s 看 Pod 事件：
kubectl describe pod，看拉取镜像耗时（Pulling / Pulled）、启动耗时。应用侧：打印应用启动日志，统计从 main 到健康接口就绪耗时。
八、常见瓶颈速查表
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢