---
title: Lucet 的价值，不只是快，而是它把 FaaS 拉回轻量沙箱
date: '2019-03-29 10:16:18'
draft: false
summary: Lucet 这类 Wasm 运行时真正值得关注的，是它重新打开了轻量沙箱式 FaaS 的实现空间。
slug: lucet-wasm-as-lightweight-faas-sandbox
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/Hn80B54GO
tags:
- webassembly
- faas
- sandbox
- edge-computing
topics:
- software-engineering
type: post
---

`Fastly` 开源 `Lucet` 之后，我最关注的不是它宣称的性能数字本身，而是它背后的方向：

用 `Wasm` 做一种足够轻的沙箱，把 `FaaS` 从“重容器”重新拉回更适合函数计算的执行边界。

现在很多 `FaaS` 方案的问题，并不只是冷启动，而是整体执行模型本来就不够贴合。

如果还是按不同语言分别维护一套运行方案，平台会越来越碎；如果试图直接拿 `Docker` 这种容器当统一抽象，又会发现它对“每次调用快速起一个执行单元”来说还是太重了。

启动延迟、资源开销、镜像分发、环境管理，这些成本叠在一起，都会让函数计算离“轻”越来越远。

所以 `Lucet` 这类基于 `Wasm` 的运行时有意思的地方在于：

- 执行边界足够轻
- 沙箱模型足够清楚
- 对平台来说更容易统一
- 对应用来说又保留了可控接口

这让我想到区块链里已经实验过很多年的沙箱思路。

区块链上的每笔交易，本质上就是一次短生命周期 VM 执行：

- 启动一个受控执行环境
- 跑完逻辑
- 把状态写回外部
- 生命周期完全由平台托管

从这个角度看，很多区块链 VM 或者 `Wasm` / `RISC-V` 这类方案，其实天然就和 `FaaS` 的问题空间接近。

因为 `FaaS` 最终也要解决两个核心问题：

- 执行单元够不够轻
- 外部状态接口怎么暴露得既可控又通用

如果应用逻辑只需要和 `ABI` 打交道，而不需要直接理解操作系统和底层存储细节，平台就更容易把生命周期、资源调度和状态持久化统一接管。

所以我会觉得，`Lucet` 值得看的不是“是不是又一个更快的 Wasm runtime”，而是它可能代表了一条更合适的 `FaaS` 演化路径：

不是把容器一层层裁薄，而是从一开始就回到更轻量的沙箱抽象。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4355123331209670-1.jpg)
<!-- WEIBO_MEDIA_END -->