关于阿里云:当-Knative-遇见-WebAssembly

作者：易立

Knative 是在 Kubernetes 根底之上的 Serverless 计算的技术框架，能够极大简化 Kubernetes 利用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化我的项目。Knative 由两个次要局部组成：一个是反对 HTTP 在线利用的 Knative Serving，一个是反对 CloudEvents 和事件驱动利用的 Knative Eventing。

Knative 能够反对各种容器化的运行时环境，咱们明天来摸索一下利用 WebAssembly 技术作为一个新的 Serverless 运行时。

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 场景的桥梁。

冷启动性能是 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] 进行的性能剖析。

为了让 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 我的项目：

https://github.com/deislabs/wagi

[2] 优化过的实现：

https://github.com/denverdino…

[3] flamegraph：

https://github.com/flamegraph…

[4] Knative 装置文档：

https://knative.dev/docs/inst…

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

https://www.aliyun.com/produc…

[6] Knative 反对：

https://help.aliyun.com/docum…

[7] 我的项目：

https://github.com/denverdino…

关于阿里云:当-Knative-遇见-WebAssembly

从 WASM、WASI 到 WAGI

WAGI 利用冷启动剖析与优化

利用 Knative 运行 WAGI 利用

后记