本文来自微信公众号“开源云中文社区”。
WebAssembly（通常简称为Wasm）是为web浏览器而构建的。但一项技术的发展往往超出了其创造者的意图。Wasm就是一个很好的例子。Wasm在一个地方很有希望，那就是在云端。这是一个运行无服务器功能的绝佳平台。
在本文中，我们将了解Wasm的设计意图，以及它是如何改进浏览器的。然后我们将看到Wasm是如何实现向通用技术的飞跃的。
最后，我们将看看云中的一个特定问题——执行无服务器功能，并看看Wasm如何解决这个问题。
跳过Applets、Flash和Silverlight
2015年，Mozilla向世界推出了WebAssembly。在这篇博客文章中，Luke Wagner这样描述WebAssembly：
“WebAssembly定义了一种可移植的、节省大小和加载时间的格式和执行模型，专门设计用作web的编译目标。”
目标是建立一种二进制格式，可以在每个主要的网络浏览器中执行。这种格式的特点使许多不同的语言，从C到Python，都可以在浏览器中运行。代码是用支持的语言之一编写的，编译成Wasm格式，然后在浏览器中执行。JavaScript代码控制Wasm的执行，甚至可以通过调用Wasm库内的函数与Wasm交互。
这已经不是第一次尝试这样的事情了。一些其他语言已经添加到浏览器中（后来又从浏览器中删除）。Java Applets是第一个。VBScript在微软浏览器中有过短暂的寿命。Silverlight和Adobe Flash也来了又走。但这一次，Mozilla的人做了一些不同的事情：
——他们没有支持一种语言，而是定义了一种现有语言可以编译的二进制格式。
——Mozilla没有单干，而是与谷歌、微软、苹果和其他公司联合起来。他们承诺在W3C的赞助下开展这项工作。
——Wasm没有像Flash、Silverlight和Java那样专注于增强用户界面，而是专注于库的使用和共享代码。
——Wasm团队试图解决的用例不是小部件和流媒体播放器，而是将代码从其他地方移植到浏览器。例如，考虑一下那个破旧的C库，它多年来一直尽职尽责地做着一些重要的工作，但每个人都害怕碰它，因为害怕破坏它。它能被编译到Wasm以在浏览器中享受新的使用吗？或者考虑一下需要高效计算的复杂问题，比如图形处理？高性能代码可能更容易用Rust这样的语言表达。Wasm允许开发人员用开发人员喜欢的语言编写代码，然后在浏览器范围内使用。
不断增长的用途
纵观计算历史，我们发明了一些技术来解决一个狭隘的问题，但后来才意识到该工具有更广泛的应用——互联网是为美国国防部的通信而建立的；网络是用来交换物理论文的；Java是用于嵌入式计算的；JavaScript，现在是世界上最流行的语言，最初是一种在浏览器中弹出警报的“玩具”语言。这些技术都从利基解决方案跃升为通用工具。
Wasm现在就在那一刻。
它在浏览器中取得了成功。但人们正在发现Wasm的各种其他用途。从编译器工具链到数据库中的用户定义函数，Wasm在一些值得注意的地方出现了。
——SingleStore将Wasm用于数据库中的用户定义函数。
——开发Zig语言的人最近宣布，他们使用Wasm自托管编译器，“消灭”了8000行C++代码。
——Docker宣布支持在Docker Desktop中运行Wasm，而微软现在支持在其AKS Kubernetes集群中运行Wasm。
还有一个用例特别令人兴奋。WebAssembly似乎非常适合云计算。为了理解原因，让我们从当今云的核心技术之一：无服务器功能开始。
无服务器功能v1
无服务器功能，有时被称为功能即服务（FaaS），旨在提供一种创建小型云服务的简单方法。通过将无服务器功能与服务器进行对比，最容易理解无服务器功能。web服务器软件在套接字上侦听HTTP请求，解析每个请求，然后处理这些请求。在web服务器的进程生存期内，它可能会处理数十万个单独的HTTP请求。典型的HTTP服务器还必须管理SSL连接、系统进程、线程池和并发，以及各种其他较低级别的任务，所有这些都是为了响应HTTP请求。
无服务器功能旨在尽可能多地去除“服务器性”。相反，编写无服务器功能的开发人员应该能够专注于一件事：响应HTTP请求。没有网络，没有SSL配置，也没有请求线程池管理——所有这些都由平台处理。无服务器功能启动，回答一个请求，然后关闭。
这种紧凑的设计不仅减少了我们必须编写的代码量，而且还降低了运行无服务器功能的复杂性。我们不必让HTTP或SSL库保持最新，因为我们不直接管理这些东西。平台确实如此。从错误处理到升级，一切都应该更容易，事实上也更容易。
鉴于这种对简单性的不懈关注，难怪420万开发人员表示他们至少编写了一个无服务器功能。亚马逊报告称，他们每月执行10万亿无服务器功能。
尽管编程范式很有吸引力，但无服务器功能的早期迭代也有几个缺点。它们起步很慢。打包无服务器功能并部署非常繁琐。调试和故障排除很困难。然而，这些问题背后的原因既容易理解，又令人惊讶。
这些无服务器功能的绝妙新想法是在错误的技术堆栈上运行的——笨重的虚拟机。每种语言的运行时和包管理器。为另一类计算构建的云基础设施正被重新用于一种事后看来不适合的技术。
事实证明，我们需要将无服务器从好提升到很棒的技术就存在于浏览器中——把Wasm植入云端。
Wasm为无服务器所做的
如果我们试图改善无服务器功能的状态，那么有一些高优先级的部分需要改进。我们需要无服务器环境非常快速、超级安全，并且我们希望它尽可能多地隐藏“服务器”的详细信息。也就是说，当我们必须开始要求用户选择操作系统或CPU类型时，我们就迫使用户做出服务器决策，而不是无服务器决策。当涉及到部署无服务器功能时，定义良好的包格式的较小二进制文件使我们更容易进行发布。
正是在这里，Wasm的传统使其成为无服务器功能的完美选择。当我们谈论Wasm是“为浏览器构建的”时，我们实际上是在谈论一些使Wasm非常适合浏览器模型的关键功能：
——启动时间快。没有人愿意等待页面加载。
——跨架构、跨操作系统。“需要Internet Explorer才能查看此页面”的日子已经一去不复返了。
——压缩二进制文件。当在互联网上移动代码时，我们不想发送大文件。
——安全沙盒。浏览器每天运行不受信任的代码。我们依靠浏览器来保护我们免受漏洞和黑客的攻击。
这四个特性恰好是无服务器功能平台所需要的特性：想要零延迟启动时间；不想知道或关心功能运行的架构或操作系统（这就是无服务器的乐趣，对吧？不必关心下面的服务器！）；希望二进制文件紧凑，这样就可以快速打包和上传它们；想知道在多租户云中运行功能是否安全。
在Wasm上运行的无服务器功能平台可以很容易地构建各种各样的应用程序，包括高响应的HTTP应用程序，然后高度自信地部署它们。这正是我们在Fermyon构建开源Spin框架时考虑的用例。
结论
许多技术都是从一个利基市场开始的，后来发展成为通用工具。随着我们发现web浏览器之外的新应用程序，Wasm正在经历这样的转变。无服务器功能已经取得了很大的成功。但要实现跨越式发展，这项技术需要更快、更稳健的基础——Wasm就是这样一种技术。
