第 1 篇：后端为什么需要容器化#

2.1 四个边界：制品、运行、配置、发布#

理解容器化，最好先从四个边界入手。第一个是制品边界，也就是“这次发布的应用到底是什么”。在没有容器化之前，制品可能是一个 jar、一个启动脚本、一个服务器目录、一份系统依赖清单和一段口头说明的组合。容器化以后，制品至少应该收敛到镜像：镜像由 Dockerfile、应用包、基础镜像、构建参数和元数据共同生成，可以被推送到仓库，可以用 tag 或 digest 引用，可以被 CI 记录。

第二个是运行边界，也就是“应用以什么进程模型运行”。容器不是虚拟机，它本质上还是宿主机上的进程，只是通过 namespace、cgroup、联合文件系统等机制获得了隔离视图。这个边界告诉我们，不应该把容器当成一台可以长期登录维护的小机器。容器应该可以被停止、删除、重建和替换，业务状态应该进入数据库、对象存储、消息队列、外部缓存或持久化卷，而不是依赖容器可写层。

第三个是配置边界，也就是“哪些差异属于环境，哪些内容属于制品”。镜像应该尽量不可变，同一份镜像可以在开发、测试、预发和生产中运行，差异通过环境变量、配置文件挂载、ConfigMap、Secret、参数中心或服务发现注入。这样做的关键不是形式，而是让差异可审查、可回滚、可最小化。如果每个环境都构建一份不同镜像，团队会重新陷入“测试通过的不是生产将要运行的东西”这个问题。

第四个是发布边界，也就是“新版本怎样替换旧版本”。发布不是把文件复制到服务器，而是让新制品通过一组规则进入流量路径。这个过程至少涉及镜像拉取、实例创建、配置注入、启动、健康检查、就绪检查、流量切换、旧实例下线和回滚目标保留。Kubernetes 里的 Deployment、ReplicaSet、Pod、Service、Ingress 等对象，就是在不同层次上表达这些边界。即使暂时不用 Kubernetes，只用 Docker 和 Compose，也应该用同样的思维看待发布过程。

2.2 从“机器可用”到“制品可追踪”#

后端工程真正要避免的是“机器可用但系统不可解释”。一台机器上应用能跑，不代表团队知道它为什么能跑。它可能依赖手工安装的字体，依赖某个旧版本 OpenSSL，依赖 /etc/hosts 里一行没人记得的解析，依赖某个目录权限，依赖运维临时改过的启动脚本。机器状态越多，系统就越像黑盒。

容器化把关注点从机器迁移到制品。制品可追踪意味着三个层面。第一，来源可追踪：镜像对应哪个 commit、哪个构建任务、哪个基础镜像、哪个依赖版本。第二，分发可追踪：镜像被推送到哪个仓库、使用哪个 tag、是否有 digest、谁有权限拉取。第三，运行可追踪：哪个环境、哪个实例、哪个时间点运行了这份镜像，启动时注入了哪些配置，健康检查是否通过。

这也是为什么生产环境不应该长期依赖 latest。latest 看起来方便，但它表达的是“某个仓库里当前被叫作 latest 的东西”，不是“这次发布经过验证的确定制品”。更稳妥的方式是使用不可变 tag 或 digest，把版本和构建记录绑定起来。tag 可以用于人类阅读，例如 order-api:2026.07.05-1432-a1b2c3d；digest 用于机器校验，保证拉到的内容没有漂移。很多故障不是因为容器技术复杂，而是因为团队没有把“版本唯一性”这件小事做严。

tag 和 digest 的差异值得提前讲清楚。tag 是名字，digest 是内容指纹。名字可以移动，内容指纹不应该移动。团队可以约定不覆盖 tag，但这仍然是一条流程约束；digest 则是镜像内容的哈希引用，更接近机器层面的确定性。生产发布记录里如果只有 tag，一旦仓库策略、人工操作或自动清理流程导致 tag 指向变化，回放事故时就会产生歧义。如果记录了 digest，就能确认当时到底运行的是哪份镜像内容。对于后端团队来说，这不是运维细节，而是事故复盘和责任边界的基础。

制品可追踪还需要和应用自身打通。镜像 label 里有 commit，但应用日志里没有版本，排障时仍然要跨系统查找；发布单里记录了镜像，但 /actuator/info 不暴露构建信息，测试同学仍然无法快速确认环境是否更新；仓库里保留了镜像，但部署系统没有记录配置版本，回滚仍然不完整。好的容器化实践会让同一组信息在多个位置互相印证：CI 构建记录、镜像元数据、部署声明、应用启动日志、健康接口、日志标签和监控标签都能指向同一个版本。

2.3 概念理解的最终落点#

这些概念最终不是为了背名词，而是为了让后端交付变得可解释、可回滚、可协作。可解释意味着事故中能说清运行的是哪份镜像、哪份配置和哪组依赖；可回滚意味着上一组稳定制品和配置仍然可用；可协作意味着开发、测试、平台和运维面对同一组对象沟通，而不是各自盯着自己熟悉的机器状态。

3.1 交付状态流：从源码到流量#

