WebAssembly终极指南

WebAssembly（又名Wasm）已被证明在浏览器中运行得非常好。它被广泛用作提高速度和安全性的一种方式，尤其是直接在浏览器中运行的应用程序的计算简单性，特别是使用 JAVAScript 以及其他语言。这种速度和简单性最终要归功于它的二进制计算结构，它直接以非常干净的方式在 CPU 上运行。

然而，WebAssembly 最终将被广泛使用的场景，可能是作为一种在单个模块中跨不同容器和 Kube.NETes 集群、设备（例如边缘和物联网设备）和多云环境同时部署应用程序的方式。

WebAssembly 可以说初露峥嵘，不负众望。尽管它是还有待观察，但它最终能否成功在很大程度上取决于其作为一项技术的价值之外的因素。可能阻碍它的因素包括缺乏关于部署它的标准化设备的协议。

1、关键卖点

考虑到其低计算指令集大小，WebAssembly 提供的其他东西是它的超快速度和它的安全性——或者它的沙箱设计使用行业术语——因为在部署期间其他服务或应用程序无法访问，因为内部代码仍然存在隔离并且在以毫秒为单位的闪电般快速旅程中无法访问，以部署在不同的环境中。

WebAssembly 非常适合无服务器环境，被视为克服许多阻碍其采用的无服务器问题的一种方式。今天典型的第三方用例意味着无服务器将需要第三方的支持，而第三方通常是云供应商。对于许多人来说，无服务器架构可能等同于Amazon Web Services上的 Lambda 或来自其他云供应商（例如 Azure、google Cloud、 Oracle或 IBM）的产品。因此，在许多情况下，组织必须乐于将其多个基础架构委托给一个第三方云提供商，而不是多个供应商来管理其关键应用程序。仅出于这个原因，避免供应商锁定是 Wasm 的一个关键卖点。

Fermyon Technologies 联合创始人兼首席执行官 Matt Butcher 表示：“我们在 Fermyon 一直听到的一件事是，开发人员喜欢无服务器函数范式。” “不过，这句话几乎总是伴随着‘但是’：虽然每个大云都提供无服务器，但开发人员不喜欢这些产品附带的供应商锁定、性能和开发人员体验。”

Wasm 的一个基本特征是它如何让开发人员不再担心使用大量潜在的库来让他们的代码看到部署。“无论底层语言如何，WebAssembly 都提供了共享库的承诺。例如，一个 JavaScript 程序可以加载一个最初用 Python/ target=_blank class=infotextkey>Python 编写的库和另一个用 Rust 编写的库，并同时使用它们，”Butcher 说。“在当今的语言生态系统中，每种编程语言都有自己的YAML解析器、自己的 JPEG 库等等。用多种语言实现相同的算法会浪费多少小时、几天和几个月？WebAssembly 是补救措施。”

2、有望成为新标准

事实上，WebAssembly 有潜力成为编写应用程序的新标准，它由可以组合并塑造成许多不同应用程序的“真正通用的构建块”组成，Enterprise Management Associates (EMA) 的分析师 Torsten Volk， 说。对于开发人员来说，这是“无需担心让它在这些应用程序的运行时内运行的”完成的。这为开发人员生产力的大幅提升打开了大门，因为开发人员可以从甚至可以作为运行时的一部分提供的样板模块库中进行选择”Volk 说。“它们可以包含用于身份管理、访问控制、应用程序消息传递、数据存储和数据挖掘的微服务，也可以是整个数据管道、机器学习模型或 API 集成。开发人员将专注于编写业务代码，并且只编写业务代码，这种前景让 Wasm 如此令人兴奋。”

然而，就目前而言，WebAssembly 仍然是一项正在进行的工作。除其他外，它正在等待组件接口 Wasi 的标准化，该层需要确保部署 Wasm 应用程序的不同设备和服务器之间的端点兼容性。

3、到底做了什么？

这个想法是，WebAssembly 旨在部署以开发人员选择的语言编写的应用程序，以便在不同的环境中同时部署到任何地方。“完全不同”，因为 WebAssembly 在 CPU 上运行，只需要一个设备、服务器等，就能运行一个 CPU 指令集。这意味着 WebAssembly 模块中应用程序的单一部署理论上应该能够在多种不同的不同设备上运行和更新，无论是服务器、边缘设备、多云、无服务器环境等。

