原文 | Richard Lander
翻译 | 郑子铭
轻量级功能
嗯……但是如果我们使用 Wasm 更像是一个典型的功能而不是一个应用程序，我们可能不会计算一百万个单词，而是做一些更轻量级的事情。让我们重新运行比较，但使用最小的文件。
通过 Wasm，使用我们的解释器：
$ time WASMTIME_NEW_CLI=0 wasmtime run --mapdir /text::/home/rich/git/convenience/wordcount count.wasm $* /text/Clarissa_Harlowe/summary.md9 153 1044 /text/Clarissa_Harlowe/summary.md
Elapsed time (ms): 21
Elapsed time (us): 21020.8real 0m0.098s
user 0m0.083s
sys 0m0.014s
使用 Wasm 和原生 AOT：
$ time WASMTIME_NEW_CLI=0 wasmtime run --mapdir /text::/home/rich/git/convenience/wordcount count.wasm $* /text/Clarissa_Harlowe/summary.md9 153 1044 /text/Clarissa_Harlowe/summary.md
Elapsed time (ms): 0
Elapsed time (us): 825.3real 0m0.048s
user 0m0.035s
sys 0m0.014s
再次，使用 CoreCLR：
$ time ./app/count ../Clarissa_Harlowe/summary.md 9 153 1044 ../Clarissa_Harlowe/summary.md
Elapsed time (ms): 16
Elapsed time (us): 16100real 0m0.063s
user 0m0.027s
sys 0m0.019s
此图表显示了上下文中的所有结果，这次是针对较小的文档。
有趣的。对于较小的工作负载，其中一些选项之间的性能差异开始缩小。我们还可以看到运行时启动成本的差异。现在说还为时过早，但这些动态可能是这项技术的关键考虑因素。一个重要的警告是，字数统计只是一种情况，其他情况可能会产生完全不同的结果。目前，该示例已经提供了足够的预期内容。
这一切都还处于早期阶段。随着我们走得更远，我们将想要测试更有趣的场景，以形成更具代表性的理解。我也确信其中一些性能数字将会提高。
功能上略有改进
WASI 的承诺是能够依赖一组具有丰富功能的接口（和匹配的实现）。 SpiderLighting 兑现了这一承诺。
SpiderLightning：一组 WIT 接口，抽象分布式应用程序功能和运行时 CLI，用于运行使用这些功能的 Wasm 应用程序。
如前所述，WASI 旨在定义与 System 命名空间相同的平台功能（但只是其中的一小部分）。您可以在 SpiderLighting wit 目录中看到该接口的接口定义（至少一种版本）。
如果你有智慧，那就发挥你的智慧
您应该能够走到任何 WIT 界面，引用它，查看其完整的类型形状，并开始使用它进行编码。我们距离最终体验还有几步之遥，但这就是愿景。
SpiderLighting 提供了一个名为 slim 的便捷 CLI 工具，它可以连接 wasmtime、您的应用程序、WASI SDK 以及您的应用程序所需的任何 WIT 实现（如在 slimfile.toml 中声明的那样）。
SpiderLighting 团队告诉我们，他们构建了 slim（及相关组件）作为工具来帮助他们开发 wasi-cloud-core 规范，以实现无服务器功能。在不久的将来，我们预计其他应用程序主机（例如 Fermyon Spin）将使用 wasi-cloud-core 接口，然后我们将使用其中一台主机，而不是轻微的。
我们有一组 Spiderlight 样本。以下示例创建 WASI 键值存储，然后打印到控制台。请注意，dotnet run 使用 light 作为实现细节。
using SpiderLightning;using var keyValue = new KeyValue("placeholder-name");
keyValue.Set("somekey", "Hello from .NET. This value is from a SpiderLightning key-value store.");Console.WriteLine(keyValue.GetString("somekey"));
请记住，KeyValue 不是 C# 类型，而是投射到 C# 中的 WASI 接口。
这是代码运行时的样子。
$ pwd
/home/rich/git/spiderlightning-dotnet
$ docker run --rm -it -v $(pwd):/source -w /source/sample/ConsoleApp wasi-sdk dotnet run -c Release
Hello from .NET. This value is from a SpiderLightning key-value store.
我正在一个安装了所有必需依赖项的容器中运行该应用程序。容器和WASI可以一起使用吗？一定。
您可以在有限的环境中构建依赖 WASI SDK 的应用程序，并在更大的环境中运行它们。 Windows 和 macOS Arm64 的支持似乎最差。随着时间的推移，这肯定会改变。
网页场景
对 WASI 的很多兴趣在于能够托管小型且便携式的 Wasm 功能和应用程序。其中一个关键方面是使用某种形式的网络编程模型。目前，我们还没有启用 WASI 的 ASP.NET Core。目前，我们已经公开了 http-server WASI 类型。
它启用以下模式。
HttpServer.OnIncomingRequest(request =>
{return new HttpResponse(200).WithBody($"<h1>Hello!</h1> You did a {request.Method} request to {request.Uri} with {request.Headers.Count} headers").WithHeaders(new[] { KeyValuePair.Create("content-type", "text/html") });
});
这有点低级了。委托也不是异步友好的。以下是异步最终如何工作的一些提示。
我尝试用这个 API 编写一个更大的示例。它目前被阻止，因为我们没有办法调用 https 端点。我可以通过在本地复制所有必需的 JSON 文件来解决这个问题，但不会那么引人注目。
这个领域是最有趣的，但也是定义最少的。我们预计至少还需要一年的时间才能运行我们所认为的真正的网络应用程序和功能。我们的目标是建立一个模型，您无需更改太多代码即可使用 Wasm 作为部署目标。
实验
WASI 工作负载目前处于实验阶段，因此得名工作负载。至少在 WASI 本身发布稳定的 1.0 版本之前，它仍将是一个实验。我们无法确切地预测那会是什么时候。
有几个待办事项需要调查和解决：
- 综合调试
- 支持AOT
- dotnet 使用 wasmtime CLI 参数运行
- 支持更多 WASI 接口，可能通过更好的 witbindgen 支持
闭幕式
更高层次的故事是，我们已经能够使我们的 Blazor Wasm 实现（实际上是整个 .NET）适应便携式计算的新领域。正如这几个演示所证明的那样，很多功能已经发挥作用。
您可以使用 .NET 8 尝试在本文中阅读的所有内容（以及更多内容）。从以下命令开始，安装所需的软件。
dotnet workload install wasi-experimental
在接下来的一年里，我们将专注于提高当前实施的功能和用户体验，并跟随 WASI 的总体发展。我们还期待观察云团队如何在其服务中采用 WASI。迄今为止，我们一直在构建支持技术。随着我们的进一步发展，我们将考虑专注于与云服务相结合的更多定位体验。就目前而言，这一切都是面向未来的，就像 WASI 的其他部分一样。
简洁是智慧的灵魂。 - 威廉·莎士比亚
如果你读到这里，你就会明白，如果我说得简短一点，你就不会那么了解情况了。但鉴于这篇文章的篇幅和细节，我已经无计可施了。
原文链接
Extending WebAssembly to the Cloud with .NET
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。
如有任何疑问，请与我联系 (MingsonZheng@outlook.com)