容器化链路可以看成一条状态流，而不是一组零散命令。后端服务从代码提交到承接流量，大致会经历：代码提交、CI 编译与测试、构建镜像、扫描与元数据记录、推送仓库、部署系统拉取镜像、注入配置、启动容器、健康检查、就绪检查、接入流量、观测反馈、必要时回滚。每一步都应该有输入、输出、成功条件和失败证据。

1
代码提交
2
  -> CI 编译与测试
3
  -> 构建镜像
4
  -> 记录 tag / digest / commit / build id
5
  -> 推送镜像仓库
6
  -> 部署环境拉取镜像
7
  -> 注入环境配置
8
  -> 启动容器进程
9
  -> 通过健康检查与就绪检查
10
  -> 接入流量
11
  -> 观测运行表现
12
  -> 保留回滚目标

这条链路里最重要的不是某个命令，而是状态之间的约束。CI 没过，镜像不应该进入可部署仓库；镜像没有明确版本，不应该进入生产发布；配置没有经过环境隔离，不应该混进镜像；健康检查没有通过，不应该接入流量；观测系统没有收到日志和指标，不应该宣布发布完成。容器化把这些约束变得更容易自动化，但不会替团队自动建立约束。

这套机制和传统发布最大的区别在于，传统发布往往只关注“操作是否执行”，容器化发布更关注“状态是否达到”。复制文件成功，不代表应用可用；容器创建成功，不代表服务可接流量；接口返回 200，不代表依赖链路健康；新版本启动成功，也不代表可以删除旧版本。后端服务的可用性由多个状态共同决定，发布系统必须持续观察这些状态，而不是把某一步命令执行完就当作结束。

如果用 Kubernetes 的思想来解释，这就是期望状态和实际状态的差异。我们声明希望运行某个镜像、某些副本、某些配置、某些探针和某些资源限制，控制器不断观察实际状态并尝试修正偏差。即使暂时只使用 Docker 或 Compose，也应该提前建立这种思维：声明想要什么，观察现在是什么，找出差异在哪里，再决定由谁修复。容器化真正改变的是工程反馈方式，从“我执行了命令”变成“系统证明它达到了期望状态”。

3.2 状态流转：从 commit 到流量#

可以用伪代码理解一条后端容器化发布链路。这里的伪代码不是某个工具的源码，而是帮助你形成“控制点”意识：每个阶段都要知道自己消费什么、产出什么、失败时留下什么证据。

1
function releaseBackendService(commitId, environment):
2
    source = checkout(commitId)
3
    testReport = runUnitAndIntegrationTests(source)
4
    if testReport.failed:
5
        stop("代码质量门禁失败", evidence = testReport)
6

7
    image = buildImage(
8
        dockerfile = source["Dockerfile"],
9
        artifact = source["target/backend-api.jar"],
10
        labels = {
11
            "git.commit": commitId,
12
            "build.time": now(),
13
            "service": "backend-api"
14
        }
15
    )
16

17
    scanReport = scanImage(image)
18
    if scanReport.hasCriticalRisk:
19
        stop("镜像安全门禁失败", evidence = scanReport)
20

21
    digest = pushToRegistry(image)
22
    deploymentSpec = renderDeploymentSpec(
23
        imageDigest = digest,
24
        environmentConfig = loadConfig(environment)
25
    )
26

27
    rollout = applyDeployment(deploymentSpec)
28
    waitUntil(rollout.podsCreated)
29
    waitUntil(rollout.startupProbePassed)
30
    waitUntil(rollout.readinessProbePassed)
31

32
    shiftTraffic(rollout.newVersion)
33
    observeWindow = observeMetricsAndLogs(duration = "10m")
34
    if observeWindow.errorRateTooHigh or observeWindow.latencyTooHigh:
35
        rollback(rollout.previousVersion)
36
        stop("发布后观测异常，已回滚", evidence = observeWindow)
37

38
    markReleaseSuccess(commitId, digest, environment)

这段伪代码里有几个关键点。第一，构建镜像不是发布链路的起点，代码质量和依赖验证才是。第二，镜像必须带上可追踪元数据，否则事故中很难把运行实例和源码版本对应起来。第三，推送仓库以后最好记录 digest，而不是只记录 tag。第四，部署声明应该由环境配置渲染，不应该靠人工进入容器修改文件。第五，发布成功不等于容器启动成功，至少要经过就绪检查和短时间观测。

如果把这套状态流转放回后端日常工作，你会发现很多“玄学问题”其实是缺少状态记录。例如同一份代码在测试和生产表现不同，先不要直接怀疑业务逻辑，应该先比较镜像 digest、启动参数、环境变量、配置挂载、依赖服务地址、数据库 schema、JVM 参数和资源限制。如果这些状态没有记录，就只能靠猜。

这里还要注意一个容易忽略的细节：构建期和运行期必须分开。构建期负责把源码、依赖和运行时封装成镜像；运行期负责把镜像和环境配置组合起来启动服务。如果构建期偷偷读取生产配置，镜像就会变成环境绑定制品；如果运行期还在下载业务依赖或生成核心文件，发布就会变得不可预测。一个健康的后端容器化流程，应该尽量让构建期确定、运行期轻量、配置注入清晰、启动过程可观察。