在任何有 CPU 能够运行指令集的地方，WebAssembly 旨在运行以越来越多的语言编写的应用程序，它可以托管在一个模块中。它现在支持 Python、JavaScript、C++、Rust 等。用不同编程语言编写的不同应用程序应该能够在单个模块中运行，尽管这种功能在很大程度上仍处于开发阶段。从本质上讲，一个微服务模块应该能够用于在多个不同的环境中部署多个服务，并在不重新配置端点的情况下提供应用程序更新。理论上，只需在模块中配置应用程序即可，一旦模块内部完成工作，就不必为部署模块的每个环境单独重新配置。

4、能取代容器吗？

WebAssembly 将取代容器和 Kubernetes 的论点在很大程度上是不合逻辑的。这是因为 WebAssembly 和容器以及 Kubernetes 是不同但重要的技术。即使有一些重叠的目的，它们也满足特定和独立的计算需求。

至少在不久的将来，许多组织将不愿意更换他们的容器基础设施和 Kubernetes 环境。除了可能会因为用 WebAssembly 替换它们而失去对它们的投资之外，WebAssembly 并不是一种适用于所有容器化环境的全部替换技术。事实上，最近人们非常关注使用 Wasm 在容器和 Kubernetes 环境中部署应用程序。

Docker 继续发布关于它将如何容纳和扩展对 WebAssembly 的支持的公告。经常讨论两者将如何协同工作，尤其是如何将 Docker 与容器一起使用以允许它们使用 WebAssembly 部署和管理应用程序。这些调整在很大程度上被认为是为 Wasm 的采用和与容器和 Kubernetes 一起使用铺平道路所必需的。

“凭借超音速启动速度和轻型运行时要求，Wasm 非常适合无服务器功能——这在历史上很难在 Docker 中很好地实现。相反，Docker 的突出特点是它能够以可移植的方式轻松捆绑长期运行的服务器及其环境，”Butcher 说。“长期运行的服务器还不是 Wasm 的强项。现在 Wasm 可以以与容器相同的图像格式打包，我们将看到这两种技术结合起来构建那种使用现有技术难以实现的混合无服务器和服务器微服务应用程序。”

5、比 JavaScript 快吗？

在广为人知的万维网诞生之初，出现了 JavaScript。自 1995 年Brendan Eich创建了支持 Netscape 的语言以来，JavaScript 就已经存在了，Netscape 是一种在当时具有革命性意义的网页浏览器，现在已不复存在但在美学上令人愉悦。从那时起，ECMAScript 标准就成为了 Web 开发的基础，代表了在 Web 浏览器中运行的绝大多数应用程序。

最近，WebAssembly——实际上已经存在了一段时间——出现了。继 2019 年万维网联盟（W3C）将其命名为网络标准后，它也因此成为继 html、css、JavaScript 之后的第四个网络标准。但是，虽然Web 浏览器应用程序 代表了 Wasm 的中心和历史用例，但重点是它被设计为可以在正确配置的 CPU 上的任何地方运行——这就是 Wasm 和 JavaScript 在某些用例中分叉并变得更加集成的地方。

Wasm 和 JavaScript 保持紧密联系，但 Wasm 除了 JavaScript 之外还有其他很多东西。简而言之，Wasm 帮助 JavaScript 在网络浏览器中更高效地运行的最初目的仍然是它们集成的关键组成部分。这种集成现在已经超越了 Web 浏览器，并扩展到边缘和服务器应用程序，而 JavaScript 本身并不是最适合的应用程序。

这是由于 Wasm 如何在 CPU 级别以二进制格式运行。别忘了，与 JavaScript 不同，Wasm 不是一种编程语言。Wasm 的主要优点之一是它的功能使其能够适应除 JavaScript 之外的多种不同语言，当然包括 Python、Rust以及 Go、.NET、C++、Java 和 php。

所以，WebAssembly 既可以在需要的时候集成 JavaScript，当然也不限于集成 JavaScript。这种与 JavaScript 的集成和使用一直是 WebAssembly 和 JavaScript 共生的基石，尤其是在 Web 应用程序领域。

