在容器化技术（尤其是 Docker）的实践中，“一个容器内应该只运行一个主进程”（One process per container）是一条黄金法则。

要理解这句话，我们需要从技术实现原理和架构设计哲学两个维度来剖析，并将其与传统的虚拟机（VM）进行对比。

---

一、 容器与虚拟机的本质区别

这是理解“单进程”原则的基石。

• 虚拟机是一个“系统空间”：你可以在里面装 Web 服务器、数据库、日志收集器、监控工具等，就像在物理机上一样。
• 容器是一个“沙盒化的进程”：Docker 容器的生命周期是与它的主进程（PID 1）紧密绑定的。主进程结束，容器即刻退出。

---

二、 为什么容器内应该“只运行一个主进程”？

如果强行在 Docker 容器内运行多个无关联的进程（例如把 Nginx、MySQL 和 PHP 塞进同一个容器），会带来以下一系列严重问题：

1. 无法正确进行生命周期管理（僵尸进程问题）

在 Linux 中，1号进程（PID 1）是所有进程的祖先（如 systemd 或 init），它负责收割孤儿进程。

• 在容器中：你指定的 Entrypoint 就是 PID 1。如果这个进程不是专门的系统初始化进程（如普通的 Node.js 或 Python 脚本），它不具备收割僵尸进程的能力。
• 如果容器内运行了多个后台进程，一旦某个子进程挂掉，PID 1 无法感知，也不会去回收它，容器内就会产生大量的僵尸进程，最终耗尽系统资源。

2. 无法进行精准的健康检查与自动恢复

Kubernetes 或 Docker Swarm 等编排工具是通过监控容器的 PID 1 进程或通过特定的健康检查（Liveness Probe）来判断容器是否存活的。

• 单进程：Nginx 挂了 $\rightarrow$ 容器退出 $\rightarrow$ K8s 自动重启容器。
• 多进程：如果容器里同时运行了 Nginx 和 MySQL。MySQL 悄悄挂了，但 Nginx 还活着，容器依然处于 Running 状态。编排工具会认为容器“健康”，导致服务部分不可用却无法触发自动修复。

3. 破坏了“横向扩展（Scaling）”的灵活性

微服务架构的核心优势是按需扩展。

• 如果 Nginx 和 PHP 在同一个容器里，当 CPU 瓶颈在 PHP 时，你不得不将整个容器复制一份。这连带复制了并不需要扩容的 Nginx，造成资源浪费。
• 如果解耦成两个容器，你可以只将 PHP 容器从 2 个扩展到 10 个，而 Nginx 保持 2 个。

4. 日志收集与可观测性变得极其复杂

Docker 的标准日志收集机制（docker logs）默认捕获的是 PID 1 进程的标准输出（stdout）和标准错误（stderr）。

• 如果一个容器运行多个进程，它们的日志会混杂在一起，或者各自写到容器内的不同文件中，导致外部的日志收集工具（如 ELK、Fluentd）极难统一收集和分析。

5. 违背了“单一职责原则”与版本控制

• 安全更新：如果 MySQL 需要升级，在多进程容器中，你必须停止整个容器（连带影响 Nginx）。而单进程容器只需要重建 MySQL 容器即可。
• 镜像复用：单进程镜像职责单一，更容易被其他项目复用。

---

三、 误区澄清：“一个进程”不等于“绝对只有一个进程”

业内说的“一个主进程”，准确来说是“一个关注点（One focus）”或“一个主分类服务”。

在实际应用中，一个容器内允许存在辅助进程，只要它们是父子关系。例如：

• Nginx 启动时，会有一个 master 进程（PID 1）和多个 worker 进程（子进程）。这是完全合规的，因为 master 进程会负责管理 worker 进程的生命周期。
• 反例：在容器里用 supervisor 或 systemd 同时拉起一个 PHP-FPM 和一个 Redis。这两个进程没有父子继承关系，属于“多主进程”，这是应该避免的。

总结

• 虚拟机 像一个 “公寓”：里面有厨房、卧室、卫生间（各种服务），它们共享地基，但互不干扰。
• 容器 像一个 “专卖店”：只卖一种商品。如果你需要全套服务，应该用多家专卖店（多个容器）组合成一个商业街（容器编排，如 Kubernetes Pod），而不是把所有商品塞进一个柜台。