译者：松宝写代码

译文：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...

❤️感激关注「松宝写代码」，写得不止是代码。