在 Docker 主机上，存储驱动决定镜像层与容器可写层如何组织，也直接影响镜像构建、容器启动、文件修改和磁盘空间利用率。很多环境默认使用 Overlay2，但“默认可用”不等于“所有负载都适合”。本文从选型原则和实测方法入手，分析 Overlay2 的性能差异及优化方向。🔍
一、存储驱动到底负责什么
Docker 镜像由多个只读层组成，容器启动后再增加一个可写层。存储驱动负责组合这些层，并通过写时复制机制处理文件变更。它适合保存日志缓存、临时文件等短生命周期数据，但不应替代持久化存储。
当容器修改镜像层中的已有文件时，驱动通常要先把文件复制到可写层，再执行修改。这个过程称为 Copy-up。文件越大、首次修改越频繁，额外开销越明显。因此，数据库、消息队列以及高频写日志服务，不宜把核心数据直接写进容器可写层。
二、常见驱动如何选择
- Overlay2：适合大多数 Linux 生产环境，架构简单，镜像层共享效率较高，运维经验和生态支持也较成熟。
- Fuse-overlayfs：常用于无根模式，能够在权限受限的环境中提供类似 OverlayFS 的分层能力。
- Btrfs、ZFS：适合已经统一采用对应文件系统，并需要快照、校验或高级存储管理能力的场景，但运维复杂度更高。
- VFS：兼容性较强，却会完整复制数据，空间占用和性能通常不适合常规生产负载，多用于测试或排障。
需要注意的是，Docker Engine 29.0 及之后的新安装默认使用 containerd 镜像存储，其底层采用 snapshotter，而不是传统存储驱动。老环境继续使用 Overlay2 时，本文的原理和测试方式仍然有参考价值，具体差异应以 Docker 存储文档 为准。
三、Overlay2 为什么表现较好
Overlay2 基于 Linux OverlayFS，将多个 lowerdir 只读目录、一个 upperdir 可写目录和 workdir 工作目录合并为统一视图。读取未修改文件时，系统可以直接访问较低层；新增文件则直接进入可写层，因此容器启动和普通读取通常比较轻量。🚀
Overlay2 还能利用页缓存。多个容器读取相同镜像文件时，有机会共享缓存，减少重复磁盘读取。不过，性能并非只由驱动名称决定，Linux 内核版本、底层文件系统、磁盘类型、目录层级、文件数量和访问模式都会改变结果。
如果底层采用 XFS，需要确认启用了 d_type 支持，通常应在 docker info 中看到 Supports d_type 为 true。相关前提、配置方法和限制可参考 OverlayFS 官方说明。
四、怎样做一组可信的实战对比
测试重点不应只是跑出一个“每秒多少 MB”的数字，而是比较同一台主机、同一镜像、同一数据规模下，不同存储路径的相对差异。建议准备三组路径：
- 直接写入宿主机目录，作为底层文件系统基线。
- 通过 Docker volume 写入，观察绕过容器可写层后的表现。
- 直接写入容器可写层，测量 Overlay2 带来的额外成本。
每组分别测试顺序读写、随机读写、小文件批量创建、元数据操作和已有大文件首次修改。测试前记录内核、Docker 版本、存储驱动、底层文件系统、挂载参数及磁盘型号；每项执行多轮，同时关注平均值和波动范围，避免把页缓存或后台任务造成的偶然结果当成结论。
可先使用 docker info 检查 Storage Driver、Backing Filesystem、Supports d_type 和 Native Overlay Diff，再通过系统 I/O 工具采集吞吐、延迟、IOPS、CPU 使用率及磁盘等待时间。测试期间不要混入镜像拉取、日志轮转或其他批量任务。
五、性能差异通常出现在哪里
首次修改已有文件
当应用第一次写入只读镜像层中的文件时，会触发 Copy-up。若文件体积较大，即使只改动少量内容，也可能产生明显延迟。解决思路是把频繁变化的数据放入 volume，并避免在镜像层预置随后会被持续修改的大文件。
海量小文件与元数据操作
软件包安装、解压依赖、扫描目录和频繁创建删除小文件，会放大路径查找及元数据开销。构建镜像时应减少无效文件，合理使用构建缓存，并通过多阶段构建缩小最终镜像。
数据库与持续写入负载
数据库通常同时要求低延迟、持久化和故障恢复能力。将数据目录放在容器可写层，不仅可能增加写时复制开销，删除容器后还会失去数据。官方文档同样建议对写密集型和持久化数据使用 volume。📦
六、生产环境优化清单
- 使用 docker info 核实实际驱动，不要只依赖配置文件推断。
- 将数据库、上传文件、队列数据和高频日志迁移到 volume 或可靠外部存储。
- 控制镜像层数量与体积，清理包管理缓存和无用构建产物。
- 避免应用启动后修改镜像层中的大型文件，可在挂载目录中提前初始化。
- 监控磁盘容量、inode、I/O 延迟和容器可写层增长，防止小文件耗尽 inode。
- 切换驱动前备份或推送镜像，并迁移持久化数据，因为切换后原有本地镜像和容器可能无法直接访问。
总结
Overlay2 的优势在于分层模型简洁、镜像共享高效，并能满足多数 Linux 容器的通用需求；它的短板主要集中在 Copy-up、元数据密集操作和容器可写层的持续写入。真正合理的选型，不是追求某个孤立跑分，而是让 Overlay2 管理镜像层与临时数据，让 volume 或外部存储承载持久化、高频写入数据。先建立宿主机基线，再对比 volume 与可写层，才能得到对自身业务有意义的结论。✅
