Knative是在Kubernetes基础之上的Serverless计算的技术框架，可以极大简化Kubernetes应用的开发与运维体验。在年3月成为CNCF孵化项目。Knative由两个主要部分组成：一个是支持HTTP在线应用的KnativeServing，一个是支持CloudEvents和事件驱动应用的KnativeEventing。
Knative可以支持各种容器化的运行时环境，我们今天来探索一下利用WebAssembly技术作为一个新的Serverless运行时。
从WASM、WASI到WAGI
WebAssembly（简称WASM）是一个新兴的W3C规范。它是一个虚拟指令集体系架构（virtualISA），其初始目标是为C/C++等语言编写的程序，可以安全和高效地运行在浏览器中。在年12月，W3C正式宣布WebAssembly的核心规范成为Web标准,大大推进了WASM技术普及。今天，WebAssembly已经得到了GoogleChrome、MicrosoftEdge、AppleSafari、MozillaFifox等流浏览器的全面支持。而更加重要的是，WebAssembly作为一个安全的、可移植、高效率的虚拟机沙箱，可以在任何地方、任何操作系统，任何CPU体系架构中安全地运行应用。
Mozilla在年提出了WebAssemblySystemInterface（WASI），它提供类似POSIX这样的标准API来标准化WebAssembly应用与文件系统，内存管理等系统资源的交互。WASI的出现大大拓展了WASM的应用场景，可以让其作为一个虚拟机运行各种类型的服务端应用。为了进一步推动WebAssembly生态发展，Mozilla、Fastly、英特尔和红帽公司携手成立了字节码联盟（BytecodeAlliance），共同领导WASI标准、WebAssembly运行时、工具等工作。后续微软，谷歌、ARM等公司也成为其成员。
WebAssembly技术仍然在持续快速演进中，年4月，W3C公布了WebAssembly2.0的第一批公共工作草案，这也成为其成熟与发展的重要标志。
WASM/WASI作为一种新兴的后端技术，具备的的原生安全、可移植、高性能，轻量化的特点，非常适于作为分布式应用运行环境。与容器是一个一个独立隔离的操作系统进程不同，WASM应用可以在一个进程内部实现安全隔离，支持毫秒级冷启动时间和极低的资源消耗。如下图所示：
图片来源：cloudfla
目前WASM/WASI还在发展初期，还有很多技术限制，比如不支持线程，无法支持低级Socket网络应用等等，这极大限制了WASM在服务器端的应用场景。社区都在探索一个能够充分适配WASM的应用开发模型，扬长避短。微软Deislabs的工程师从HTTP服务器发展的历史中汲取灵感，提出了WAGI-WebAssemblyGatewayInterface项目[1]。没错WAGI的概念就是来自于互联网的上古传奇，CGI。
CGI是“公共网关接口”（CommonGatewayInterface）的简称，是HTTP服务器与其它程序进行交互的一种规范。HTTPServer通过标准输入、输出接口等与CGI脚本语言进行通信，开发者可以使用Python/PHP/Perl等各种实现来处理HTTP请求。
一个非常自然的推演，如果我们可以通过CGI规范来调用WASI应用，开发者就可以非常轻松地利用WebAssembly来编写WebAPI或者微服务应用了，而且无需在WASM中处理太多的网络实现细节。下图就是CGI与WAGI的概念架构图对比：
二者架构上高度相似，其不同之处是：传统CGI架构，每次HTTP请求会创建一个OS进程来进行处理，由操作系统的进程机制来实现安全隔离；而WAGI中，每次HTTP请求会在一个独立的线程来中调用WASI应用，应用之间利用WebAssembly虚拟机实现安全隔离。在理论上，WAGI可以有比CGI更低的资源损耗和更快的响应时间。
本文不会对WAGI自身架构以及WAGI应用开发进行分析。有兴趣的小伙伴可以自行阅读项目文档。
进一步思考，如果我们可以将WAGI作为一个KnativeServing运行时，我们就可以建立起一座将WebAssembly应用于Serverless场景的桥梁。
WAGI应用冷启动分析与优化
冷启动性能是Serverless场景的关键指标。为了更好了了解WAGI执行效率，我们可以利用ab做一个简单的压测：
$ab-k-n-c