单个或多个容器
我在我的系统中有两个进程P1和P2，通过TCP彼此进行非常频繁的通信。 出于这个原因，它们都被托pipe在同一个虚拟机上。 我想消除虚拟机，而是托pipe我的系统在物理机器上的容器。 如果我dockerize我的系统，我有2个选项：
- 容器1包含P1，容器2包含P2。 这两个容器将被链接。 P1和P2之间的通信将跨越集装箱边界。
- 一个Container将包含P1和P2。 沟通将保持在容器内。
请引导我介绍上述两种方法的优点和缺点。
方法1中通信延迟方面的开销是多less？
一个容器中的几个进程的主要问题是信号pipe理：你如何（干净地）停止所有的进程？
这就是“ PID 1僵尸收割问题 ”，这就是为什么，无论何时你需要pipe理多个进程，像phusion/baseimage-docker这样的基本映像都可以提供帮助。
更普遍的问题是微服务的解耦：如果P1和P2都是有状态的并且相互依赖，那么保持它们在同一容器中是有意义的。
通信延迟方面的开销是多less？
这取决于所涉及的进程的types，但是由于这两个进程在同一个docker主机上运行（即使它们位于不同的容器中），开销也很小，
这也是一个缩放的问题。 如果你想自动缩放P1，假设P1的用法跨过某个门限（堆，吞吐量），用一个容器方法，你也可以复制P2，虽然这可能不是必需的。
因此，一个集装箱一个过程，规模更好，并提供细粒度的pipe理（协调）控制。
就延迟而言，它实际上取决于容器的部署体系结构。 如果两个容器都托pipe在同一台机器上，则延迟将变得微不足道，同时，如果他们在两个不同的AWS区域，则会开始产生影响。