这也是多阶段 Dockerfile、依赖缓存、制品仓库和配置中心存在的工程原因。它们不是为了让技术栈显得高级，而是为了减少状态漂移。构建环境只负责产出制品，运行环境只负责消费制品；制品一旦进入仓库，就不应该被人工修改；环境差异通过配置层表达，而不是重新构建一份差不多的镜像。只要这条边界守不住，测试通过的结果就很难代表生产将要运行的结果。

3.3 失败定位：先判断层次再看命令#

容器化排障最怕一上来就执行熟悉的命令。看到服务访问失败，有人先看业务日志，有人先重启容器，有人先改配置，有人先怀疑网络。正确顺序应该是先判断失败发生在哪个层次，再选择证据入口。

构建层失败，通常发生在 CI、Dockerfile、依赖下载、编译、测试、基础镜像拉取或镜像扫描阶段。证据入口是构建日志、测试报告、镜像构建缓存、基础镜像版本和 CI 环境变量。运行层失败，通常表现为容器退出、重启、启动慢、端口未监听、文件权限不足、JVM 参数不合适。证据入口是容器状态、退出码、启动日志、docker inspect、Kubernetes Event 和资源指标。

配置层失败，通常表现为连接不上数据库、读取不到密钥、环境变量为空、配置文件路径不对、测试和生产行为不同。证据入口是部署声明、环境变量列表、挂载文件内容、ConfigMap 或 Secret 版本、应用启动时打印的配置摘要。网络层失败，通常表现为 DNS 解析失败、端口不通、Service selector 不匹配、Ingress 路由错误、网关超时。证据入口是 DNS 查询、端口监听、endpoint 列表、网关日志和链路追踪。

发布层失败，通常表现为新版本一直未就绪、滚动发布卡住、旧版本过早下线、回滚后仍异常。证据入口是 rollout 状态、ReplicaSet、Pod 事件、探针结果、发布历史和镜像版本。观测层失败，通常表现为服务其实异常，但日志、指标、链路没有证据，或者证据无法关联到版本。证据入口是日志采集器状态、标准输出、trace id、指标标签、告警规则和发布标记。

这套分层不是为了显得复杂，而是为了缩小搜索空间。后端工程师掌握容器化，最核心的能力不是背命令，而是在 5 分钟内判断问题应该落在哪个边界：制品、运行、配置、网络、存储、发布，还是观测。

4.1 示例目标与项目假设#

下面用一个 Spring Boot 风格的 backend-api 服务说明最小容器化链路。这个例子不是生产模板，它的目的有两个：第一，让你看到后端服务如何从 jar 变成镜像；第二，让你看到镜像、配置、日志、健康检查和依赖服务之间的基本关系。

项目假设如下：

• 应用构建后生成 target/backend-api.jar。
• 应用监听 8080 端口。
• 应用通过环境变量读取数据库和 Redis 地址。
• 应用提供 /actuator/health 健康检查接口。
• 本地使用 Compose 同时启动 API、MySQL 和 Redis。

4.2 Dockerfile 与构建上下文#

.dockerignore 用来避免把无关文件放进构建上下文：

1
.git
2
.idea
3
.vscode
4
target/classes
5
target/test-classes
6
*.log
7
node_modules

Dockerfile 如下：

1
FROM eclipse-temurin:21-jre
2

3
WORKDIR /app
4

5
COPY target/backend-api.jar /app/backend-api.jar
6

7
ENV TZ=Asia/Shanghai
8
ENV JAVA_OPTS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
9

10
EXPOSE 8080
11

12
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/backend-api.jar"]

4.3 Compose 编排与观察点#

本地 compose.yaml 如下：

1
services:
2
  backend-api:
3
    build:
4
      context: .
5
      dockerfile: Dockerfile
6
    image: backend-api:local
7
    container_name: backend-api
8
    environment:
9
      SPRING_PROFILES_ACTIVE: local
10
      DB_HOST: mysql
11
      DB_PORT: 3306
12
      DB_NAME: backend
13
      DB_USER: backend
14
      DB_PASSWORD: backend_dev_password
15
      REDIS_HOST: redis
16
      REDIS_PORT: 6379
17
    ports:
18
      - "8080:8080"
19
    depends_on:
20
      mysql:
21
        condition: service_healthy
22
      redis:
23
        condition: service_started
24
    healthcheck:
25
      test: ["CMD-SHELL", "wget -qO- http://localhost:8080/actuator/health | grep UP"]
26
      interval: 10s
27
      timeout: 3s
28
      retries: 12
29
      start_period: 30s
30

31
  mysql:
32
    image: mysql:8.4
33
    environment:
34
      MYSQL_DATABASE: backend
35
      MYSQL_USER: backend
36
      MYSQL_PASSWORD: backend_dev_password
37
      MYSQL_ROOT_PASSWORD: root_dev_password
38
    ports:
39
      - "3306:3306"
40
    volumes:
41
      - mysql-data:/var/lib/mysql
42
    healthcheck:
43
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
44
      interval: 10s
45
      timeout: 5s
