企业官网建设流程全解析

1. 从本地 java -jar 到容器化：为什么这一步非走不可

很多做 Java 后端的朋友，第一次把服务往服务器上放的时候，用的都是最朴素的办法：本地mvn package打个包，scp传到服务器，然后nohup java -jar xxx.jar &一挂，日志往一个文件里一写，就算上线了。这套流程在小规模、单机、自己维护的场景下确实能跑，我自己早期也是这么干的。但只要你经历过一次“服务器上 JDK 版本和本地不一致导致启动报错”“换台机器要重新装环境”“服务挂了没人拉起来”这类事情，就会开始琢磨：能不能把运行环境也一起打包带走？

这就是 jar 包容器化部署要解决的核心问题。它做的事情说白了就一句话：把 JAR 包和它依赖的 JDK 运行环境，一起封装进一个标准化的镜像里，让这个服务在任何装了容器运行时的机器上都能以完全相同的方式跑起来。你不需要在目标服务器上装 JDK、配环境变量、纠结 glibc 版本，只要机器能跑容器，镜像一拉、容器一起，服务就起来了。

这篇文章适合几类人看：一是刚接触容器、想把现有 Spring Boot 或普通 Java 项目容器化的后端开发；二是被“本地能跑服务器跑不了”折磨过的运维或全栈；三是想把手动部署流程标准化、但又不想一上来就搞一整套重型编排系统的团队。我会从镜像怎么构建、基础镜像怎么选、启动参数怎么调、日志和配置怎么处理、常见坑怎么排这几个角度，把这件事从头到尾讲透，尽量给到你能直接抄的配置和命令。

需要先明确一个前提：容器化不是银弹。它解决的是“环境一致性”和“交付标准化”，但它不会自动帮你做高可用、自动扩缩容、服务发现。那些是更上层的事情。我们这篇聚焦在“单个 jar 包如何稳稳当当地跑在容器里”这个最基础也最关键的环节，把地基打牢。

2. 镜像构建的两种主流打法：Dockerfile 手写 vs 分层构建

把 jar 包做成镜像，最直接的方式就是写一个 Dockerfile。但同样是写 Dockerfile，写法差别很大，直接影响到镜像体积、构建速度、以及后续迭代的效率。我见过不少人上来就FROM openjdk:8，然后COPY一个几百兆的 fat jar 进去，镜像直接干到六七百兆。能跑是能跑，但每次改一行代码重新构建，都要重新传一遍整个 jar，推拉镜像慢得让人抓狂。

2.1 最朴素但能用的单阶段写法

先看一个最基础的版本，理解它之后再谈优化：

FROM openjdk:8-jre-slim WORKDIR /app COPY target/myapp.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

这个 Dockerfile 的逻辑很直白：基于一个带 JRE 的镜像，把打好的 jar 拷进去，声明端口，设置启动命令。构建命令就是docker build -t myapp:1.0 .，运行就是docker run -d -p 8080:8080 myapp:1.0。

它的问题在哪？第一，基础镜像openjdk:8-jre-slim本身就不算小，大概 200 多兆；第二，你的 fat jar 可能 100 到 300 兆，全叠在一起；第三，也是最要命的，每次你改代码重新打包，jar 的哈希变了，COPY这一层缓存就失效，整个镜像层要重建。对于频繁迭代的项目，这个构建和推送成本很难接受。

提示：openjdk这个官方镜像仓库其实已经停止更新了，新项目建议用eclipse-temurin系列，它是目前社区维护得比较活跃的 OpenJDK 发行版镜像，标签也更规范。

2.2 分层构建：把依赖和业务代码拆开

Spring Boot 从 2.3 版本开始，支持把 fat jar 拆成多层，这是解决上面缓存问题的关键。它的原理是利用 jar 包内部的目录结构，把不常变的依赖（BOOT-INF/lib）和常变的业务代码（BOOT-INF/classes）分成不同的层，这样构建镜像时，依赖层可以被缓存复用，只有业务代码层需要重建。