对于纯计算性能以及图像处理等任务，WebAssembly 无疑显示了其比 JavaScript 快得多的优点。但可以说，上下文要比这复杂得多。关于更快的计算时间是否同样重要，这并不是一个真正的问题，例如移动和 Web 应用程序的轻型编码任务需要 JavaScript 代码。

JavaScript 是一种几乎任何人都可以使用的语言，它提供了许多社区支持的库，这些库支持许多用例，而无需每次都重新发明轮子，Volk 指出。“将 JavaScript 和 Python 等依赖于解释器的语言作为字节码执行，并将样板代码与核心应用程序分开，可以带来巨大的性能和容量优势，”Volk 说。

6、会取代 JavaScript 吗？

重点不在于 WebAssembly 是否会取代 JavaScript，因为没有可预见的原因。相反，WebAssembly 将做的是扩展 JavaScript 的范围，使其更易于部署，而不仅仅是浏览器。

“我们在 Fermyon 看到的一切让我们感到惊讶。开发人员要求在 WebAssembly 中执行 JavaScript 和 TypeScript。我们从我们的社区听到的是，无服务器范式是他们喜欢的，而 JavaScript 只是他们在构建无服务器功能时希望拥有的多种语言之一，”Butcher 说。“所以，如果 Wasm 最初是 JavaScript 的补充，那么在某些方面这种关系已经倒转了。”

7、提供卓越的安全性？

与仅在 JavaScript 中部署的代码相比，Wasm 可以提供安全优势。当 Wasm 被用作可以部署 JavaScript 应用程序的“steroids编译器”时，Wasm 可以使 JavaScript 代码更加安全。例如，Wasm 将 JavaScript 与浏览器隔离开来，确保内存安全，并实现与 JavaScript 的动态类型变量相比更难利用的强类型变量。

“Wasm 的安全模型可以让庞大的 JavaScript 社区开始创建完整的应用程序，而不是只构建前端并依靠后端开发人员来完成其余的工作，”Volk 说。“将单个 Wasm 模块链接到基本应用程序中，为传统 JavaScript 前端带来活力的能力是一个令人兴奋的观点。想象一下，如果前端开发人员能够安全地在 MongoDB、Postgres 或 SalesForce API 上存储和访问数据，将会有怎样的可能性。”

事实上，Wasm 在许多方面都提供了安全优势。这是因为，正如网络资产管理和治理解决方案提供商 JupiterOne 的首席信息安全官Sounil Yu所说：

Wasm 作为 JavaScript 的编译器可以通过减少漏洞攻击面、提供更好的内存安全性、模糊代码、沙盒化执行环境和利用现有的安全生态系统来提高应用程序的安全性。Wasm 具有有限的指令集和更好的内存管理，这有助于减少漏洞的攻击面并防止一些常见类型的漏洞，例如缓冲区溢出。

Wasm 代码通过晦涩难懂的方式提供了一点安全性，因为它不是人类可读的，这使得攻击者更难对代码进行逆向工程，从而更难发现和利用漏洞。

Wasm 还可以在沙盒环境中运行，这有助于将代码与系统的其余部分隔离开来，以防止它访问敏感信息或执行非法操作。

Wasm 框架，如 CNCF 的wasmCloud，通过提供更高级别的抽象进一步扩展了 Wasm 安全足迹，减少了开发人员嵌入每个应用程序的代码量。wasmCloud 还可以更轻松地对工件进行签名、启用内置监控和自动化应用程序修补，从而减轻开发人员的安全负担。

但我们不能说 JavaScript 天生就是不安全的。事实上，Javascript“可以变得非常安全，”微软 Azure Core Upstream 的首席项目经理 Ralph Squillace 在一封电子邮件回复中说。“浏览器是地球上最受攻击的表面之一。然而，WebAssembly 通过数学上可证明的沙箱模型更容易进行深度防御，Veriwasm 等工具利用了这种模型，”他说。

“此外，您可以使用即将推出的组件模型来限制攻击面——例如，主机可能甚至不提供文件系统 API——在未来的世界中，这些类型的限制将被证明是至关重要的，”Squillace 说。“但不要被愚弄：主机仍然会犯配置错误并为模块提供过多的功率！”

原文链接：https://thenewstack.io/webassembly-the-ultimate-guide/