46
      retries: 10
47

48
  redis:
49
    image: redis:7.2
50
    ports:
51
      - "6379:6379"
52

53
volumes:
54
  mysql-data:

本地启动流程可以写成：

1
./mvnw clean package -DskipTests
2
docker compose up --build
3
curl http://localhost:8080/actuator/health

这个例子已经具备容器化学习所需的几个观察点。镜像由 Dockerfile 构建，依赖服务由 Compose 声明，数据库状态进入 volume，API 通过服务名访问 mysql 和 redis，健康检查由容器运行时执行，日志默认进入标准输出。它仍然不是生产方案，因为密码写在 Compose 文件里，没有资源限制，没有非 root 用户，没有镜像扫描，没有固定 digest，没有部署审计，也没有统一日志和指标采集。学习时可以先跑通，理解时必须知道这些边界。

5.1 Dockerfile 字段：先固定运行制品#

.dockerignore 的意义经常被低估。构建上下文越大，构建越慢，泄露风险越高，缓存越不稳定。把 .git、IDE 配置、日志、测试产物和无关目录排除掉，可以让镜像构建只依赖真正需要的输入。生产团队还应该避免把本地密钥、证书、临时导出数据放进构建上下文，否则即使 Dockerfile 没有 COPY 它们，也可能在构建过程或缓存中留下风险。

FROM eclipse-temurin:21-jre 表达基础运行时。后端应用选择基础镜像时，不只是看 JDK 版本，还要看镜像来源、系统发行版、更新策略、漏洞修复节奏、字体和证书支持、时区处理方式、CPU 架构兼容性。学习阶段可以使用官方 JRE 镜像快速开始，生产阶段应该固定版本，建立基础镜像升级流程，并通过扫描和回归测试验证升级影响。

WORKDIR /app 表达应用运行目录。它看似普通，实际上会影响相对路径、日志路径、临时文件路径和启动脚本行为。很多本地能跑、容器里失败的问题，来自应用默认从当前目录读取配置或模板文件。后端项目应该尽量显式指定配置路径，并在启动日志中打印关键路径，这样排障时能直接确认应用到底从哪里读取资源。

COPY target/backend-api.jar /app/backend-api.jar 把构建产物放进镜像。这里隐含一个重要边界：应用编译和镜像构建最好由 CI 串起来，而不是开发者手动把 jar 复制进目录。否则镜像里的 jar 可能不是当前 commit 编出来的。更严谨的做法是在镜像 label 中写入 git.commit、build.id、build.time，并在应用 /actuator/info 或启动日志中暴露这些信息。

ENV TZ=Asia/Shanghai 处理默认时区。时区问题在日志、定时任务、缓存过期、报表统计、数据库时间字段中非常常见。容器化以后，团队应该明确使用 UTC 还是业务时区，并保证 JVM、系统时区、数据库时区、日志采集时区的解释一致。不要只在容器里随手设置时区，却不验证应用和数据库之间的时间语义。

ENV JAVA_OPTS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError" 是 JVM 容器化的重要入口。容器有内存限制时，JVM 必须能感知限制并合理分配堆、元空间、线程栈和直接内存。MaxRAMPercentage 不是万能答案，真实生产还要结合服务类型、请求并发、GC 策略、直接内存使用、线程数和容器 memory limit 调整。ExitOnOutOfMemoryError 的价值是让严重 OOM 快速失败并由编排平台重建，而不是让进程处于不可预期状态。

EXPOSE 8080 是镜像元数据，不等于真正发布端口。它告诉使用者应用默认监听哪个端口，但不会自动把端口映射到宿主机，也不会创建 Kubernetes Service。学习时容易误以为写了 EXPOSE 就能访问，实际还需要 Compose 的 ports、Kubernetes Service 或 Ingress 等对象把流量接进来。

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/backend-api.jar"] 表达容器启动入口。这里使用 sh -c 是为了展开 JAVA_OPTS，但生产中要注意信号传递和进程模型。理想情况下，Java 进程应该作为主进程接收 SIGTERM，并配合 Spring Boot 的 graceful shutdown 完成优雅停机。如果启动脚本过于复杂，信号可能被 shell 吞掉，导致滚动发布时旧实例无法及时释放连接。

5.2 Compose 字段：把依赖关系显式化#

compose.yaml 里的 build 表达本地如何构建镜像，适合开发和学习，不适合生产发布直接使用。生产发布通常应该使用 CI 构建并推送到仓库的镜像，部署系统只拉取已验证镜像。这样才能保证测试、预发和生产消费的是同一份制品。

image: backend-api:local 给镜像命名。学习阶段使用 local 没问题，但生产阶段必须有稳定版本策略。推荐把服务名、语义版本或日期、commit 短哈希放进 tag，并在部署侧记录 digest。没有版本策略的镜像，会让回滚和审计变得非常困难。

environment 注入应用配置。这里的数据库密码只是本地示例，不能照搬到生产。生产里敏感信息应该由 Secret、密钥平台或环境级配置系统管理，并限制读取权限。普通配置也不应该无限膨胀成几十个环境变量，超过一定复杂度后，配置文件挂载或参数中心更容易治理。