要启用这个能力，需要在pom.xml的打包插件里加一段配置：

<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <layers> <enabled>true</enabled> </layers> </configuration> </plugin>

打包之后，用java -Djarmode=layertools -jar app.jar list就能看到分出来的层，通常是dependencies、spring-boot-loader、snapshot-dependencies、application这几层。然后在 Dockerfile 里用多阶段构建把它们依次拷进去：

FROM eclipse-temurin:17-jre-jammy AS builder WORKDIR /app COPY target/myapp.jar app.jar RUN java -Djarmode=layertools -jar app.jar extract FROM eclipse-temurin:17-jre-jammy WORKDIR /app COPY --from=builder /app/dependencies/ ./ COPY --from=builder /app/spring-boot-loader/ ./ COPY --from=builder /app/snapshot-dependencies/ ./ COPY --from=builder /app/application/ ./ ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

这么写的好处非常明显：只要你的依赖没变，dependencies这一层就命中缓存，重新构建时只重建application那一层，通常只有几百 KB 到几 MB。推拉镜像的速度提升是数量级的。实测下来，一个原本 300 多兆的镜像，分层之后日常迭代的增量层可能就一两兆，构建时间从几十秒降到几秒。

2.3 基础镜像选型：别只看体积

选基础镜像这件事，很多人只盯着体积，其实还有几个维度要考虑。我把常见的几类列个表对比一下：

Alpine 镜像体积小是优势，但它用的是 musl libc 而不是 glibc。如果你的项目依赖了某些带 native 代码的库（比如某些加密库、图像处理库、Netty 的某些 native 传输），在 Alpine 上可能会报UnsatisfiedLinkError或者莫名其妙的崩溃。我踩过这个坑，一个用了本地压缩库的服务在 Alpine 上跑着跑着就段错误，换成 Ubuntu 基础镜像立刻就好了。所以除非你确认所有依赖都纯 Java，否则生产环境我一般建议用 Ubuntu 或 Debian 基础的镜像，稳字当头。

Distroless 镜像没有 shell、没有包管理器，攻击面小，安全性好，但代价是你没法docker exec进去排查问题，日志只能靠标准输出。如果你的团队排错能力够强、监控体系完善，可以考虑；否则新手用它会很痛苦。

3. 容器里跑 Java 的那些参数讲究

镜像构建好了，不代表服务就能跑得稳。Java 应用在容器里运行，和直接在物理机上跑，有几个关键差异，处理不好会出大问题。这一块是很多人容易忽略的地方，我单独拎出来讲。

3.1 内存限制与 JVM 堆的“鸡同鸭讲”

这是最经典的一个坑。假设你给容器限制了 1GB 内存（docker run -m 1g），但 JVM 默认的堆大小是根据物理机的内存来算的，不是根据容器限制。在 JDK 8 的早期版本里，JVM 根本感知不到容器的内存限制，它会以为整台机器的内存都是可用的，于是把最大堆设成物理内存的四分之一。如果宿主机有 64GB 内存，JVM 可能把堆开到 16GB，然后容器一跑就 OOM 被 kill，日志里还看不到 Java 的异常，只有系统层面的Killed。

从 JDK 10 开始，JVM 默认开启了容器感知（UseContainerSupport），会读取 cgroup 的内存限制来设置堆大小。JDK 8u191 之后的版本也把这个能力 backport 回来了。所以第一件事：确认你的 JDK 版本足够新，或者显式加上容器支持参数。

即便如此，我仍然建议显式指定堆大小，而不是依赖自动计算。因为自动计算只考虑了堆，没考虑元空间、线程栈、直接内存这些堆外开销。一个稳妥的经验公式是：

容器内存限制 = 堆大小 + 元空间 + 线程栈 + 直接内存 + 系统预留

