Docker 镜像基础：分层原理与体积构成分析
在微服务架构中，每个服务都被打包为一个独立的 Docker 镜像。理解镜像的底层构造——分层原理、联合文件系统、缓存机制以及体积构成——是后续进行多阶段构建优化的理论基石。本章将逐一拆解这些核心概念。
2.1 镜像分层原理
Docker 镜像并非一个巨大的单体文件，而是由一系列只读层（Layer）堆叠而成。每一层代表 Dockerfile 中的一条指令（如 FROM、RUN、COPY）。这种设计使得镜像的构建、存储和传输变得高效。
- 层是增量的：每一层只记录与上一层的差异（diff）。例如，安装一个软件包，新层只包含该软件包新增的文件，而非整个文件系统。
- 层是只读的：构建完成后，所有层均不可修改。当容器运行时，会在这些只读层之上添加一个可写层（容器层）。
- 层可共享：多个镜像可以共用相同的底层（如
alpine:3.18基础层），从而节省磁盘空间和网络带宽。
核心洞察： 镜像层是 Docker 实现“构建一次，到处运行”以及高效分发的基础。后续的多阶段构建正是利用分层特性，将构建产物与构建环境分离，只保留最终运行所需的层。
2.2 UnionFS 与 OverlayFS
分层堆叠的机制依赖于联合文件系统（UnionFS）。Docker 早期使用 AUFS，现代 Docker 引擎（Linux 环境）默认使用 OverlayFS（特别是 Overlay2 驱动）。
| 特性 | UnionFS (通用概念) | OverlayFS (Docker 默认) |
|---|---|---|
| 工作原理 | 将多个目录（分支）联合挂载到同一个挂载点，呈现为一个统一的文件系统视图。 | 将 lowerdir（只读层）和 upperdir（可写层）叠加，通过 merged 目录提供统一视图。 |
| 层数支持 | 理论上支持多层，但性能随层数增加下降。 | Overlay2 支持最多 128 层，性能稳定。 |
| 写时复制 (CoW) | 支持。当修改只读层文件时，先将文件复制到可写层再进行修改。 | 支持。性能优于 AUFS，尤其在页面缓存方面。 |
| 性能 | 中等，受限于分支数量。 | 高，是当前 Linux 上 Docker 的首选存储驱动。 |
关键点： OverlayFS 通过“写时复制（Copy-on-Write）”策略，确保容器对文件系统的修改不会影响镜像层，同时最大限度地减少磁盘 I/O。
2.3 镜像层缓存机制
Docker 在构建镜像时，会利用构建缓存（Build Cache）来加速重复构建。其核心规则是：如果某层对应的指令和上下文（如 COPY 的文件内容）没有变化，Docker 会直接复用之前构建的缓存层。
- 指令匹配：Docker 会比较当前指令与缓存中上一条指令的哈希值。
- 上下文校验：对于
COPY和ADD指令，Docker 会计算被复制文件的校验和（Checksum）。如果文件内容发生变化，该层及之后所有层的缓存都会失效。 - 缓存失效链：一旦某一层缓存失效（Cache Miss），其后的所有层都必须重新构建，无法再使用缓存。
常见陷阱： 在 Dockerfile 中，将频繁变化的指令（如
COPY . .）放在前面，会导致后续所有层（包括耗时的 RUN apt-get install）的缓存失效，大幅增加构建时间。正确的做法是将“不变”的指令（如安装系统依赖）放在前面，“易变”的指令（如复制源代码）放在后面。
2.4 镜像体积构成分析
一个 Docker 镜像的体积由所有只读层的大小总和决定。理解体积的构成，是进行优化的前提。以下是常见的体积“杀手”：
| 体积来源 | 典型示例 | 优化方向 |
|---|---|---|
| 基础镜像 | ubuntu:22.04 (~77MB) vs alpine:3.18 (~5MB) |
选择更小的基础镜像（如 Alpine、Distroless） |
| 构建依赖 | GCC、Make、Maven、npm 等编译工具 | 多阶段构建：仅在构建阶段使用，最终镜像不包含 |
| 缓存文件 | apt-get 的 /var/cache/apt、pip 的 ~/.cache |
在同一个 RUN 指令中清理缓存（&& rm -rf /var/lib/apt/lists/*） |
| 不必要的文件 | README、测试代码、日志文件、.git 目录 | 使用 .dockerignore 排除，或只复制必要文件 |
| 重复的层 | 多个 RUN 指令产生多个层，即使内容很小 |
合并 RUN 指令，减少层数 |
实战要点： 在微服务架构中，每个服务独立部署，镜像体积直接影响启动速度、网络传输成本和磁盘占用。通过分析体积构成，我们可以精准定位优化点。例如，一个典型的 Spring Boot 应用，通过从 Ubuntu + JDK 11 切换到 Alpine + JRE 11，并采用多阶段构建，体积可以从 450MB 降至 120MB 以下。