DB_HOST: mysql 体现了容器网络中的服务名访问。Compose 会为同一 project 下的服务建立默认网络，backend-api 可以通过 mysql 解析到数据库容器。很多初学者会在容器里写 localhost，结果 API 尝试连接自己这个容器，而不是数据库容器。这个错误在 Kubernetes 里同样常见，只是对象会变成 Service DNS。

ports: "8080:8080" 表达宿主机端口到容器端口的映射。左边是宿主机端口，右边是容器端口。本地调试需要它，容器之间互相访问通常不需要它。生产 Kubernetes 中通常由 Service 和 Ingress 负责流量入口，而不是直接暴露 Pod 端口。

depends_on 解决启动顺序的一部分问题，但不等于应用级依赖可靠。数据库容器健康，不代表 schema 已经迁移完成，也不代表应用连接池一定能立即建立连接。后端应用仍然需要合理的连接重试、启动失败策略、迁移流程和健康检查。把所有依赖问题都交给 depends_on，会在测试环境制造偶然成功。

healthcheck 是容器运行状态和应用语义之间的桥。端口打开不代表服务可用，进程存在也不代表依赖正常。健康检查应该尽量区分“进程是否活着”和“是否可以接流量”。在 Kubernetes 中，这会进一步拆成 startupProbe、livenessProbe 和 readinessProbe。第一篇只需要记住一点：没有健康检查的容器化发布，很难做到自动化回滚和稳定流量切换。

volumes: mysql-data:/var/lib/mysql 把数据库数据放进命名卷。它说明容器本身可以删除重建，但数据不应该跟着容器一起丢。对于后端业务服务，通常不建议把业务状态写入应用容器本地文件系统。上传文件、报表导出、缓存、队列积压、临时文件都要明确生命周期，否则重启后数据丢失会成为高频事故。

5.3 配置、健康检查与日志的边界#

还要特别区分“配置”和“密钥”。配置是环境差异的普通表达，例如超时时间、开关、依赖地址、线程池大小；密钥是需要权限控制和审计的敏感信息，例如数据库密码、API token、证书私钥。两者都可以通过环境变量或文件注入，但治理方式不同。普通配置关注版本、审批、灰度和回滚，密钥还要关注加密、最小权限、轮换、访问审计和泄露响应。把密钥当普通配置写进镜像或 Git，是容器化新手非常常见也非常危险的错误。

配置注入方式也会影响应用设计。环境变量简单直接，适合少量扁平配置；文件挂载适合结构化配置和证书；配置中心适合动态开关和集中治理；Secret 适合敏感数据但不等于完整密钥生命周期管理。后端应用不要假设所有配置都能热更新，也不要假设所有配置变更都必须重启。哪些配置需要重启，哪些配置可以动态生效，哪些配置变更会影响连接池、缓存、线程池和路由，都应该在应用文档和发布流程中写清楚。

健康检查的字段也要避免过度简化。学习环境里用 /actuator/health 返回 UP 很方便，但生产环境里要思考这个 UP 到底代表什么。如果健康检查强依赖数据库，那么数据库短暂抖动可能导致所有实例被判定不可用，触发雪崩；如果健康检查完全不看依赖，那么服务虽然返回 UP，但真实请求全部失败。更合理的方式是区分启动检查、存活检查和就绪检查：启动检查给慢启动应用足够时间，存活检查判断进程是否需要重启，就绪检查判断实例是否可以接流量。

日志输出同样不是小事。容器化推荐应用把日志输出到 stdout/stderr，不是因为文件日志不能用，而是因为标准输出更容易被运行时和采集器统一接管。如果应用仍然写本地文件，团队就要额外处理挂载、滚动、清理、权限和采集路径。后端服务最好在日志中稳定包含 trace id、请求路径、状态码、耗时、异常类型、服务名、版本和环境，这样发布后才能把某次异常和某个镜像、某个配置、某个实例关联起来。

6.1 本地、CI 与测试环境的价值#

本地开发阶段，容器化最大的价值是降低环境准备成本。新人不需要手工安装 MySQL、Redis、消息队列和一堆依赖，只要能启动 Compose，就能获得接近团队约定的开发环境。但本地开发不应该追求和生产完全一致，否则会把学习成本和机器成本推得太高。本地阶段重点是依赖可复现、配置可见、日志可读、启动足够快。

CI/CD 阶段，容器化的价值是让构建产物变成可追踪制品。CI 不应该只产出一个 jar，还应该产出镜像、镜像标签、digest、测试报告、扫描报告和构建元数据。每一次发布都应该能回到 CI 记录：这个镜像从哪个 commit 来，经过哪些测试，使用哪个基础镜像，谁触发构建，推送到哪个仓库。没有这些记录，容器化只是把不可追踪从服务器目录转移到了镜像仓库。

测试环境阶段，容器化的价值是减少环境漂移。测试环境应该尽量使用和生产相同的镜像，只通过配置区分依赖地址、开关、资源规格和流量入口。这样测试发现的问题才更接近生产风险。测试环境也应该保留必要观测能力，否则测试失败后无法判断是应用 bug、配置错误、依赖不可用，还是容器运行问题。

