译者：松宝写代码
译文：https://bytecodealliance.org/...
概要
美东时间 9 月 20 日，Bytecode Alliance 宣布经过三年开发，正式迎来 Wasmtime 1.0 版本。Wasmtime 是创建在编译器 Cranelift 之上的 WebAssembly Runtime。Wasmtime 利用 Rust 编程语言，完全开源并符合 WASI。Wasmtime 还支持与 C/C++、Python、.NET、Go 等语言集成，同时运行在 Windows/Linux/macOS 等平台上。
前言
截至今天，Wasmtime WebAssembly运行时现在是1.0！这意味着我们字节码联盟中的所有人都同意它已完全准备好在生产中使用。
事实上，我们可以称Wasmtime为生产就绪一年多以前.但是我们不想只发布任何WebAssembly引擎。我们想要一个超级快速和超级安全的WebAssembly引擎。当我们建议人们选择Wasmtime时，我们想感到非常自信。
因此，为了确保它为你们所有人做好生产准备，我们字节码联盟中的一些人在过去的一年里一直在自己的生产中运行Wasmtime。Wasmtime在这些生产环境中做得很好，提供了一个稳定的平台，同时也给我们带来了安全性和速度优势。
以下是我们使用新的、改进的Wasmtime的一些经验：
Shopify-生产14个月
Shopify于2021年7月从另一个WebAssembly引擎切换到Wasmtime。通过切换，Shopify看到了一个平均执行性能提高约50%。
很快-生产6个月
2022年3月，法斯特从另一个WebAssembly引擎切换到Wasmtime。法斯特还看到了一个~执行时间提高50%.此外，法斯特看到了一个每秒请求数增加72%至163%它可以起作用。很快就起作用了。数万亿个请求使用Wasmtime。
DFINITY-生产16个月
DFINITY于2021年5月使用Wasmtime推出了互联网计算机区块链。从那时起，互联网计算机已经执行100京（10^18）超过150,000个智能合约的说明没有任何生产问题。
InfinyOn-生产14个月
InfinyOn Cloud自2021年7月以来一直在生产中使用Wasmtime。有了Wasmtime，英飞凌能够提供大于端到端流处理的吞吐量提高5倍与Kafka等基于Java的平台相比。
Fermyon-生产6个月
Fermyon的Spin自2022年3月发布以来一直在使用Wasmtime。从那时起，Fermyon发现成千上万的WebAssembly二进制文件可以在一个Spin实例中运行，同时将启动时间保持在一毫秒以下。
上船-生产2年
自2020年以来，Embark一直在他们的游戏引擎中使用Wasmtime。从那以后，Embark对Wasmtime卓越的稳定性、安全性和性能印象深刻，保持游戏以60 FPS运行。
SingleStore-生产3个月
SingleStoreDB Cloud自2022年6月以来一直在使用Wasmtime将开发人员的代码安全、快速、大规模地带入数据。
微软-预览11个月
自2021年10月以来，微软在Azure库伯内特斯服务中预览了Wasmtime的WebAssembly系统接口（WASI）节点池。
凭借所有这些在生产中运行它的经验，我们相信我们也可以向您推荐它。
所以我想告诉你我们是如何让它变得超级快速和超级安全的。但是首先，你为什么要首先使用WebAssembly运行时？
为什么要使用WebAssembly运行时？
WebAssembly最初是为了让代码在浏览器中快速运行而创建的。这意味着您可以在浏览器中运行更复杂的应用程序，如图像编辑应用程序或视频游戏。因此，每个主要浏览器都有自己的WebAssembly运行时来运行这些类型的应用程序。
但是WebAssembly也在浏览器之外打开了许多用例。因此，在这些情况下，您需要找到一个独立的WebAssembly运行时，例如Wasmtime。
以下是我们看到人们使用Wasmtime的一些用例。
Microservices和serverless
像Wasmtime这样的WebAssembly运行时非常适合Microservices和serverless平台，在这些平台上，您有需要快速扩展和缩减的独立代码片段。这是因为WebAssembly的启动时间比其他类似技术（如JS隔离、容器或虚拟机）低得多。
例如，最快的替代方案——JS隔离——大约需要5毫秒才能启动。相比之下，Wsom实例只需要5微秒就能启动。
WebAssembly的轻量级隔离非常适合多租户平台，因为与虚拟机、容器或其他粗粒度隔离技术相比，您可以在同一台机器上容纳更多的工作负载。
第三方插件系统
WebAssembly非常适合平台，在平台上，您经常希望运行第三方代码，这样您就可以支持许多不同的特定用例——例如，通过插件市场，平台生态系统中的开发人员可以与用户共享代码。
但是运行它会带来一个信任问题——平台能信任这些生态系统开发人员编写的代码吗？
使用WebAssembly，平台可以运行不受信任的代码，但仍然有一些安全保证。由于WebAssembly默认是沙盒的，并且不能访问您没有明确交给它的任何资源，因此平台不会面临风险。平台和插件之间的通信仍然很快。
数据库、分析和事件流
对于数据库支持的应用程序，WebAssembly确实可以加快速度。数据库支持的应用程序通常会浪费大量时间重复查询数据库，根据返回的数据执行一些计算，然后发出更多查询来获取更多数据。加快这种通信的一种方法是使用用户定义函数（UDF）将代码带到数据中。有了这些，您可以直接在数据库中运行代码，摆脱它们之间的网络调用。
在WebAssembly运行时的帮助下，数据库可以使用基于WebAssembly的UDF来共同定位代码和数据。这提供了对数据的快速计算，而不会使数据库本身面临安全风险。
因为它是WebAssembly，这些数据库可以安全地在它们的UDF中支持许多不同的语言，而不会有一个UDF崩溃并导致整个数据库瘫痪的风险。这使得UDF对于不太熟悉特定数据库的用户来说更加容易接近。
可信的执行环境
可信执行环境（TEE）是为用户不能或不想信任系统的较低级别（如管理程序、内核或其他系统软件）的情况而设计的。TEE在CPU上提供了一个安全区域，TEE托管的代码在该区域运行，与所有其他软件隔离。
WebAssembly非常适合这些用例，因为它支持许多不同的语言并且独立于CPU架构。这使得跨不同硬件平台运行TEE变得更加容易。
便携式客户端
浏览器是便携式客户端的一个很好的例子，许多应用程序可以在浏览器中运行。但是有时你需要一个位于浏览器之外的便携式客户端——不管是为了性能还是为了更丰富的用户体验。
对于这些情况，您可以使用WebAssembly运行时创建自己的可移植客户端，例如BBC为他们的iPlayer做的. WebAssembly运行时负责可移植性并确保来宾代码可以在不同的架构上运行。这意味着您可以专注于您希望客户端提供的功能。
这些是您可能想要使用Wasmtime的一些用例。现在让我们谈谈我们如何确保Wasmtime在这些用例中表现良好。
我们如何让Wasmtime超快
对于几乎所有这些用例，速度会产生影响。这就是为什么我们如此关注性能。
作为我之前说过，当我们进行优化时，我们会考虑性能的两个部分——实例化和运行时。
如果你想知道我们是如何让这两个都变得更快的所有细节，你可以阅读Chris Fallin关于Wasmtime表演的博客文章，但这是一个基本的细分。
实例化
实例化是从新工作到达（如Web请求、插件调用或数据库查询）到WebAssembly模块实例实际准备好运行并为其准备好所有内存和其他状态所需的时间。
这种速度对于快速扩展和缩小的用例非常重要，例如一些Microservices架构和serverless。
正如克里斯在他的帖子中指出的，我们最近的一些变化：
SpiderMonkey.wasm的实例化时间从大约2毫秒……变成了5微秒，或者快了400倍。不错。
这只是一个例子。
我们主要通过使用两种不同的优化来实现这些结果：虚拟内存技巧和延迟初始化。在这两种情况下，我们所做的都是推迟工作，直到真正需要完成。
使用虚拟内存技巧，我们不需要每次创建新实例时都创建新内存。相反，我们依靠操作系统特性在实例之间共享尽可能多的内存，并且只有当其中一个实例需要更改数据时才创建新的内存页。
我们将同样的想法应用于初始化。一个模块可以有许多它声明但不会使用的函数和状态。所以我们推迟了函数表之类的东西的初始化，直到函数真正被使用。这加快了启动速度，并且有一个很好的好处，那就是在不使用函数或其他状态的情况下减少了需要完成的整体工作。
所以我们在实例化阶段通过延迟工作直到需要完成来加快速度。但是我们不仅需要使实例化快速。我们还需要使运行时快速。
运行时
运行时是代码启动后实际运行的速度。当您有长时间运行的代码（如可移植客户端）时，这一点尤其重要。
我们已经能够通过各种更改来提高运行时性能。一些最大的胜利来自我们对编译器Cranelift所做的更改，它采用WebAssembly代码并将其转换为机器代码。
例如，该新的寄存器分配器使SpiderMonkey.wasm运行速度提高约5%。新的后端框架（它选择最好的机器指令用于代码块）使SpiderMonkey.wasm运行速度比这快22%！
我们在这里也做了一些实验。例如，我们已经开始研究一个新的中端优化框架。在早期的原型中，我们已经看到运行时速度提高了13%SpiderMonkey.wasm.
这就是我们如何提高速度。但是安全性呢？
我们如何让Wasmtime超级安全
安全是我们字节码联盟的一大驱动力。我们相信WebAssembly在解决一些最大的新兴安全威胁方面处于独特的地位，我们致力于确保它做到这一点。
我们一直在推动WebAssembly提案，使开发人员更容易创建默认安全的应用程序。但是如果运行代码的运行时本身并不安全，这些都不重要。
这就是为什么我们在Wasmtime本身的安全性上投入了如此多的精力。
尼克·菲茨杰拉德写了一篇关于我们确保Wasmtime安全的所有不同方法的好文章，你应该阅读更多细节，但这里有几个例子：
我们已经使用货物兽医来保护我们的供应链。我们已经在使用内存安全语言，这有助于我们避免引入攻击者可能利用的漏洞。但是这种安全性并不一定能保护我们免受攻击者溜进依赖项的恶意代码的侵害。为了防止这种情况，我们使用货物兽医确保依赖项由受信任的审核员手动审查。
我们在模糊测试上做了很多工作。模糊测试是一种通过抛出一堆伪随机生成的输入来发现代码中难以解释的错误的方法。正如Nick所说，“我们无处不在的模糊测试可能是Wasmtime代码质量的最大单一贡献因素。我们模糊是因为手工编写测试虽然必要，但还不够。”
我们正在正式验证代码的安全关键部分。通过形式化的验证，你实际上可以证明一个程序做了它应该做的事情，就像数学课上的证明一样。这给了我们对相关代码非常高的信心，并帮助我们在不小心引入新错误时准确地指出问题出在哪里。
所以这些是我们让Wasmtime更安全的一些方法。
这是我们非常强烈的感觉——所有WebAssembly运行时都应该遵循Nick列出的最佳实践还有更多的是确保它们是安全的。这是我们拥有我们都想要的安全WebAssembly生态系统的唯一方法。
1.0之后是什么？
现在我们已经达到了1.0，我们计划保持稳定版本的频繁和可预测的周期。我们将每月发布一个新版本的Wasmtime。
Wasmtime的每个版本都会增加主要版本号。这使我们能够使Wasmtime的版本号与特定语言嵌入的版本号保持同步。例如，如果您使用wasmtime-py 7.0，您可以确定您使用的是Wasmtime 7.0。您可以在此处了解有关发布过程的更多信息.
感谢所有使这成为可能的贡献者，如果你想帮助构建Wasmtime的未来，加入我们的Zulip聊天!
GitHub 地址：
https://github.com/bytecodeal...
❤️感谢关注「松宝写代码」，写得不止是代码。