作者：易立

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 使用能够在一个进程内部完成安全阻隔，支撑毫秒级冷启动时刻和极低的资源耗费。如下图所示：

当 Knative 遇见 WebAssembly

图片来源：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 的概念架构图比照：

当 Knative 遇见 WebAssembly

二者架构上高度相似，其不同之处是：传统 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)

当 Knative 遇见 WebAssembly

咱们能够看到 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)

当 Knative 遇见 WebAssembly

在通过优化过的完成中，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 服务能够依据恳求数进行弹性伸缩

$ 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 的岁月，那是一种十分简略而单纯的高兴。在这里，也祝每一位技能人永葆猎奇，享用每一天的编程韶光。

点击此处，了解阿里云 Serverless 容器服务 ASK 更多详情！

参阅链接

[1] WAGI – WebAssembly Gateway Interface 项目：

github.com/deislabs/wa…

[2] 优化过的完成：

github.com/denverdino/…

[3] flamegraph：

github.com/flamegraph-…

[4] Knative 装置文档：

knative.dev/docs/instal…

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

www.aliyun.com/product/cs/…

[6] Knative 支撑：

help.aliyun.com/document_de…

[7] 项目：

github.com/denverdino/…