预发和生产阶段，容器化的价值是让发布变成受控替换。新版本不应该直接覆盖旧版本，而应该先创建新实例，等待健康检查通过，再逐步接入流量。旧版本不应该立刻删除，而应该保留回滚窗口。发布系统不应该只看容器是否启动，还要看错误率、延迟、资源、日志和关键业务指标。对于后端 API 来说，真正的发布完成是“新版本稳定承接业务流量”，不是“Pod 变成 Running”。

6.2 团队协作中的共同语言#

团队协作阶段，容器化的价值是形成共同语言。开发关注应用如何读取配置、输出日志、处理信号和暴露健康检查；测试关注依赖如何复现、数据如何准备、异常如何制造；平台关注镜像、权限、资源、调度、网络、发布和回滚；运维关注告警、容量、备份、恢复和复盘。容器化把这些角色连接到同一条链路上，大家不再围绕“某台机器怎么了”沟通，而是围绕“哪个对象、哪个版本、哪个状态、哪个证据”沟通。

6.3 贯穿案例：订单 API 的容器化路径#

假设团队有一个订单 API，最初的启动方式是把 order-api.jar 上传到测试机，执行 nohup java -jar order-api.jar --spring.profiles.active=test &。数据库地址写在机器上的 application-test.yml，日志写到 /data/logs/order-api，上传文件暂存在 /data/upload，发布时运维手工备份旧 jar。这个方式能跑，但所有关键状态都在机器里。

第一步容器化时，不要急着上 Kubernetes。先写 Dockerfile，把 JDK、jar、启动入口、工作目录固定下来；把数据库地址、Redis 地址、profile、日志级别变成外部配置；把日志改为标准输出；把上传文件改成对象存储或明确挂载目录；把健康检查接口打开。此时目标是让订单 API 可以在本地和测试环境用同一份镜像运行。

第二步进入 CI。每次合并主干时，CI 编译、测试、构建镜像、写入 commit label、推送仓库，并把 tag 和 digest 记录到构建结果。测试环境只允许部署 CI 产出的镜像，不允许手工构建。本阶段的目标是让“测试正在测什么”变得可回答。

第三步进入部署治理。测试环境和预发环境使用同一镜像，不同配置；发布时保留上一版本镜像和配置；健康检查不通过时不接流量；发布后观察错误率、延迟、JVM 内存、数据库连接池和关键业务日志。如果新版本异常，回滚的是镜像和配置组合，而不是只替换 jar。

第四步进入生产化。镜像使用非 root 用户，基础镜像定期升级，Secret 不进入镜像，资源 requests 和 limits 有压测依据，应用支持优雅停机，日志带 trace id，指标带版本标签，发布单记录 commit、digest、配置版本和操作者。到这一步，容器化才不只是“启动方式变化”，而是变成团队交付能力的一部分。

这个案例里最值得注意的是，容器化改造并不要求一次性完成所有平台能力。很多团队失败，不是因为 Docker 或 Kubernetes 难，而是因为他们把本地运行、CI 构建、配置治理、日志规范、健康检查、资源限制、发布策略和回滚机制一次性堆到同一个迁移任务里，结果每一层都做得很浅。更稳妥的做法是每一阶段都留下可验证成果：第一阶段能稳定启动，第二阶段能追踪制品，第三阶段能区分环境差异，第四阶段能安全发布和回滚。

后端负责人在推动这类改造时，还要明确哪些问题属于应用团队，哪些问题属于平台团队。应用团队应该负责 Dockerfile、启动参数、健康接口、日志规范、配置读取、优雅停机和业务依赖说明；平台团队应该负责镜像仓库、基础镜像、CI 模板、部署模板、Secret 接入、资源策略、观测采集和发布系统。边界不清时，容器化会变成互相甩锅：应用说平台没调度好，平台说应用不健康，运维说日志不规范，测试说环境不可复现。好的容器化实践会把这些责任提前写进模板和检查项。

7.1 高频故障先按边界分类#

第一类是“本地能跑，容器内启动失败”。现象通常是容器启动后立即退出，或者健康检查一直失败。可能原因包括 jar 路径不对、工作目录变化、配置文件没复制、字体或证书缺失、时区差异、启动命令无法展开、文件权限不足。排查时先看退出码和启动日志，再用 docker inspect 看入口命令、环境变量、工作目录和挂载，必要时临时进入同版本镜像检查文件。修复方向不是在运行中的容器里手工补文件，而是回到 Dockerfile、构建流程或外部配置。预防方式是在 CI 中构建后立即启动容器做 smoke test，至少验证进程能启动、端口能监听、健康检查能返回。

第二类是“测试和生产行为不同”。现象可能是同一个接口在测试正常、生产超时，或者生产读取了错误开关。可能原因包括测试和生产不是同一镜像 digest，配置项名称不同，环境变量覆盖顺序不同，数据库 schema 不一致，JVM 参数和资源限制不同，依赖服务版本不同。排查时不要先改业务代码，而要先拉出两边的镜像 digest、配置版本、环境变量摘要、应用启动日志、数据库迁移记录和资源限制。修复方向是统一制品来源，把环境差异收敛到可审查配置。预防方式是禁止环境内手工改配置，发布系统记录镜像和配置组合。

