2009年开发的Wasmtime1.0版本正式迎来。Wasmtime是构建在编译器Cranelift之上的WebAssemblyRuntime。Wasmtime利用Rust编程语言，完全开源且符合WASI标准。Wasmtime还支持与C/C++、Python、.NET、Go等语言集成，同时运行于Windows/Linux/macOS等平台。前言从今天开始，WasmtimeWebAssembly运行时已经是1.0了！这意味着我们字节码联盟中的每个人都同意它已完全准备好用于生产。事实上，我们可以在一年多前就称Wasmtime生产就绪。但我们不想只发布任何WebAssembly引擎。我们想要一个超快速和超安全的WebAssembly引擎。当我们推荐人们选择Wasmtime时，我们希望感到非常自信。因此，为了确保它为你们所有人做好生产准备，我们字节码联盟中的一些人在过去一年中一直在我们自己的生产中运行Wasmtime。Wasmtime在这些生产环境中做得很好，提供了一个稳定的平台，同时也给了我们安全和速度上的优势。以下是我们使用改进后的新Wasmtime的一些经验：Shopify-14个月的生产Shopify于2021年7月从另一个WebAssembly引擎切换到Wasmtime。通过切换，Shopify的平均执行性能提高了约50%。很快-投入生产6个月2022年3月Fast从另一个WebAssembly引擎切换到Wasmtime。Fast的执行时间也缩短了约50%。此外，Fast的每秒请求数增加了72%，达到163%。它工作得很快。数以万亿计的请求使用Wasmtime。DFINITY-16个月的生产DFINITY于2021年5月使用Wasmtime启动了互联网计算机区块链。从那时起，互联网计算机已经为超过150,000个智能合约执行了100K(10^18)条指令，没有出现任何生产问题。InfinyOn-投入生产14个月自2021年7月以来，InfinyOnCloud一直在生产中使用Wasmtime。与Kafka等基于Java的平台相比，英飞凌能够通过Wasmtime将端到端流处理的吞吐量提高5倍以上.Fermyon-Spin产生了6个月的Fermyon，自2022年3月推出以来一直在使用Wasmtime。从那时起，Fermyon发现数以万计的WebAssembly二进制文件可以在单个Spin实例中运行，同时将启动时间保持在一毫秒以内。Embark-投入生产2年自2020年以来，Embark一直在他们的游戏引擎中使用Wasmtime。从那时起，Embark就对Wasmtime卓越的稳定性、安全性和性能印象深刻，让游戏以60FPS的速度运行。SingleStore-投入生产3个月自2022年6月以来，SingleStoreDBCloud一直在使用Wasmtime将开发人员代码安全、快速、大规模地引入数据中。微软——预览11个月自2021年10月起，微软在AzureKubernetes服务中预览了Wasmtime的WebAssembly系统接口（WASI）节点池。凭借在生产中运行它的所有这些经验，我们相信我们也可以向您推荐它。所以我想告诉你我们是如何让它超快和超安全的。但首先，您为什么要首先使用WebAssembly运行时？为什么要使用WebAssembly运行时？WebAssembly最初是为了让代码在浏览器中快速运行而创建的。这意味着您可以在浏览器中运行更复杂的应用程序，例如图像编辑应用程序或视频游戏。因此，每个主流浏览器都有自己的WebAssembly运行时来运行这些类型的应用程序。但WebAssembly也在浏览器之外开辟了许多用例。因此，在这些情况下，您需要找到一个独立的WebAssembly运行时，例如Wasmtime。以下是我们看到人们使用Wasmtime的一些用例。像Wasmtime这样的微服务和无服务器WebAssembly运行时非常适合微服务和无服务器平台，在这些平台上，您拥有需要快速扩展和缩减的独立代码片段。这是因为与JS隔离、容器或虚拟机等其他类似技术相比，WebAssembly的启动时间要短得多。例如，最快的替代方案——JSIsolate——大约需要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超快对于几乎所有这些用例，速度都会产生影响。这就是我们如此关心性能的原因。正如我之前所说，当我们优化时，我们会考虑两个部分的性能——实例化和运行时。如果您想了解我们如何使这两者更快的所有细节，您可以阅读ChrisFallin关于Wasmtime性能的博客文章，但这里有一个基本的细分。实例化实例化是指从新工作到达（例如Web请求、插件调用或数据库查询）到WebAssembly模块实例实际准备好运行并准备好所有内存和其他状态所花费的时间。这种速度对于快速扩展和收缩的用例很重要，例如某些微服务架构和无服务器。正如克里斯在他的帖子中指出的那样，我们最近的一些变化：SpiderMonkey.wasm实例化时间从大约2毫秒......变成了5微秒，或者说快了400倍。好的。这只是一个例子。我们主要通过使用两种不同的优化来实现这些结果：虚拟内存技巧和惰性初始化。在这两种情况下，我们所做的都是将工作推迟到真正需要完成的时候。使用虚拟内存技巧，我们不需要在每次创建新实例时都创建新内存。相反，我们依靠操作系统功能在实例之间共享尽可能多的内存，并且仅在其中一个实例需要更改数据时才创建新的内存页面。我们将相同的想法应用于初始化。一个模块可以有许多它声明但不使用的函数和状态。所以我们推迟函数表之类的初始化，直到函数被实际使用。这加快了启动速度，并且具有减少需要在不使用函数或其他状态的情况下完成的总体工作的好处。因此，我们在实例化阶段通过延迟工作直到需要完成来加快速度。但我们不仅仅需要快速实例化。我们还需要加快运行时间。Runtime运行时是代码启动后实际运行的速度。当您拥有可移植客户端等长时间运行的代码时，这一点尤其重要。我们已经能够通过各种更改提高运行时性能。一些最大的胜利来自我们对编译器Cranelift所做的更改，它采用WebAssembly代码并将其转换为机器代码。例如，这个新的寄存器分配器使SpiderMonkey.wasm的运行速度提高了大约5%。新的后端框架（选择最好的机器指令用于代码块）使SpiderMonkey.wasm的运行速度比这快22%！我们也在这里做了一些实验。例如，我们已经开始研究新的中端优化框架。在早期的原型中，我们发现SpiderMonkey.wasm的运行速度提高了13%。这就是我们提高速度的方式。但是安全呢？我们如何让Wasmtime超级安全安全是我们字节码联盟的重要推动力。我们相信WebAssembly具有独特的定位，可以解决一些最大的新兴安全威胁，我们致力于确保它做到这一点。我们一直在推动WebAssembly提案，以使开发人员更容易创建默认安全的应用程序。但如果运行代码的运行时本身不安全，那么这一切都无关紧要。这就是为什么我们为Wasmtime本身的安全性付出如此多的努力。NickFitzgerald写了一篇很棒的文章，介绍了我们保护Wasmtime的所有不同方式，您应该阅读更多详细信息，但这里有几个例子：我们已经使用货运兽医来保护我们的供应链。我们已经在使用内存安全语言，这有助于我们避免引入攻击者可以利用的漏洞。但这种安全性并不一定能保护我们免受攻击者潜入依赖项的恶意代码的侵害。为了防止这种情况，我们使用cargovet来确保依赖项由受信任的审计员手动审查。我们在模糊测试方面做了很多工作。模糊测试是一种通过向代码中输入一堆伪随机生成的输入来查找代码中难以解释的错误的方法。正如Nick所说，“我们无处不在的模糊测试可能是Wasmtime代码质量的最大贡献者。我们进行模糊测试是因为手写测试虽然必要，但还不够。”我们正在正式验证代码的安全关键部分。通过形式验证，您实际上可以证明一个程序在做它应该做的事情，就像数学课上的证明一样。这使我们对相关代码充满信心，并帮助我们在无意中引入新错误时准确查明出了什么问题。因此，这些是我们使Wasmtime更安全的一些方法。我们有一种非常强烈的感觉——所有WebAssembly运行时都应该遵循Nick提出的最佳实践以及更多以确保它们是安全的。这是我们拥有我们都想要的安全WebAssembly生态系统的唯一途径。1.0之后是什么？现在我们已经达到1.0，我们计划保持频繁且可预测的稳定版本发布周期。我们每个月都会发布一个新版本的Wasmtime。Wasmtime的每个版本都会增加主版本号。这使我们能够使Wasmtime的版本号与特定语言嵌入的版本号保持同步。例如，如果您使用wasmtime-py7.0，则可以确定您使用的是Wasmtime7.0。您可以在此处了解有关发布过程的更多信息。感谢所有使这一切成为可能的贡献者，如果您想帮助构建Wasmtime的未来，请加入我们的Zulip聊天室！GitHub地址：https://github.com/bytecodeal...??感谢大家关注“松宝写代码”，写的不仅仅是代码。
