作者：易立
Knative 是在 Kubernetes 基础之上的 Serverless 计算的技术框架，可以极大简化 Kubernetes 应用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化项目。Knative 由两个主要部分组成：一个是支持 HTTP 在线应用的 Knative Serving，一个是支持 CloudEvents 和事件驱动应用的 Knative Eventing。
Knative 可以支持各种容器化的运行时环境，我们今天来探索一下利用 WebAssembly 技术作为一个新的 Serverless 运行时。
从 WASM、WASI 到 WAGI
WebAssembly（简称 WASM）是一个新兴的 W3C 规范。它是一个虚拟指令集体系架构（virtual ISA），其初始目标是为 C/C++等语言编写的程序，可以安全和高效地运行在浏览器中。在 2019 年 12 月，W3C 正式宣布 WebAssembly 的核心规范成为Web标准, 大大推进了 WASM 技术普及。今天，WebAssembly 已经得到了 Google Chrome、Microsoft Edge、Apple Safari、Mozilla Firefox 等流浏览器的全面支持。而更加重要的是，WebAssembly 作为一个安全的、可移植、高效率的虚拟机沙箱，可以在任何地方、任何操作系统，任何 CPU 体系架构中安全地运行应用。
Mozilla 在 2019 年提出了 WebAssembly System Interface（WASI），它提供类似 POSIX 这样的标准 API 来标准化 WebAssembly 应用与文件系统，内存管理等系统资源的交互。WASI 的出现大大拓展了 WASM 的应用场景，可以让其作为一个虚拟机运行各种类型的服务端应用。为了进一步推动 WebAssembly 生态发展，Mozilla、Fastly、英特尔和红帽公司携手成立了字节码联盟（Bytecode Alliance），共同领导 WASI 标准、WebAssembly 运行时、工具等工作。后续微软，谷歌、ARM 等公司也成为其成员。
WebAssembly 技术仍然在持续快速演进中，2022 年 4 月，W3C 公布了 WebAssembly 2.0 的第一批公共工作草案，这也成为其成熟与发展的重要标志。
WASM/WASI 作为一种新兴的后端技术，具备的的原生安全、可移植、高性能，轻量化的特点，非常适于作为分布式应用运行环境。与容器是一个一个独立隔离的操作系统进程不同，WASM 应用可以在一个进程内部实现安全隔离，支持毫秒级冷启动时间和极低的资源消耗。如下图所示：
图片来源：cloudflare
目前 WASM/WASI 还在发展初期，还有很多技术限制，比如不支持线程，无法支持低级 Socket 网络应用等等，这极大限制了 WASM 在服务器端的应用场景。社区都在探索一个能够充分适配 WASM 的应用开发模型，扬长避短。微软 Deislabs 的工程师从 HTTP 服务器发展的历史中汲取灵感，提出了 WAGI - WebAssembly Gateway Interface 项目 [ 1] 。没错 WAGI 的概念就是来自于互联网的上古传奇，CGI。
CGI 是“公共网关接口”（Common Gateway Interface）的简称，是 HTTP 服务器与其它程序进行交互的一种规范。HTTP Server 通过标准输入、输出接口等与 CGI 脚本语言进行通信，开发者可以使用 Python/PHP/Perl 等各种实现来处理 HTTP 请求。
一个非常自然的推演，如果我们可以通过 CGI 规范来调用 WASI 应用，开发者就可以非常轻松地利用 WebAssembly 来编写 Web API 或者微服务应用了，而且无需在 WASM 中处理太多的网络实现细节。下图就是 CGI 与 WAGI 的概念架构图对比：
二者架构上高度相似，其不同之处是：传统 CGI 架构，每次 HTTP 请求会创建一个 OS 进程来进行处理，由操作系统的进程机制来实现安全隔离；而 WAGI 中 ，每次 HTTP 请求会在一个独立的线程来中调用 WASI 应用，应用之间利用 WebAssembly 虚拟机实现安全隔离。在理论上，WAGI 可以有比 CGI 更低的资源损耗和更快的响应时间。
本文不会对 WAGI 自身架构以及 WAGI 应用开发进行分析。有兴趣的小伙伴可以自行阅读项目文档。
进一步思考，如果我们可以将 WAGI 作为一个 Knative Serving 运行时，我们就可以建立起一座将 WebAssembly 应用于 Serverless 场景的桥梁。
WAGI 应用冷启动分析与优化
冷启动性能是 Serverless 场景的关键指标。为了更好了了解 WAGI 执行效率，我们可以利用 ab 做一个简单的压测：
$ ab -k -n 10000 -c 100 http://127.0.0.1:3000/
...
Server Software:
Server Hostname: 127.0.0.1
Server Port: 3000
Document Path: /
Document Length: 12 bytes
Concurrency Level: 100
Time taken for tests: 7.632 seconds
Complete requests: 10000
Failed requests: 0
Keep-Alive requests: 10000
Total transferred: 1510000 bytes
HTML transferred: 120000 bytes
Requests per second: 1310.31 [#/sec] (mean)
Time per request: 76.318 [ms] (mean)
Time per request: 0.763 [ms] (mean, across all concurrent requests)
Transfer rate: 193.22 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 0 9
Processing: 8 76 29.6 74 214
Waiting: 1 76 29.6 74 214
Total: 8 76 29.5 74 214
Percentage of the requests served within a certain time (ms)
50% 74
66% 88
75% 95
80% 100
90% 115
95% 125
98% 139
99% 150
100% 214 (longest request) 
我们可以看到 P90 请求响应时间在 115ms，就这？这个和我们对 WASM 应用轻量化的认知不同。利用火焰图，我们可以快速定位到问题所在：prepare_wasm_instance 函数消耗了整体应用运行 80% 的时间。
经过对代码的分析，我们发现在每次响应 HTTP 请求过程中，WAGI 都要对已经编译过的 WSM 应用，重新连接 WASI 以及 wasi-http 等扩展和并进行环境配置。这消耗了大量的时间。定位了问题，解决思路就非常简单了，重构执行逻辑，让这些准备工作只在初始化过程中执行一次，无需在每次 HTTP 请求过程中重复执行。具体可参考优化过的实现 [ 2]
我们重新运行一遍压力测试：
$ ab -k -n 10000 -c 100 http://127.0.0.1:3000/
...
Server Software:
Server Hostname: 127.0.0.1
Server Port: 3000
Document Path: /
Document Length: 12 bytes
Concurrency Level: 100
Time taken for tests: 1.328 seconds
Complete requests: 10000
Failed requests: 0
Keep-Alive requests: 10000
Total transferred: 1510000 bytes
HTML transferred: 120000 bytes
Requests per second: 7532.13 [#/sec] (mean)
Time per request: 13.276 [ms] (mean)
Time per request: 0.133 [ms] (mean, across all concurrent requests)
Transfer rate: 1110.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 0 9
Processing: 1 13 5.7 13 37
Waiting: 1 13 5.7 13 37
Total: 1 13 5.6 13 37
Percentage of the requests served within a certain time (ms)
50% 13
66% 15
75% 17
80% 18
90% 21
95% 23
98% 25
99% 27
100% 37 (longest request)
在经过优化过的实现中，P90响应时间已经下降到 21ms，其中 prepare_wasm_instance 所占运行时间已经下降到 17%。整体冷启动效率有了很大的提升！
注：本文利用 flamegraph [ 3] 进行的性能分析。
利用 Knative 运行 WAGI 应用
为了让 WAGI 可以作为 Knative 应用运行，我们还需在 WAGI 上增加了对 SIGTERM 信号的支持，让 WAGI 容器支持优雅下线。具体细节不再赘述。
Knative 的环境准备可以参考 Knative 安装文档 [ 4] ，利用 Minikube 创建本地测试环境。
注：前提是需要有一定的网络能力，因国内无法访问在 gcr.io 中的 Knative 镜像。
一个更加简单的方式是直接使用阿里云 Serverless 容器服务 ASK [ 5] 上 Serverless K8s 集群。ASK 内建了 Knative 支持 [ 6 ] ，无需复杂的配置安装过程即可以开发和使用 Knative 应用。
首先我们利用 WAGI 来定义一个 Knative 服务：
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: autoscale-wagi
namespace: default
spec:
template:
metadata:
annotations:
# Knative concurrency-based autoscaling (default).
autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
autoscaling.knative.dev/metric: concurrency
# Target 10 requests in-flight per pod.
autoscaling.knative.dev/target: "10"
# Disable scale to zero with a min scale of 1.
autoscaling.knative.dev/min-scale: "1"
# Limit scaling to 100 pods.
autoscaling.knative.dev/max-scale: "10"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/denverdino/knative-wagi:0.8.1-with-cache其中：
- 容器镜像 knative-wagi 包含了 WAGI 网关和一些示例的 WASI 应用，更多细节可以参考项目 [ 7] 。
- autoscale-wagi 服务可以根据请求数进行弹性伸缩