WebAssembly 组件提供了一种在云原生环境中部署微服务和其他应用程序的新方法。这自然引发了一个问题：这个新兴组件是否会取代容器？或者，这是否意味着这些明显的竞争对手需要学习如何合作？
为了得到正确的答案，我们需要研究这两种技术之间的异同，然后考虑如何理解它们各自的用例------无论是独立使用还是协同工作。
然后，我们将探讨 WebAssembly（Wasm）如何将容器编排的边界扩展到多个云、边缘和设备。
但首先：什么是 WebAssembly 组件，它与容器有何不同？
1
什么是 WebAssembly 组件？
WebAssembly 是一种高效的字节码格式，它以虚拟指令集架构为目标。当你将所选语言的代码编译为 Wasm 二进制文件时，你可以在任何可以安装 WebAssembly 运行时（本质上是一个微型虚拟机）的地方运行这个精简的二进制文件。
WebAssembly 组件在核心 Wasm 格式上添加了一个标准化的规范层，使得二进制文件......
-
可互操作：组件可以通过与语言无关的接口从其他组件导入和导出函数 - 这意味着用 Rust 编写的组件可以调用用 Go 编写的组件中的函数。
-
可组合：两个或多个组件可以在构建时组合成一个组件。
-
可自省：当一个组件从另一个组件导入（即依赖）函数时，该依赖关系在二进制文件本身中定义，并且可以由系统或操作员进行自省。
与容器相比，一些主要区别立即显现出来：
-
可移植性：单个组件可以在任何支持该组件规范的 WebAssembly 运行时（例如 Wasmtime）上运行。您无需为每个操作系统和架构分别构建一个组件。单个工件即可在任何地方运行。
-
大小：WebAssembly 二进制文件很小 - 通常从千字节到兆字节不等 - 因此可以在给定的硬件上打包更多的工作负载。
-
通信：在编排部署中，容器跨越网络边界进行通信，而这些网络通信通常是规模化部署的主要开销来源。在任何支持组件的 Wasm 系统中，紧密耦合的组件都可以组合在一起；而在 wasmCloud 中，分布式组件可以通过动态运行时链接进行通信。
从高层次来看，也许最重要的区别是组件单独抽象了应用程序逻辑。
即使是最精简的无发行版基础镜像也只包含位于应用程序和内核之间的极少量库，而容器镜像通常包含更多库和实用程序。例如，当你想在开发容器中启动一个标准的开发环境时，这非常有用。这种用例非常适合容器，而对于如今的组件来说则毫无意义。容器非常适合可移植、隔离、可复制的环境。
相比之下，组件是应用程序的正确抽象级别。
2
抽象时代
您可以将软件部署的时间线视为逐步抽象的时代。
我们从紧密耦合的单体系统开始。虚拟机将操作系统与特定硬件解耦，减少了对数据中心的依赖。容器作为下一个抽象层级应运而生，容器编排器帮助应用程序更灵活、更高效地运行。
下一层抽象是 WebAssembly 组件，它将应用程序视为可互换组件的集合，并在运行时链接起来。使用组件构建的应用程序体积小巧、可移植且支持多种语言。
与虚拟机相比，容器在效率方面有所提升，但在大规模和边缘编排容器方面也存在一些明显的限制。
3
协调效率
Kubernetes 使得大规模迁移到云端成为可能，并且对于抽象基础设施至关重要，但它对于运行应用程序来说并不理想，除非你付出大量额外的工作。在 Kubernetes 上运行容器化应用程序的传统方法面临一些重大限制：
-
边缘部署：即使使用轻量级发行版，使用 Kubernetes 在边缘运行容器也极具挑战性。最小的容器也只有几 MB，因此仅仅让 Kubernetes 运行起来就会占用大量可用资源。
-
资源效率与冷启动问题的代价：超过 80% 的容器支出用于闲置基础设施。容器化应用程序需要容器持续运行，以应对流量高峰，并满足标准的延迟预期。统计数据显示，保持"以防万一"实例的运行成本高昂。
-
由于组件能够在几毫秒内启动，因此它们不会面临这样的挑战。人们想要运行组件的首要原因（也可能是最常见的原因）是，它们能够显著提高依赖 Kubernetes 的资源效率。借助组件，团队可以使用自己选择的语言编写代码，并在任何地方运行，即使在容器不适用的地方也是如此。
如果组织已经在使用 Kubernetes，则可以轻松地使用 wasmCloud 在现有集群上运行组件。wasmCloud 是一个 WebAssembly 编排器，可以独立运行或在 Kubernetes 本身上大规模运行分布式 Wasm 应用程序。
事实上，wasmCloud 可以帮助扩展 Kubernetes 以应对多云和边缘等传统挑战领域。
4
WebAssembly + Kubernetes：云原生的新组合
在早期的 wasmCloud 用例中，Adobe 利用 wasmCloud 证明了它可以提高其 Kubernetes 资源的效率。该公司持续扩展 Wasm 的使用范围：Adobe 和 Akamai 的工程师与 wasmCloud 合作，在云服务、Kubernetes 集群和边缘计算上运行 WebAssembly。
在工业领域，MachineMetrics 使用 wasmCloud 实现平台功能在边缘和云端的动态容错迁移。在电信领域，WebAssembly Canvas™ 论坛催化剂项目已证明，在管理其开放 API 资源方面，用 wasmCloud 取代 Kubernetes 具有重要价值，目前正在研究如何将 wasmCloud 与 Kubernetes 协同工作，从而提高效率。
wasmCloud 主机可以在 Kubernetes 集群内部或集群外部运行：裸机、虚拟机、物联网设备，或者几乎任何您想要的地方。无论主机在哪里运行，都可以连接。Kubernetes 通过编排 wasmCloud 主机来处理基础设施管理，而 wasmCloud 则处理应用程序级操作，并全面支持组件功能。
这种关注点分离------用于基础设施的容器和 Kubernetes、用于应用程序的组件和 wasmCloud------意味着 WebAssembly 运行时操作不受以容器为中心的框架和抽象的限制；wasmCloud 可以扩展 Kubernetes 以提供新的混合计算选项并扩展计算的边界。
这正是 Wasm 颠覆范式的超能力发挥作用的地方。使用 Wasm 开发应用程序可以大幅节省成本，而采用 wasmCloud，我们可以避免被专有系统锁定，工程师可以使用他们现有的云原生基础设施，并且可以利用 WebAssembly 组件模型最强大、最独特的特性------可组合性和基于标准的互操作性------进行构建。总而言之，容器和组件并非竞争对手，而是一支强大而灵活的团队，共同应对基础设施效率低下的问题。
随手关注或者"在看"，诚挚感谢！