几周前我有一个“哦，啊哈，当然”的时刻，我想分享：WebAssembly是下一个Kubernetes吗？Kubernetes就在这里Kubernetes承诺提供一个软件虚拟化基础，让您一次解决许多问题问题：Kubernetes允许您比在裸机上运行服务更有效地使用硬件。Kubernetes允许您在单个硬件服务器上运行多个容器，并允许您根据需要向集群添加更多服务器。“容器云”架构有效地划分了构建服务器端应用程序的工作。数据库团队可以发布数据库容器，后端团队可以发布Java容器，产品经理使用网络作为公共中间层将它们连接在一起。它遵循康威定律：软件看起来像组织结构图。容器抽象足够通用以支持许多不同类型的服务。Go、Java、C++等等——它不是特定于语言的。开发团队可以使用他们喜欢的东西。负责运行容器的Kubernetes服务器的运营团队不必信任他们运行的容器，他们内置了一些沙盒和保护措施。Kubernetes本身是以前架构OpenStack的演变。OpenStack使每个容器成为一个完整的虚拟机，具有完整的内核和操作系统以及一切。相比之下，Kubernetes通常使用容器，其中通常不需要内核。它们更轻量级——想想Docker和VirtualBox。在Kubernetes部署中，内核仍然是软件架构的中心。容器化的基本机制是具有私有命名空间的Linux内核进程。这些容器然后通过TCP和UDP套接字粘合在一起。然而，虽然每个容器有一个或多个内核进程确实比一个完整的虚拟机更好地扩展，但它通常不会扩展到数百万个容器。进程确实有一些启动时间——您不能为每个高性能Web服务请求启动一个容器。这些技术限制导致某些类型的系统架构，通常具有保持特定状态的长寿命组件。k8s会进化到w9y吗？服务器端WebAssembly与Kubernetes处于类似的空间——或者更确切地说，WebAssembly类似于进程和私有命名空间。WebAssembly为您提供了很好的抽象障碍和（可以提供）高安全隔离。在某些方面，它甚至更好，因为WebAssembly提供了“白名单”安全性——它没有能力开始要求运行WebAssembly的“主机”将其某些功能显式委托给访客WebAssembly模块。将其与默认情况下从每个功能开始然后必须受到限制的流程进行比较。与Kubernetes一样，WebAssembly也为您提供康威定律系统。您无需运送容器，而是运送WebAssembly模块——以及一些元数据（“导入”），了解他们需要从环境中获取哪些类型的东西。WebAssembly是通用的——它是一个低级虚拟机，任何东西都可以编译进去。然而，在WebAssembly中你得到的更多。一是快速启动，因为内存就是数据，所以你可以安排创建一个WebAssembly模块，它的状态从内存中的一个预先初始化的状态开始。这样的模块可以在几微秒内启动——足够快，可以根据每个请求创建一个，在某些情况下，之后就丢弃状态。您可以在WebAssembly上比在容器上更高效地运行功能即服务架构。另一个是虚拟化完全在用户空间中提供。一个进程可以在许多不同的WebAssembly模块中复用。这允许一台服务器做更多的事情。此外，您不需要使用网络来连接WebAssembly组件；他们可以在内存中传输数据，有时无需复制。题外话：WebAssembly的这种轻量级进程特性也支持其他架构，例如这个有趣的hack将链接到Firefox的库沙箱化，他们实际上发布了！我将WebAssembly与Kubernetes进行比较，但实际上它更像是进程和私有命名空间。所以对最初提出的问题的一个答案是，不，WebAssembly不是下一个Kubernetes。下一个项目正在等待构建，尽管我知道一些团队已经开始了。不过，有一件事对我来说似乎很清楚：WebAssembly将处于新事物的底部，因此WebAssembly的近期轨迹可能会跟随Kubernetes的轨迹，这意味着......分析师的庆祝时间！Gartner魔力象限再次回归，IBM推出了一个新的WebAssembly部门Accenture，开始向公司询问他们的WebAssembly迁移计划、Linux基金会、早期采用者等。我将在不久的将来看到汹涌的水域。所以从这个意义上来说，Kubernetes本质上不是一个技术软件，而是一个泡沫商业竞争的纽带，当然：我们还有5年左右的时间，我们会很高兴。读者评论：2021年12月的WebAssembly让我想起了2014年容器/Kubernetes的情况——业界已经意识到目前的技术状态并不能解决今天的所有问题。跨边缘/服务器/浏览器的可移植性、可移植的安全模型以及业务逻辑和库之间的紧密耦合意味着企业构建/管理/运行多个版本的应用程序。像wasmCloud这样的技术是未来，在我看来，未来几年会有更好的故事。
