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:            3000Document Path:          /
Document Length:        12 bytesConcurrency 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] receivedConnection 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     214Percentage of the requests served within a certain time (ms)50%     7466%     8875%     9580%    10090%    11595%    12598%    13999%    150100%    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:            3000Document Path:          /
Document Length:        12 bytesConcurrency 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] receivedConnection 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      37Percentage of the requests served within a certain time (ms)50%     1366%     1575%     1780%     1890%     2195%     2398%     2599%     27100%     37 (longest request)

在经过优化过的实现中，P90响应时间已经下降到 21ms，其中 prepare_wasm_instance 所占运行时间已经下降到 17%。整体冷启动效率有了很大的提升！

注：本文利用 flamegraph[3] 进行的性能分析。

利用 Knative 运行 WAGI 应用

为了让 WAGI 可以作为 Knative 应用运行，我们还需在 WAGI 上增加了对 SIGTERM 信号的支持，让 WAGI 容器支持优雅下线。具体细节不再赘述。

Knative 的环境准备可以参考 Knative 安装文档[4]，利用 Minikube 创建本地测试环境。

注：前提是需要有一定的网络能力，因国内无法访问在 http://gcr.io 中的 Knative 镜像。

一个更加简单的方式是直接使用阿里云 Serverless 容器服务 ASK[5] 上 Serverless K8s 集群。ASK 内建了 Knative 支持[6]，无需复杂的配置安装过程即可以开发和使用 Knative 应用。

首先我们利用 WAGI 来定义一个 Knative 服务：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: autoscale-waginamespace: default
spec:template:metadata:annotations:# Knative concurrency-based autoscaling (default).autoscaling.knative.dev/class: kpa.autoscaling.knative.devautoscaling.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 服务可以根据请求数进行弹性伸缩

$ kubectl apply -f knative_test.yaml$ kubectl get ksvc autoscale-wagi
NAME             URL                                                LATESTCREATED           LATESTREADY            READY   REASON
autoscale-wagi   http://autoscale-wagi.default.127.0.0.1.sslip.io   autoscale-wagi-00002   autoscale-wagi-00002   True
$ curl http://autoscale-wagi.default.127.0.0.1.sslip.io
Oh hi world
$ curl http://autoscale-wagi.default.127.0.0.1.sslip.io/hello
hello world

大家也可以进行一些压测，学习一下 Knative 的弹性伸缩能力。

后记

本文介绍了 WAGI 这个项目，它可以将 HTTP 服务器的网络处理细节，与 WASM 应用逻辑实现解耦。这样可以轻松将 WASM/WASI 应用与 Knative 这样的 Serverless 框架相结合。一方面我们可以复用 Knative/K8s 带来的弹性和大规模资源调度能力，一方面我们可以发挥 WebAssembly 带来的安全隔离、可移植、轻量化等优势。

一脉相承的思考，在之前一篇文章《WebAssembly + Dapr = 下一代云原生运行时？》 中，我介绍了一个思路是将 WASM 应用与外部服务依赖通过 Dapr 实现解耦，来解决可移植性与多样化的服务能力之间的矛盾。

当然这些工作还是简单的玩具，只是用来验证技术的可能性边界。主要目的还是抛砖引玉，听到大家关于下一代分布式应用框架和运行时环境的思考和设想。

文章书写过程中，忽然回忆起在 90 年代与师兄们一起根据 RFC 规范来实现 HTTP Server 与 CGI Gateway 的岁月，那是一种非常简单而单纯的快乐。在这里，也祝每一位技术人永葆好奇，享受每一天的编程时光。

参考链接

[1] WAGI - WebAssembly Gateway Interface 项目：

https://github.com/deislabs/wagi

[2] 优化过的实现：

https://github.com/denverdino/wagi/tree/with_cache

[3] flamegraph：

https://github.com/flamegraph-rs/flamegraph

[4] Knative 安装文档：

https://knative.dev/docs/install/

[5] 阿里云 Serverless 容器服务 ASK：

https://www.aliyun.com/product/cs/ask

[6] Knative 支持：

https://help.aliyun.com/document_detail/121508.html

[7] 项目：

https://github.com/denverdino/knative-wagi

作者：易立

原文链接

本文为阿里云原创内容，未经允许不得转载。