比如容器限制 1GB，我一般会把-Xmx设成 700MB 到 750MB，留出 250MB 左右给堆外。启动参数可以这样写：

ENTRYPOINT ["java", \ "-XX:MaxRAMPercentage=70.0", \ "-XX:InitialRAMPercentage=50.0", \ "-jar", "app.jar"]

用百分比而不是写死数值，好处是当你调整容器内存限制时，堆大小会自动跟着变，不用改 Dockerfile。MaxRAMPercentage=70表示最多用容器内存的 70% 做堆，这个比例是我实测下来比较安全的区间，既不会浪费内存，也给堆外留了足够空间。

3.2 时区问题：日志时间差 8 小时

容器默认时区通常是 UTC，而国内业务大多需要东八区时间。如果不处理，你会发现日志里的时间戳比实际时间早 8 小时，排查问题时对不上，非常误导人。

解决办法有两种。一种是在 Dockerfile 里设置：

ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

另一种是在启动参数里加-Duser.timezone=Asia/Shanghai。我倾向于在 Dockerfile 里设置环境变量，因为这样对容器内所有进程都生效，包括一些可能读取系统时区的第三方组件。注意 Alpine 镜像里没有tzdata，需要先apk add --no-cache tzdata，这也是 Alpine 的一个小坑。

3.3 优雅停机：别让请求被硬生生掐断

容器停止的时候，默认行为是给主进程发SIGTERM信号，等一段时间（默认 10 秒）后如果进程还没退出，就发SIGKILL强杀。如果你的 Java 服务正在处理请求，被强杀会导致请求中断、数据不一致。

Spring Boot 支持优雅停机，配置一下就行：

server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 30s

然后在 Dockerfile 里，ENTRYPOINT要用 exec 格式（就是 JSON 数组那种写法），而不是 shell 格式。因为 shell 格式下，java进程是 shell 的子进程，SIGTERM发给的是 shell 而不是 java，信号传不到，优雅停机就失效了。这是个很隐蔽的坑，很多人写了 graceful 配置却没生效，就是栽在这里。

# 正确：exec 格式，信号能传到 java 进程 ENTRYPOINT ["java", "-jar", "app.jar"] # 错误：shell 格式，信号被 shell 拦截 ENTRYPOINT java -jar app.jar

4. 配置、日志与数据：容器里的“三件套”怎么管

服务跑起来只是第一步，真正让它在生产环境可用，还得处理好配置注入、日志收集、数据持久化这三件事。这三块处理不好，容器化就是给自己找麻烦。

4.1 配置外置：镜像不变，环境可变

容器化的一个核心原则是“一次构建，到处运行”。意思是同一个镜像，在测试环境、预发环境、生产环境都能用，区别只在于外部注入的配置。所以千万不要把数据库密码、环境相关的地址硬编码进 jar 或者镜像里。

Spring Boot 天然支持通过环境变量覆盖配置。比如application.yml里写：

