WebAssembly 在云原生项目中的应用

2021/01/12 21:40
阅读数 835

作者:iyacontrol

原文链接:

https://segmentfault.com/a/1190000038925794

微信不支持插入外链,点击阅读原文查看文中所附资源。


尽管在诞生之初,WebAssembly(简称Wasm)目的是为浏览器带来高级编程的功能 -- 它提供了一条途径,以使得以各种语言编写的代码都可以以接近原生的速度在Web中运行。在这种情况下,以前无法以此方式运行的客户端软件都将可以运行在 Web 中。

但是随着最近几年的发展,Wasm 凭借着以下几个特性:

  1. 接近原生性能运行

  2. 沙箱

  3. 可移植性,build once, run everywhere

给云原生项目带来了可扩展性。

接下来我们通过几个云原生项目,来看看Wasm 是如何成为可扩展性的利器。

Envoy 和 Istio

Envoy是专为大型现代服务架构设计的L7代理和通信总线。其已经成为了Service Mesh 解决方案数据面事实上的标准。

但是我们在应用Envoy的过程中,我们可能希望插入其他业务逻辑,例如度量,可观察性,转换,数据丢失预防,合规性验证或其他功能。

不过编写和添加自定义Envoy模块有点繁琐。你必须使用C++编程并在Envoy中重新编译。

为了解决这个问题,Envoy 社区在 Envoy 中嵌入了 WASM 虚拟机以获得一个安全的沙箱环境,用于动态加载和运行可拔插的扩展代码(被编译为 WASM 字节码),简化 Envoy 二次开发和功能增强的复杂度。

使用 Wasm 扩展 Envoy 带来了几个主要好处:

  • 敏捷性:可以用控制平面在运行时下发和重载扩展。这就可以快速的进行扩展开发→ 测试→ 发布周期,而无需重启 Envoy。

  • 可靠性和隔离性:扩展部署在具有资源限制的沙箱中,这意味着它们现在可以崩溃或泄漏内存,但不会让整个 Envoy 挂掉。CPU 和内存使用率也可以受到限制。

  • 安全性:沙盒具有一个明确定义的 API,用于和 Envoy 通信,因此扩展只能访问和修改链接或者请求中有限数量的属性。此外,由于 Envoy 协调整个交互,因此它可以隐藏或清除扩展中的敏感信息(例如,HTTP 头中的 “Authorization”和“Cookie”,或者客户端的 IP 地址)。

  • 灵活性:可以将超过 30 种编程语言编译为 WebAssembly,可以让各种技术背景的开发人员都可以用他们选择的语言来编写 Envoy 扩展,比如:C++,Go,Rust,Java,TypeScript 等。

在 Envoy 支持 Wasm 之后,istio 也通过这种扩展机制,移除了 Mixer 组件,将现有的 out-of-process 的插件模型最终用基于 WASM 的 in-proxy 扩展模型来替代,极大提升了网格的性能。

OPA

Open Policy Agent(简称OPA)是一种开放源代码的通用策略引擎,它统一了整个技术栈中的策略执行。OPA背后的原则之一是策略评估与策略执行解耦。

在 OPA v0.15.1 之前,各种基础设施需要嵌入策略评估引擎。

由于OPA策略评估引擎是使用golang编写,所以对于其他编程语言,集成OPA存在一定难度。其他语言只能通过Restfull API的方式。

在OPA v0.15.1+版本,OPA 引入了Wasm 来解决该问题。OPA包含一个接受Rego策略作为输入并生成可执行的 Wasm 程序作为输出的编译器。该 Wasm 程序可以加载到任何标准的Wasm 运行时中,并在需要策略决策时执行。

容器和 Kubernetes

随着Wasm的发展,WebAssembly system interface(简称Wasi)出现了。WASI代表WebAssembly系统接口。这是由 Wasmtime 项目设计的API,可提供对几种类似操作系统的功能的访问,包括文件和文件系统,Berkeley套接字,时钟和随机数。

此时Wasm的沙箱机制带来的隔离性和安全性,都比Docker做的更好。Docker的创始人也曾说过:"如果WASM + WASI在2008年存在,我们就不需要创建Docker。"

用于创建可以与容器相同的方式运行的有效二进制可执行文件。Wasm有潜力成为Docker的重要替代部署单元。

Wasm container 与 Kubernetes的集成,目前有两种思路:

Krustlet

Krustlet是一个用 Rust 开发的开源 Kubernetes kubelet,用于在 Kubernetes 中运行 WebAssembly 工作负载。

目前这是一个实验性质的项目。

container-shim-wasm

该思路相对Krustlet,更加合理,侵入性也比较小。我们只需要实现 container-shim-wasm,使containerd直接可以管理 Wasm container。

该方案与 kata,firecracker 集成 Kubernetes 的实现思路都比较类似。

相信随着 Wasi 的完善,我们不久的将来,在kubernetes中,可以通过 RuntimeClass 指定,在 node节点运行 Wasm container。

Serverless

其实截止目前,已经有大量的组织将 Wasm 用于 serverless 的场景。比如:

Second State 提供了一个开源WebAssembly实现(Second State Virtual Machine,或SSVM),该实现专门针对服务器端应用程序进行了优化。

  • 同类最佳的性能。对于冷启动,它比Docker快1000倍。

  • 无缝支持服务器应用程序框架,例如Node.js。您可以使用SSVM构建高性能的Node.js应用程序。

  • 支持安全访问外部资源,例如数据库,消息队列,甚至是新的AI硬件

  • 允许精确计量无服务器应用程序的计算资源。

Second State 已经支持 Wasm 用于AI、区块链等场景。

而 Cloudflare 也早已推出了自己的 Serverless 产品 Cloudflare Workers

边缘计算

边缘运行的物联网设备正在推动计算的未来,这已不是什么秘密。但是,许多设备缺少最佳的计算硬件或其他资源,例如电源,网络和存储。

现在诸多基于Kubernetes的边缘计算解决方案(kubeedge等),其边缘工作运行时依旧是docker。这种做法不是最理想的,尤其是对于物联网和边缘计算用例。

我们是否可以在边缘端直接运行 Wasm 

随着Wasm通用运行时wasmer 1.0 GA,其推出了Headless版本。该版本提供尽可能轻量级的执行环境,这对于在边缘的IoT设备上高效运行Wasm至关重要。

借助对AOT编译的新增支持,我们可以运行“headless”版本的Wasmer,其重量仅为数百KB,并且可以在任何设备上运行任何预编译的Wasm二进制文件。

总结

Wasm已经成为了云原生项目的扩展利器,并且非常有可能成为云原生工作负载的最佳运行时。


点击阅读原文,查看文中所附链接

本文分享自微信公众号 - WebAssembly 中文社区(webassemblywasm)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
1 收藏
分享
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部