在 2026 年的容器编排生态中，Docker Compose 依然被广泛用于开发环境和小规模部署。但当团队考虑将其引入生产环境时，核心问题不再是 “能否使用”，而是 “在什么条件下可以使用”。本文提供一个工程化的决策框架，从高可用能力、监控与自愈、扩缩容弹性三个维度定量评估 plain Docker Compose 的能力边界，并给出替代方案的选型建议。
高可用：单点故障的物理限制
Docker Compose 最根本的高可用限制在于其架构假设：它是为单主机设计的容器编排工具，不提供跨主机服务调度。这意味着整个栈共享同一个故障域 —— 当主机宕机时，所有服务同时不可用，无法通过在其他节点上重启容器来恢复。
具体而言，Compose 缺少三个关键能力。首先是无内置集群管理：没有类似 Kubernetes ReplicaSet 或 Docker Swarm 副本调度器的机制，无法将服务分布到多台机器。其次无自动故障转移：容器崩溃后可以通过 restart policy 恢复，但这是同一主机内的重启，无法应对底层硬件或虚拟机的故障。第三无跨主机流量分发：即使手动在多台主机上运行同一 compose 文件，它们之间也没有内置的负载均衡或服务发现机制。
定量决策阈值：如果业务对可用性的要求是全年可用率低于 99.9%（即年化停机时间不超过 8.7 小时），且可以接受手动故障处理窗口在 30 分钟以上，单节点 Compose 部署是可选项。否则，应考虑 Docker Swarm 或 Kubernetes。
监控与自愈：健康检查的被动属性
Docker Compose 支持通过 healthcheck 指令定义容器健康检查，但这是一个经常被误解的功能。healthcheck 的结果会反映在 docker inspect 的输出中，但 Docker Engine 本身不会根据健康状态自动执行任何操作。换言之，一个被标记为 unhealthy 的容器会持续运行，直到外部力量干预或进程自行退出。
这与 Kubernetes 的探针机制形成鲜明对比。Kubernetes 的 livenessProbe 检测到故障时会重启容器，readinessProbe 会将 Pod 从 Service 端点中摘除，两者都有明确的自动化行为。而 Compose 生态中，唯一的官方解决路径是升级到 Docker Swarm——Swarm 会自动重启不健康的任务。除此之外，团队需要自行部署类似 willfarrell/docker-autoheal 的 sidecar 容器来轮询健康状态并触发重启。
定量决策阈值：如果团队没有部署额外的自愈层（如 autoheal sidecar 或 Swarm 模式），且无法接受不健康容器持续运行超过 5 分钟产生错误响应，则 plain Docker Compose 不满足监控自愈需求。
除了容器级别的健康检查，生产环境还需要主机级别的监控。Compose 本身不提供节点监控能力 —— 磁盘空间、内存压力、Docker daemon 状态等都需要通过外部手段采集。Prometheus + cAdvisor 是常见的解决方案，但这意味着在单机部署场景下，监控栈的复杂度可能接近甚至超过业务本身。
扩缩容：水平扩展的缺失
Docker Compose 的 scale 能力是其文档中较少被强调的弱点。虽然 docker compose up 支持 --scale 参数（或通过 deploy.replicas 配置），但这个扩缩容仅限于单机范围内的副本数调整。它无法将容器分布到多台物理或虚拟主机上，也无法在副本之间实现流量的自动分发。
对于需要水平扩展的生产服务，这意味着：如果单个节点的 CPU 或内存成为瓶颈，无法通过增加节点来分担负载。流量高峰时无法自动扩容，需要手动登录主机调整副本数后重新部署。多实例部署需要手动维护负载均衡配置，Compose 不提供内置的 ingress 或负载均衡器。
定量决策阈值：如果服务的预期峰值 QPS 超过单台主机能够承载的范围（通常为数千级别，取决于业务类型），或者需要根据负载动态调整实例数，则必须使用 Swarm 或 Kubernetes。Plain Docker Compose 适合容量相对稳定、可预期小于单机上限的工作负载。
运维开销：被忽视的隐性成本
除了上述三个核心维度，生产环境的运维实践还涉及更琐碎但同样关键的操作。第一个常见问题是孤立容器（orphan containers）：从 compose 文件中移除某个服务后，docker compose up 不会自动删除旧容器，这些 “僵尸” 容器继续占用资源，直到手动加上 --remove-orphans 标志。这是一个每次部署都需要注意的参数。
第二个问题是日志与磁盘空间。默认的 json-file 日志驱动会无限写入 /var/lib/docker/containers/ 目录，在流量较大的主机上，这是磁盘空间耗尽的首要原因。生产环境必须在 /etc/docker/daemon.json 中配置 log-opts 的 max-size 和 max-file 参数，限制单个容器的日志轮转大小。
第三个问题是镜像更新。docker compose pull 会保留旧版镜像在磁盘上，累积后占用大量空间。应该定期执行 docker image prune 或在部署时使用镜像清理策略。同样，镜像标签（tag）是易变的，:latest 标签可能在几分钟内指向不同版本，生产环境应使用 digest（@sha256:...）来锁定具体版本。
综合运维阈值：如果团队没有建立标准化部署流程（如使用 ansible、terraform 或专用 agent），且无法保证每次部署都执行 --remove-orphans、配置日志轮转、清理旧镜像等操作，则 plain Docker Compose 的运维风险会随时间累积，最终导致生产事故。
替代方案选型路径
当评估结论是 plain Docker Compose 不满足需求时，下一步是选择替代方案。常见的路径有三条：
Docker Swarm 是最平滑的升级路径。它复用现有的 compose YAML 格式（通过 docker stack deploy），提供内置的服务副本调度、健康检查自动重启、滚动更新和 secrets 管理。对于已经熟悉 Compose 语法的团队，Swarm 的学习曲线极低。其局限在于生态规模和第三方工具兼容性不如 Kubernetes，适合单集群、对运维复杂度敏感的场景。
Kubernetes 是面向大规模、高可靠生产负载的标准选择。其缺点是陡峭的学习曲线和较高的运维开销，但在多租户、复杂网络策略、动态扩缩容等方面的能力是 Compose 和 Swarm 无法比拟的。对于面向客户的 SaaS 产品或需要跨云多活架构的系统，Kubernetes 是更稳妥的长期选择。
混合方案也值得考虑：部分非关键服务（如内部工具、一次性任务）继续使用 Compose 降低复杂度，核心业务流迁移到 Kubernetes。这种渐进式迁移策略可以在不中断业务的前提下逐步建立容器编排能力。
决策清单：何时可以采用 plain Docker Compose
综合以上分析，满足以下全部条件时，plain Docker Compose 可以作为生产就绪的选择：
- 服务为单节点部署，不存在跨主机高可用需求
- 团队已部署外部自愈层（如 autoheal sidecar）或接受 Swarm 模式
- 业务负载稳定，峰值不超过单机容量上限
- 建立了标准化的部署流程，确保 --remove-orphans、日志轮转、镜像清理等操作被执行
- 故障恢复时间目标（RTO）在 30 分钟以上，且有明确的应急响应流程
如果不满足其中任何一项，应认真考虑升级到 Docker Swarm 或 Kubernetes。工具的选择始终应服务于业务连续性目标，而非技术偏好。
参考资料
- Docker Compose 生产就绪实践分析（Distr）https://distr.sh/blog/running-docker-in-production/