spring: datasource: url: ${DB_URL:jdbc:mysql://localhost:3306/mydb} username: ${DB_USER:root} password: ${DB_PASSWORD:}

然后运行时通过环境变量注入：

docker run -d \ -e DB_URL=jdbc:mysql://db-host:3306/proddb \ -e DB_USER=appuser \ -e DB_PASSWORD=secret \ myapp:1.0

环境变量里的点号要转成下划线，比如spring.datasource.url对应SPRING_DATASOURCE_URL，这是 Spring Boot 的宽松绑定规则。如果配置项特别多，用环境变量一个个写很累，可以挂载一个外部配置文件：

docker run -d \ -v /host/config/application-prod.yml:/app/config/application-prod.yml \ -e SPRING_PROFILES_ACTIVE=prod \ myapp:1.0

Spring Boot 会自动加载config目录下的配置文件，且优先级高于 jar 内部的配置。这样你改配置只需要改宿主机上的文件然后重启容器，不用重新构建镜像。

注意：挂载单个文件时，如果宿主机上的文件被编辑器替换（比如 vim 保存时会创建新文件再改名），容器内看到的可能还是旧文件的 inode，导致配置不生效。稳妥的做法是挂载整个目录，而不是单个文件。

4.2 日志：写标准输出，别写文件

容器的最佳实践是：应用日志写到标准输出（stdout）和标准错误（stderr），由容器运行时统一收集。不要把日志写到容器内的文件里，因为容器一销毁，文件就没了，而且你还得想办法进容器去看。

Spring Boot 默认就是输出到控制台的，所以通常不用改。但如果你之前配置了logging.file.name写到文件，容器化时建议去掉，或者改成输出到控制台。日志的落盘和轮转交给外部的日志系统处理，比如用docker logs查看，或者接入统一的日志采集。

如果确实需要保留文件日志（比如某些审计要求），那就得把日志目录挂载出来：

docker run -d \ -v /host/logs:/app/logs \ myapp:1.0

但即便如此，我也建议同时保留控制台输出，方便快速排查。

4.3 数据持久化：容器无状态，数据有归属

容器本身应该是无状态的，重启、重建都不应该丢数据。所以任何需要持久化的东西——上传的文件、生成的报表、本地缓存——都要挂载到宿主机或者网络存储上。

docker run -d \ -v /host/data/upload:/app/upload \ -v /host/data/cache:/app/cache \ myapp:1.0

这里有个权限坑：容器内进程通常以某个非 root 用户运行（好的实践是不用 root），而宿主机上挂载目录的属主可能是 root，导致容器内写不进去，报Permission denied。解决办法是提前在宿主机上把目录属主改成容器内运行用户的 UID，或者在 Dockerfile 里创建用户时指定一个和宿主机匹配的 UID。这个 UID 映射问题在跨团队协作时特别容易出，建议在部署文档里写清楚。

5. 上线之后：健康检查、资源限制与排错链路

镜像能构建、容器能启动，这只是及格线。真正到了生产环境，还得考虑怎么知道服务活着、怎么防止它拖垮宿主机、出问题了怎么快速定位。这一章讲的是“上线之后”的事，也是区分“能跑”和“跑得稳”的分水岭。

5.1 健康检查：让编排系统知道你还活着

如果你用的是单机docker run，健康检查可能没那么重要。但一旦上了编排系统（比如容器编排平台），健康检查就是生死攸关的东西。编排系统靠它判断容器是否就绪、是否需要重启。

Spring Boot Actuator 提供了现成的健康检查端点，加个依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>

配置里暴露健康端点：

management: endpoints: web: exposure: include: health,info endpoint: health: show-details: always

然后在 Dockerfile 里加健康检查指令：

HEALTHCHECK --interval=30s --timeout=3s --start-period=60s --retries=3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1

start-period很关键，它给应用启动留出缓冲时间。Java 应用启动慢，如果这个值设太小，容器还没启动完就被判定为不健康，会被反复重启，陷入死循环。我一般会根据实际启动时间设成 60 到 120 秒。

不过要注意，curl命令在精简镜像里可能不存在。如果基础镜像没有 curl，可以用wget，或者干脆写一个 Java 的健康检查小程序。Distroless 镜像就更麻烦，得用专门的健康检查工具。这也是选基础镜像时要考虑的一个点。

5.2 资源限制：给容器画个圈

不限制资源的容器是危险的。一个内存泄漏的服务可能吃光宿主机内存，把同机器上的其他服务一起拖死。所以生产环境一定要设资源限制：

docker run -d \ --memory=1g \ --memory-swap=1g \ --cpus=1.5 \ myapp:1.0

--memory-swap设成和--memory一样，表示禁用 swap。因为 Java 应用一旦用上 swap，性能会急剧下降，GC 停顿时间变得不可预测，还不如直接 OOM 让它重启来得干脆。

--cpus=1.5表示最多用 1.5 个 CPU 核心。这个值要和 JVM 的ActiveProcessorCount配合看。JVM 在容器里默认能感知到 CPU 限制，GC 线程数、JIT 编译线程数都会相应调整。如果 CPU 限制设得太小（比如 0.5），JVM 可能只开一个 GC 线程，导致 GC 效率低下。所以 CPU 限制别设得太抠门，至少给 1 个核。

5.3 一个真实的排错链路：容器启动就退出

最后分享一个我实际遇到过的排查过程，这类问题新手很容易懵。现象是：docker run之后容器秒退，docker ps看不到，docker ps -a显示状态是Exited (1)。

第一步，看日志。docker logs <container_id>，如果日志是空的，说明应用还没来得及输出就挂了。这时候看退出码，Exited (1)通常是应用自身报错，Exited (137)是被 OOM kill，Exited (143)是被 SIGTERM 正常终止。

第二步，如果日志为空，用交互模式跑一下，看看到底发生了什么：

docker run -it --entrypoint /bin/sh myapp:1.0

进去之后手动执行java -jar app.jar，错误信息就直接打出来了。我那次是发现application.yml里引用的一个环境变量没传，导致占位符解析失败，应用启动直接抛异常退出。这种问题在docker logs里其实有，只是被淹没在一堆启动日志里没注意看。

第三步，如果是 OOM，docker inspect <container_id>看State.OOMKilled是不是 true。是的话就得回头调堆大小或者加内存限制。

第四步，如果是端口冲突或者连不上数据库，那通常是网络配置问题。容器内的localhost指的是容器自己，不是宿主机。要连宿主机的服务，得用宿主机的 IP 或者host.docker.internal（这个在 Linux 上需要额外配置）。连其他容器则要用容器网络里的服务名。这个“localhost 不是你以为的 localhost”是新手最容易踩的坑之一。

排查这类问题的核心思路就是：先看退出码定位大类，再看日志找具体错误，日志没有就用交互模式手动复现。别一上来就瞎改配置，按链路一步步缩小范围，效率最高。

6. 我踩过的几个印象深刻的坑

前面讲的都是相对系统的东西，最后再零散地补几个我实际踩过、且比较有代表性的坑，算是给准备动手的朋友提个醒。

第一个是文件句柄数限制。容器默认的nofile限制可能比宿主机低，高并发场景下应用报Too many open files。解决办法是在docker run时加--ulimit nofile=65535:65535，或者在编排配置里设置。这个问题在压测时才会暴露，平时低负载根本看不出来，很容易被忽略。

第二个是随机数生成慢导致启动卡顿。早期一些镜像里/dev/random熵不足，JVM 初始化安全随机数时会阻塞，表现为启动特别慢甚至卡住。解决办法是加 JVM 参数-Djava.security.egd=file:/dev/./urandom。新版本的 JDK 和镜像基本已经默认用 urandom 了，但如果你用的是老镜像，这个参数还是值得加上。

第三个是镜像层数过多。有人在 Dockerfile 里一个RUN装一个东西，搞了二三十层，镜像又大又乱。好的做法是把相关的RUN命令用&&串起来，减少层数，同时在同一个RUN里清理掉 apt 缓存，避免缓存文件留在镜像里。

第四个是构建时把不该带的东西带进去了。比如COPY . .把.git目录、本地编译产物、IDE 配置全拷进镜像。一定要写.dockerignore文件，把target之外的东西、.git、*.iml、node_modules这些排除掉。这个文件能显著减小构建上下文，加快构建速度。

这些坑单拎出来都不复杂，但组合在一起，就是“为什么我的容器部署总出幺蛾子”的答案。容器化本身不难，难的是把细节都照顾到。我的建议是，第一次做的时候别追求一步到位，先把服务跑起来，然后对照着这篇文章里的点，一项一项去检查、去优化。跑通一次完整的流程之后，你对这套东西的理解会完全不一样。