为什么需要Docker多架构（而不是Docker引擎抽象化的差异）？

简版

我想知道为什么需要为多个架构创建Docker镜像的技术原因。另外，不清楚这里的重点是为每个CPU架构创建镜像还是为一个OS创建镜像。OS不是应该抽象出架构吗？

我可以理解为什么Docker引擎必须移植到多种架构上。它是一个软件，它将与操作系统交互，进行系统调用，最终它只是代码，在一个特定的指令集中，在一个特定的架构下，被表示为一个指令序列。因此，Docker引擎必须被移植到多个OSarchitecture上，就像，让我们说，微软Word必须被移植一样。

同样的事情也会发生在--比方说--JVM，或者VirtualBox上。

但是，与Docker不同的是，在Windows上为JVM编写的软件可以在Linux上运行。JVM将抽象出底层OSarchitectures的差异，并在两个平台上运行相同的代码。

为什么Docker镜像不是这样呢？为什么Docker引擎不能抽象出差异，并提供一个通用的接口，这样镜像本身就不需要与特定的OSarchitecture兼容？

这是一个决定（就像 "让我们为每个架构制作不同的镜像，因为这对X原因更好"），还是Docker工作方式的结果（就像 "我们需要这样做，因为Docker需要Y"）？

我不是在喊 "哎呀，为什么？"。这不是在发牢骚，也不是在批评，我只是在寻找一个技术上的解释，不同架构需要不同的镜像。
我不是在问如何创建一个多架构的镜像。
我不是在寻找 "需要多架构镜像，这样你就可以在不同的平台上运行你的镜像 "这样的答案，它回答的是 "为什么？"，而不是 "为什么需要这样？"。(这是我的问题)。

除此之外，当你看到一个图像时，它通常有一个 os/arch 在文摘中，这样的。

图像的目标到底是什么？操作系统，架构，还是两者都有？OS不是应该抽象出底层架构吗？

编辑：我开始认为，每个架构需要不同的镜像是这样的：镜像里面会包含应用。比方说，它将包含Go编译器。Go编译器本身是一个二进制文件，它一定是被编译到不同的架构上的。镜像的 x86-64 将包含Go编译器，编译成 x86-64以此类推。这是否正确呢？如果正确，这是唯一的原因吗？

1
投票

为什么Docker Engine不能把差异抽象化，提供一个通用接口呢？

性能将是一个主要因素。考虑到Cygwin在Windows之上提供POSIX API时，通过模拟一些不直接映射到Windows API的POSIX事物，对一些事物的速度有多慢。 (例如 fork() exec分开，而不是CreateProcess）。)

而这仅仅是源头兼容性；所产生的二进制文件是特定于Windows上的Cygwin的，如果你想在运行时这样做（二进制兼容而不是源代码兼容），那就更糟糕了。如果你想在运行时做到这一点，那就更糟糕了（二进制兼容而不是源代码兼容）。

还有就是Docker需要在各种操作系统之上提供一个高效的可移植的JIT编译虚拟机，特别是跨各种CPU ISA，比如x86-64与AArch64，甚至不共享共同的机器代码，这就需要大量的复杂性。

如果Docker走这条路，其实只是重新发明了一个基于JVM或.NET CLR字节码的虚拟机。

或者更有可能的是，与其重新发明那个轮子，不如直接使用现有的虚拟机，并在此基础上添加镜像管理。但这样一来，它就无法与用C语言编写的本地程序一起工作，除非它将它们移植到Java或CLR字节码中。