共计 4991 个字符，预计需要花费 13 分钟才能阅读完成。
译者：松宝写代码
译文：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…
❤️感激关注「松宝写代码」，写得不止是代码。
