基于 Node.js 的分布式系统

第 5 章 容器 集装箱

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

程序通常不会在一个文件中捆绑所需的所有内容。这不仅适用于 Node.js 程序（至少包括一个.js文件和node可执行文件），也适用于使用其他平台编译的程序。几乎总会涉及其他要求，如共享库。即使是用 C 语言编写的单个可执行二进制文件，如果静态链接其依赖项，在技术上仍然依赖于内核提供的系统调用 API。

程序分发和执行的方式有很多种。每种方式都要在可移植性、效率、安全性和脆性方面进行权衡。

有时，"只发布一个二进制文件 "是件好事。但这至少意味着要为不同的操作系统提供不同的二进制文件，有时（如二进制文件依赖于 OpenSSL 时）还需要根据操作系统和库版本提供多个二进制文件。这就是可移植性问题。

共享库是最大的问题之一。考虑一台运行 Linux 操作系统的服务器。然而，一个版本依赖于 ImageMagick v7，而另一个版本依赖于ImageMagick v5。现在，安装 ImageMagick 共享库不再是一项简单的任务，而是一项隔离不同版本库的杂耍。这种情况非常脆弱。

运行多个程序时可能会出现其他问题。也许两个程序需要在文件系统中维护一个锁文件，而路径是硬编码的。或者，程序想监听同一个端口。或者，其中一个程序受到攻击，攻击者可能会利用它来干扰另一个程序，这也是一个安全问题。

虚拟机（VM）的出现解决了许多此类问题。虚拟机可以在主机操作系统中模拟计算机硬件，访问独立的内存子集和磁盘空间。安装在虚拟机中的操作系统可以运行与主机操作系统完全隔离的程序。这是一个非常强大的概念，至今仍极为重要。不过，它也有一个缺点，那就是每个运行中的虚拟机都需要一个完整的操作系统副本。这也意味着新部署的虚拟机需要花时间启动客户操作系统。这种开销可能会让每个程序专用一个虚拟机的成本过高，这也是一个效率问题。

容器是描述程序需求并将其捆绑到可分发软件包中的一种方式。这包括私有文件系统的内容和其中的共享库、隔离的 PID 列表和隔离的端口，这些端口可以被监听，而不会有与其他容器冲突的风险，所有这些都不允许访问其他容器专用的内存。容器中唯一没有捆绑的是操作系统本身--相反，容器依赖于主机操作系统（或者更确切地说，是主机操作系统的内核）。容器内的系统调用在提供给主机操作系统之前，会经过一些轻量级的转换。

图 5-1比较了三种程序隔离方法。第一种方法，我称之为经典方法，它依赖于直接在硬件上运行的操作系统上运行程序。在这种情况下，可能会出现复杂的共享库杂耍行为。部署新程序时可能需要系统管理员，或者一个组织可能需要同意在所有地方使用完全相同的依赖关系。不过，这种方法的开销最小。第二种方法是虚拟机，它传达了操作系统内核的冗余副本，可能是针对每个程序的（尽管多个程序经常在同一个虚拟机中运行）。虚拟机术语将父操作系统称为主机操作系统，，将子操作系统称为客户操作系统。第三种方法是容器，它展示了容器抽象如何重复使用内核，但共享库很可能是多余的。它还说明了使用较小容器的必要性。

最理想的情况是，不管程序有什么依赖关系，它都能非常迅速地部署到某个位置，然后在那里消耗 CPU 和 RAM，并回复网络请求。一旦不再需要这个程序，它就能被迅速删除，而不会留下任何麻烦。

备注

现代技术堆栈应至少利用其中两种方法。容器非常适合部署无状态的第一方程序，这些程序会频繁更新和部署，并可上下伸缩，而有状态数据库直接运行在操作系统（虚拟或其他）上，会受益更多。

图 5-1. ...