第三类是“发布后无法回滚”。现象是新版本异常，但回滚旧镜像后仍然异常，或者根本不知道旧版本是什么。可能原因包括使用 latest，tag 被覆盖，只记录了镜像没有记录配置，数据库迁移不可逆，旧版本镜像被清理，部署系统没有保留发布历史。排查时先确认上一稳定版本的镜像 digest、配置版本、数据库迁移状态和流量切换记录。修复方向是恢复上一组可运行组合，而不是只替换镜像。预防方式是每次发布都记录镜像 digest、配置版本、数据库变更、操作者和回滚策略，对破坏性数据迁移设置单独审批。

第四类是“日志找不到或看不懂”。现象是容器运行异常，但日志系统没有记录，或者日志里没有版本、请求 id、环境、实例信息。可能原因包括应用仍写本地文件，日志目录没有挂载，日志采集器没有采集标准输出，JSON 格式不规范，日志级别被生产配置关闭。排查时先确认应用输出位置，再看容器 stdout/stderr，再看采集器状态和日志标签。修复方向是让应用默认输出标准输出，并为生产日志补齐 trace id、span id、service、version、environment、instance 等字段。预防方式是把日志规范写进服务模板，而不是每个项目自己决定。

第五类是“容器重启后状态丢失”。现象是上传文件丢失、缓存文件丢失、临时任务状态丢失，或者重启后应用认为自己是第一次启动。可能原因是把业务状态写入容器可写层，或者没有区分临时文件和持久数据。排查时看应用写入路径、容器挂载、volume、对象存储和数据库记录。修复方向是把业务状态迁移到数据库、对象存储、消息队列或明确的持久化卷，把临时文件设计为可丢弃。预防方式是在代码评审和部署评审中明确每一类写入路径的生命周期。

7.2 现场保留比马上重启更重要#

这五类故障有一个共同点：都不能靠“重启试试”解决根因。重启可能恢复现场，但如果没有记录证据，下一次还会发生。容器化后的排障应该形成固定问法：当前运行的是什么镜像，注入了什么配置，进程为什么退出，依赖是否可达，流量是否已经接入，日志和指标是否能证明现象，修复应该回到制品、配置、部署还是代码。

实际事故中，排障顺序还要考虑“保留现场”。如果容器一直重启，不要第一时间删除重建；先保存当前镜像、配置、事件、日志、退出码和最近发布记录。如果怀疑配置错误，不要直接在线上改环境变量；先把当前配置版本记录下来，再用可回滚方式修正。如果怀疑镜像问题，不要只在本地重新 build 一个同名 tag；应该构建新 tag，保留旧 digest，确保后续能比较差异。容器化提供了更好的证据入口，但前提是团队不要在慌乱中把证据抹掉。

排障时还可以采用“从外到内”和“从新到旧”两条线并行。从外到内，是先看用户入口、网关、Service、实例就绪、容器状态、应用日志、依赖连接，逐步缩小范围；从新到旧，是先看最近一次发布、最近一次配置变更、最近一次依赖升级、最近一次基础镜像更新、最近一次资源调整。很多线上问题都和最近变更有关，但不能因为最近变更可疑就跳过证据验证。好的事故处理，是用变更线索提出假设，用容器化证据验证假设。

7.3 灰色失败要靠业务指标识别#

对于后端服务，还要特别关注“灰色失败”。不是所有故障都会表现为容器退出。线程池耗尽、连接池耗尽、DNS 偶发超时、下游慢调用、GC 抖动、缓存击穿、日志阻塞、磁盘写满，都可能让容器保持 Running，但业务已经不可用。这就是为什么生产发布不能只看容器状态，还要看错误率、延迟分位数、依赖调用、JVM 内存、GC、线程数、连接池和业务指标。容器状态告诉你进程是否存在，业务指标才告诉你服务是否健康。

8.1 生产边界不是本地示例的自然延伸#

学习环境可以简化，但生产环境不能把简化当最佳实践。一个能在本地启动的容器，距离能进入生产还有很长距离。生产化边界至少包括镜像不可变、安全身份、敏感信息、资源管理、健康检查、优雅停机、配置治理、日志指标、发布回滚和供应链安全。

镜像不可变意味着生产发布不应该在运行中的容器里修改文件，也不应该依赖可变 tag。每次变更都应该产生新镜像或新配置版本，并通过发布系统替换实例。安全身份意味着容器不应该默认 root 运行，文件权限和运行用户要提前设计。敏感信息意味着密码、token、证书不能写进镜像、Git 仓库或普通日志，而应该由 Secret 或密钥平台注入。

资源管理意味着服务要有 requests 和 limits，JVM 参数要与容器内存匹配。没有资源边界的容器会在压力下互相影响，有资源边界但 JVM 不理解限制，也可能频繁 OOM。健康检查意味着平台知道什么时候可以接流量，什么时候应该重启，什么时候还在启动期。优雅停机意味着发布和扩缩容时，应用能停止接新请求，等待已有请求完成，关闭连接池，再退出进程。

