百度医院网站建设,佛山seo按效果付费,phpstorm做网站,长沙市有什么好玩的旅游景点Knative 是在 Kubernetes 基础之上的 Serverless 计算的技术框架#xff0c;可以极大简化 Kubernetes 应用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化项目。Knative 由两个主要部分组成#xff1a;一个是支持 HTTP 在线应用的 Knative Serving#xff0c;一个是支持 …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 InterfaceWASI它提供类似 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: 10spec: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
作者易立
原文链接
本文为阿里云原创内容未经允许不得转载。
