在Bytecode Alliance成立一周年之际，WebAssembly 开发者 Lin Clark 和 Till Schneidereit 在博客中宣布，Fastly 已经从 Mozilla 手中收购了部分 WebAssembly 团队。在未来，Mozilla 将继续关注浏览器中的 WASM，尤其是 Firefox 浏览器。另一方面，Fastly 将管理服务器端的 WASM，包括 Fastly 自己的商业 WebAssembly 服务器产品 Compute@Edge。这也导致了 Mozilla 的 wasmtime 和 Fastly Lucet Wasm VM 项目的合并。Lucet 和 wasmtime 共享了很多代码，这次合并确保了它们未来的开发将继续沿着同样的方向进行。
在博文中，Clark 和 Schneidereit 描绘了他们对服务器端 WASM 未来的技术愿景。他们的核心观点是 nanoprocess 模型，它为 WASM 程序提供了一个安全且轻量级的容器，但仍然可以让沙箱内的 WASM 程序很容易与其他 WASM 程序及系统的其他部分通信。
从技术上讲，WASM 在通往nanoprocess的关键路径上有三个增强提议。
第一个增强是 WebAssembly Systems Interface(WASI)，它为 WASM 程序提供了一种调用宿主系统标准库函数的方法。在服务器端，也就是指访问文件系统、环境变量、随机数和套接字。现在，多个领先的 WASM 实现都支持 WASI。
WASI 的实现在完整性和性能方面各不相同。例如，谷歌的 V8 使用主机环境的 JavaScript 运行时作为访问操作系统的代理，因此速度很慢。
WASI 方法并不仅限于访问操作系统标准库。这篇博文还讨论了 Bytecode Alliance 倡导的其他类似 WASI 的扩展，比如wasi-socket和wasi-nn。除了 Bytecode Alliance 之外，还有很多项目可以让 WASM 访问更多的主机功能。例如，在区块链领域，以太坊 WebAssembly (Ewasm)也是 WASI 的一种形式，它可以让 WASM 访问主机以太坊区块链的用户帐户和交易服务。
第二个增强是接口类型，它可以让 WASM 程序与外部程序通信，无论是在主机操作系统中，还是内嵌了 WASM 的语言运行时(例如，Node.js)中。这个建议还处于早期阶段，还没有得到编译器工具链的支持。但是，wasmtime和Second State VM已经支持它。目标是让 WASM 程序更强大和具备更强的嵌入能力。
综合起来，WASI 和接口类型让开发人员可以充分利用原生主机系统，同时保持 WASM 沙箱的安全性。早期的一个例子是 Second State VM 为其 WASM 程序提供原生 GPU 访问能力来进行 tensorflow 模型推断。
nanoprocess 的第三个元素是模块链接，除了让 WASM 程序可以调用主机函数外，还可以相互调用。声明模块依赖关系的能力可以支持类似 Node.js NPM 和 Rust Crate.io这样的公共包管理系统，为已经启动的WAPM工作提供补充。
这篇博文参引用了 Bytecode Alliance 为服务器端的 WASM 设计的愿景。与此同时，WASM 开源社区现在比 Bytecode Alliance 要大得多。现在有多种 WASM 虚拟机实现、编程语言的编译器工具链以及主机操作系统和环境(例如，Node.js、Deno或区块链)。
原文链接：
Bytecode Alliance Lays out Plans for WebAssembly on the Server-side
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论