配置治理意味着环境差异应该有所有者、版本、审批和回滚路径。日志指标意味着服务能解释自己正在发生什么，而不是只暴露“进程还在”。发布回滚意味着团队提前知道失败时回到哪个镜像、哪个配置、哪个数据库状态。供应链安全意味着基础镜像、依赖、构建环境、仓库权限和扫描报告都要进入治理视野。

8.2 学习写法与生产写法的分界#

学习写法可以把 MySQL 密码放在 Compose 文件里，因为目标是理解服务之间如何连接；生产写法必须使用 Secret 或密钥平台，因为目标是降低泄露和误用风险。学习写法可以使用 backend-api:local，因为目标是快速构建；生产写法必须使用可追踪 tag 或 digest，因为目标是确定性发布和回滚。学习写法可以只写一个 healthcheck，生产写法要区分启动、存活和就绪，因为三者对应不同恢复动作。

学习写法可以用 root 用户运行，生产写法应该使用非 root 用户并限制文件权限。学习写法可以不设置资源限制，生产写法必须根据压测和容量规划设置资源。学习写法可以用 ports 暴露本地端口，生产写法应该通过 Service、Ingress 或网关接入流量。学习写法可以只看控制台日志，生产写法要接入统一日志、指标、链路追踪和告警。

这个分界非常重要，因为很多事故不是来自“不懂容器”，而是来自把学习环境的便利写法带进生产。学习阶段追求的是理解快，生产阶段追求的是风险可控。两者不是同一套标准。

8.3 生命周期、容量与安全要前置#

生产化还有一个经常被忽略的维度：生命周期。镜像不是构建完就结束，它需要定期重建、扫描、升级基础镜像、清理过期版本、保留回滚窗口。Secret 不是创建完就结束，它需要轮换、权限审计和泄露响应。配置不是写完就结束，它需要变更记录、灰度验证和回滚路径。健康检查不是能返回就结束，它需要随着依赖和业务语义调整。容器化以后，团队管理的是一组持续变化的对象，而不是一次性脚本。

容量规划也不能省略。容器让服务更容易复制，但复制不等于无限扩容。后端系统的瓶颈可能在数据库连接数、缓存连接数、消息队列消费能力、下游限流、网关连接、节点资源、镜像拉取速度和日志采集吞吐。给 Deployment 增加副本前，要知道每个副本会增加多少数据库连接、多少内存、多少线程、多少 QPS、多少日志量。否则容器扩容可能只是把压力更快地传递给下游。

安全边界同样要前置。非 root、只读文件系统、最小 Linux capability、镜像扫描、SBOM、仓库鉴权、Secret 注入、网络策略、出站访问控制，这些不是“安全团队以后再补”的附加项。越到生产后期再补，迁移成本越高。第一篇不需要展开所有安全细节，但必须建立一个判断：容器隔离不是安全的全部，容器化只是给安全治理提供了更清晰的对象边界。

9.1 适合引入容器化的场景#

容器化适合那些需要跨环境交付、依赖复杂、发布频繁、团队协作多人、多服务组合、需要弹性扩缩和统一治理的后端系统。只要服务需要在本地、测试、预发、生产之间保持一致，只要团队需要知道某次发布到底运行了什么，只要故障回放需要还原当时制品和配置，容器化就有明确价值。

9.2 不适合为了形式强行引入#

容器化不适合被当成装饰性技术。如果一个项目只是个人脚本、一次性数据处理、极低频内部工具，部署环境单一且没有团队协作成本，强行引入 Docker、Compose、Kubernetes、Helm 可能只会增加维护负担。容器化也不能替代基础工程能力。如果应用本身没有健康检查、没有结构化日志、没有配置边界、没有优雅停机、没有测试，容器化只能把问题包装起来，不能消除问题。

9.3 决策判断：不要为了“云原生感”而容器化#

判断是否应该容器化，可以问几个直接的问题。这个服务是否需要多人稳定启动。这个服务是否依赖数据库、缓存、消息队列或系统库。这个服务是否需要频繁发布。这个服务是否需要在多个环境运行。这个服务是否需要快速回滚。这个服务是否需要被平台统一调度、限流、观测和治理。如果大部分答案是肯定的，容器化通常值得投入。

也要问反向问题。团队是否有能力维护镜像和基础镜像升级。是否有仓库权限和版本策略。是否有 CI 构建和扫描。是否有配置和密钥管理。是否有人负责排障文档和发布模板。如果这些能力完全缺失，直接上 Kubernetes 可能会让问题更多。更合理的顺序是先把单服务 Dockerfile 写规范，再用 Compose 收敛本地依赖，再接入 CI 构建镜像，最后再进入 Kubernetes 和 Helm/Kustomize 的多环境治理。

后端团队默认可以采用渐进式路线：先容器化运行时，再标准化镜像构建，再把配置外置，再把发布接入平台，再补观测和回滚。不要一开始就追求全量云原生对象，也不要停留在“本地能 docker run”就宣布完成。容器化是一条工程能力成熟路线，不是一个一次性任务。