eBPF WebAssembly 于 Rust

[jingslunt]

本文又名：学习 Rust 的第 1001 个理由

在当今的云原生世界中，有两个轻量级代码执行沙箱 /虚拟机非常火热：eBPF 和 WebAssembly 。二者都能够运行由 C 、C++ 和 Rust 编译而来的高性能字节码程序。

然而，最大的区别在于 eBPF 在 Linux 内核中运行，而 WebAssembly 在用户空间中运行。eBPF 有一些编程限制，使其在内核应用场景中是安全的（例如，没有无限循环）。但这也意味着 eBPF 不是是图灵完备的。相比之下，WebAssembly 是一种图灵完备的语言，具有能够打破沙盒和访问原生 OS 库的扩展。

一般来说，eBPF 适用于网络或安全相关的任务，而 WebAssembly 则非常适用于商业应用。但其中有重叠。

首先，有一些在 Linux 内核中运行 WebAssembly 的尝试。然而，基本上不太成功。eBPF 是这个应用场景下更好的选择。

然而，WebAssembly 程序可以处理许多类内核的任务。WebAssembly 可以被 AOT 编译成原生应用程序。来自 CNCF 的 WasmEdge Runtime 是一个很好的基于 LLVM 的云原生 WebAssembly 编译器。原生应用程序将所有沙箱检查合并到原生库中，这允许 WebAssembly 程序表现得像一个独立的 unikernel “库操作系统”。

此外，这种 AOT 编译的沙盒 WebAssembly 应用程序可以在微内核操作系统（如 seL4 ）上运行，并且可以接管许多“内核级”任务。

虽然 WebAssembly 可以下降到内核级别，但 eBPF 也可以上升到应用程序级别。例如，服务网格代理通常支持 WebAssembly 作为一种扩展机制。由于这些代理基本上是网络应用程序，因此可以在 eBPF 中编写一些扩展，以在不影响安全性和可扩展性的情况下获得更高的性能和可扩展性。

在服务网格应用场景中，WebAssembly 非常适合 sidecar 微服务应用程序，而 eBPF 适合通过代理路由 API 流量并监控整个应用程序。

eBPF 和 WebAssembly 的兴起对开发者而言是个好消息。我们有了更多的工具来管理和编程日益复杂的基础设施。Rust 已成为这两种虚拟机的领先编程语言，因为它性能强大，并且可以由 LLVM 编译为机器代码，而无需额外的 runtime 支持。

所以最终，开发者只需要关心 Rust API ，将 Rust 程序按照部署需要编译成 eBPF 和 WebAssembly 即可。Rust 是正解。