Docker 与虚拟机到底有什么本质区别？场景选择与最佳实践

上篇我们深入讲解了 Docker 的核心原理Docker 核心原理详解镜像、容器、Namespace、Cgroups 与 UnionFS本篇重点对比 Docker 与虚拟机的差异。虚拟机的运行方式为了清晰地理解 Docker需要将其与传统的虚拟机Virtual Machine进行对比。虚拟机是一种完全的硬件级虚拟化技术。在一台物理服务器上运行虚拟机首先需要安装一个虚拟机监视器软件Hypervisor。Hypervisor 的作用是模拟出完整的计算机硬件环境包括虚拟的 CPU、内存、硬盘、网卡等。常见的 Hypervisor 有 VMware ESXi、KVM、Hyper-V 等。在这些模拟出来的虚拟硬件之上需要安装完整的操作系统这个操作系统被称为 Guest OS。每个虚拟机都有自己独立运行的内核。要在虚拟机中运行应用程序需要经历以下步骤启动物理机 - 启动 Hypervisor - 启动 Guest OS - Guest OS 加载内核和系统进程 - 启动应用程序。在这个架构中物理机的操作系统Host OS与虚拟机内部的操作系统Guest OS是完全分离的虚拟机内部的应用程序必须通过 Guest OS 的内核来调度虚拟硬件资源然后再由 Hypervisor 将虚拟硬件的指令翻译并传递给真实的物理硬件。Docker 与虚拟机的具体差异虽然 Docker 容器和虚拟机都在提供隔离的运行环境但它们在架构层面和实际表现上有根本的不同。操作系统的架构差异虚拟机包含完整的 Guest OS 和内核。如果物理服务器运行的是 Linux 操作系统你在其上启动一个 Ubuntu 虚拟机虚拟机内部会运行一个完整的 Ubuntu Linux 内核。如果你启动一个 Windows 虚拟机内部运行的是完整的 Windows NT 内核。Docker 容器没有自己的内核。所有的容器都直接共享宿主机Host OS的操作系统内核。容器内的应用程序产生系统调用时是直接传递给宿主机内核执行的中间没有任何硬件模拟或额外的指令翻译层。启动速度的差异虚拟机的启动等同于开启一台真实的计算机。它需要经历 BIOS 引导、内核加载、文件系统挂载、各类系统后台服务如网络服务、日志服务启动等漫长的过程。这个过程通常需要一分钟到几分钟的时间。Docker 容器的本质是宿主机上的一个进程。启动一个容器实际上就是使用 Namespace 和 Cgroups 参数启动一个被隔离的普通进程。它不需要引导系统内核也不需要启动无关的系统服务。因此容器的启动速度极快通常只需要毫秒级或秒级的时间。一旦进程启动完毕容器就处于运行状态。资源占用与消耗差异虚拟机的资源占用是非常庞大的。由于包含完整的 Guest OS即便虚拟机内没有任何业务程序运行操作系统内核及其基础服务也会占用大量的 CPU 周期和固定的物理内存通常是几百兆到数个 G。此外Hypervisor 预先分配给虚拟机的内存是独占的即使虚拟机内部没有用满物理机也无法将这部分空闲内存分配给其他任务。Docker 容器属于轻量级虚拟化。容器本身几乎不产生额外的基础资源消耗。容器占用的内存主要就是其内部运行的业务进程实际使用的内存。在分配资源时Docker 默认采用弹性的按需分配模式。即使一台配置有限的服务器只要内存总量足够分配给各个实际进程就可以同时运行成百上千个容器而如果运行相同数量的虚拟机服务器的内存早被数十个操作系统的基础开销耗尽。隔离性与安全性的差异虚拟机提供的是硬件级别的强隔离。不同虚拟机拥有独立的内核。如果一个虚拟机内部的系统崩溃例如发生内核级错误引发 Kernel Panic或者被黑客利用内核漏洞攻破并获取了 root 权限影响范围仅局限于该虚拟机内部。宿主机上的其他虚拟机和物理环境不会受到牵连。Docker 容器提供的是进程级别的隔离所有的容器共享宿主机内核。这意味着容器的隔离级别弱于虚拟机。如果宿主机内核存在漏洞或者容器内的进程获得了特权级访问攻击者有可能突破 Namespace 的限制直接访问宿主机的核心资源甚至控制整个物理机。这就是常说的“容器逃逸”。因此在多租户环境或者对安全要求极高的场景中纯粹的 Docker 容器在安全性上不如虚拟机可靠。但通过非 root 运行、扫描镜像、最小化基础镜像等可以减小“容器逃逸”的风险。存储体积的差异虚拟机的镜像通常包含了一个操作系统所需的所有二进制文件和系统数据体积巨大动辄几 GB 甚至几十 GB。其分发和传输需要占用大量的网络带宽。Docker 镜像仅包含应用程序本身及其直接依赖的系统库和运行环境体积小得多通常在几十 MB 到几百 MB 之间。配合联合文件系统的分层共享机制多次拉取不同镜像时的网络开销可以进一步降低。跨平台内核限制问题了解了 Docker 共享内核的原理后就能解释在实际使用中经常遇到的跨平台问题。很多人有一个疑问既然 Docker 镜像是跨平台的为什么有时候在某些系统上运行会失败这涉及到容器内的程序指令最终由哪个内核执行的问题。由于 Docker 容器没有内核它依赖宿主机的内核。因此Linux 环境下的 Docker 只能运行包含 Linux 程序的容器。如果你试图在一个原生的 Linux 服务器上运行一个打包了 Windows 程序的 Docker 镜像系统会报错因为 Linux 内核无法解析和执行 Windows 特有的系统调用如 Windows API。反过来很多开发人员在 Windows 操作系统的个人电脑上安装 Docker Desktop并成功运行了 Linux 镜像如 Nginx、Redis。这似乎打破了“共享内核”的限制。实际上这是因为 Docker Desktop 在 Windows 上并非直接使用 Windows 内核运行 Linux 容器。Docker Desktop 在后台自动利用了 Windows 的 WSL2Windows Subsystem for Linux 2首先在 Windows 内部启动了一个极轻量级的 Linux 虚拟机。然后在这个后台的 Linux 虚拟机中运行 Docker 引擎从而提供了 Linux 内核来支撑 Linux 容器的运行。在 macOS 上运行 Docker 也是同理macOS 并没有 Linux 内核Docker Desktop for Mac 同样是在底层运行了一个轻量级的 Linux 虚拟机来支持容器工作。因此容器内的应用程序与宿主机内核必须保持架构和系统调用层面的一致性。虽然现在有模拟器技术可以实现跨架构运行但会有严重的性能损耗。实际工作中的选择建议明确了 Docker 和虚拟机的各项原理差异后在后端的架构设计和日常运维中就可以根据实际需求选择合适的技术方案。虚拟机由于其较重的资源开销和较慢的启动速度不再适合作为微服务架构中单个服务实例的部署载体。虚拟机更适合以下场景基础设施层面公有云提供商通常使用虚拟机为不同租户划分基础计算资源例如购买的云服务器 ECS 就是一台虚拟机以确保租户之间的绝对隔离和安全。多操作系统需求需要在一台物理机上同时运行完全不同的操作系统例如同时运行 Linux 和 Windows 服务器或者需要运行依赖特定内核版本的遗留系统。强安全隔离场景业务中存在未经验证的第三方代码执行或者对系统权限要求极高不能承担任何因内核共享导致的安全越权风险。Docker 由于其极其轻量、启动迅速、环境一致性强的特点成为现代应用交付的首选。它特别适合以下场景微服务架构部署一个庞大的系统被拆分成几十个微服务每个微服务打包成独立的容器运行互不干扰且可以根据负载情况实现秒级的横向扩容或缩容。持续集成与持续部署CI/CD开发人员提交代码后自动化流水线直接构建镜像并推送到仓库测试环境和生产环境拉取相同的镜像运行。这种标准化的流程消除了环境配置带来的故障。本地开发环境统一新入职的后端开发人员无需在本地安装配置各种数据库、消息中间件和特定的语言运行环境。只需编写一个docker-compose.yml文件执行一条命令所有依赖的后端服务就会以容器的形式在本地瞬间启动确保了整个团队开发环境的一致性。高密度的资源利用在相同的物理硬件上相较于部署少量几个消耗巨大的虚拟机部署数百个轻量级的 Docker 容器能够极大地提升服务器资源的整体利用率。总结来说Docker 并不是用来替代虚拟机的两者在物理架构上处于不同的层级。虚拟机解决的是底层物理硬件资源的切分和系统级环境分配问题而 Docker 容器解决的是操作系统之上应用程序的打包、分发、隔离和生命周期管理问题。在当前的主流架构中两者通常是结合使用的物理机上运行 Hypervisor 切分出多台虚拟机然后在这多台虚拟机的操作系统内部安装 Docker 引擎来运行各种业务容器。这样既保证了基础设施的安全性与灵活性又发挥了容器化技术带来的应用交付与环境一致性优势。