WebAssembly
Edge Computing
Serverless
Cloudflare Workers
Performance

边缘的 WebAssembly:为什么快速启动和独立很重要

为什么边缘的 Wasm 提供近乎零的冷启动和每个请求的隔离,以及该模型何时优于 Lambda 和 Cloud Run。

无服务器的前提一直很诱人:编写一个函数,不管理服务器,按实际使用付费。问题是,执行从来没有像演讲那样干净利落。容器需要初始化。进程在来自不同客户端的请求之间重用。您的系统需要的全球化程度越高,在地球另一端冷唤醒的函数的延迟成本就越高。 [边缘的 WebAssembly0 恰好解决了这组问题 - 不是通过更快的原始吞吐量,而是通过拥有根本不同的执行模型。

冷启动的问题

当 Lambda 函数在一段时间不活动后收到第一个请求时,运行时需要初始化环境。根据语言和数据包大小,这会花费 100 毫秒到 500 毫秒。 Cloud Run 中的容器还是 [Kubernetes1??准备好为流量提供服务可能需要一到十秒的时间。对于 P99 延迟不是关键问题的内部 API,您可以忍受它。对于涉及每个用户请求的逻辑(地理路由、令牌验证、标头定制、A/B 测试),时间成为一个明显的问题。

[Cloudflare Workers2 和 Fastly Compute 做出了架构选择,从结构上消除了这个问题。在 Workers 中,代码在 V8 中运行,在同一进程中隔离、轻量级共享。隔离已经存在;当请求到达时,它会以微秒为单位进行调度。实际上,冷启动接近于零。在 Fastly Compute 中,方法更加直接:Wasm 模块预先编译为主机上的本机代码,并作为纯执行单元加载。从开始到处理只需亚毫秒。

Deno Deploy 遵循类似的路线,支持分布在 30 多个边缘位置的 [TypeScript3´、JavaScript 和 Wasm。结果是一样的:“请求到达”和“函数开始执行”之间的差距缩小到用户体验中不再可衡量的程度。

按请求隔离,而不是按进程隔离

有一个细节很少出现在[无服务器4教程中,但在多租户环境中非常重要:同一进程中的连续请求之间会发生什么?

在 Lambda 和 Cloud Run 函数中,容器或进程经常被重用以提高效率。这对性能有好处,但它会创建一个窗口,在该窗口中,调用之间的意外状态可能会泄漏。由一个请求修改的全局变量可以影响下一个请求。打开连接、内存缓存——所有这些都保留在同一个进程中。对于拥有纪律严明的团队的无遗产设计应用程序来说,这不是问题。但这是存在的风险面。

边缘的 Wasm 模型以另一种方式封闭了这个表面。每个 Wasm 模块都在自己的线性内存上运行:该模块私有的连续字节数组。请求之间没有共享堆。一个请求无法读取另一个请求的内存,即使它们同时在同一硬件上运行。隔离不依赖于单独的进程;它处于虚拟机执行模型级别。

对于在同一硬件上运行来自数千个客户端的逻辑的平台,此细节不是可选的。这是您可以正式推理的安全模型与依赖每个团队最佳实践的安全模型之间的区别。

Edge Wasm 战胜 Lambda 和 Cloud Run 的地方

胜利不是普遍的。在一组特定的情况下,即时启动、全局分发和请求隔离的组合会产生真正的产品差异。

需要在地理上靠近用户的逻辑受益更多。按位置进行路由、按市场进行个性化响应、在到达源服务器之前验证[身份验证5] - 所有这些的延迟都直接受到代码运行位置的影响。边缘功能在距离用户数十毫秒的网络中运行,而不是在数百米之外的云区域中运行。

修改请求和响应也很适合:注入标头、重写 URL、应用自定义缓存、基于 A/B 测试的重定向。这些都是低 CPU 操作,对体验影响很大。速率限制逻辑和机器人检测同样获胜——在流量到达主要基础设施之前对其进行控制,按租户定制,在全球范围内运行。

模型不成立的地方

每个请求的 CPU 限制非常严格 — 在大多数平台上约为 50 毫秒。任何更长的处理都在模型之外。

有状态工作负载是另一个结构性限制。边缘的 Wasm 没有对 [数据库6] 的本机访问权限,任何持久性都通过对源的网络调用。如果业务逻辑是读取、转换和写入数据,则此调用的延迟可能会抵消任何边缘增益。严重的依赖也是一个问题:具有兆字节库的 Wasm 模块失去了快速初始化的优势。

交易是明确的:您获得全球分布和即时启动,并放弃长时间运行的进程、丰富的操作系统访问和 CPU 密集型工作负载。在正确的情况下接受这种交易,并在错误的情况下拒绝这种交易,这是重要的架构决策。

技术负责人需要评估什么

富有成效的问题不是“我们应该使用边缘 Wasm 吗?”但是“我们平台的边缘逻辑有多少部分从这个模型中获益?”几乎每个平台都有涉及每个请求的逻辑:身份验证、路由、[功能标志 7、自定义缓存。这个逻辑是一个自然的候选者。

评估首先按地理区域绘制当前延迟。如果根据用户所在位置,P50 和 P99 之间存在较大差异,则边缘计算将进入对话。如果用户群在地理上集中,收益就会降低。

第二个轴是多租户隔离。如果平台为每个客户端运行不同的逻辑,Wasm 的每个请求隔离模型可以保证传统容器在没有额外运营成本的情况下无法交付。第三个轴是入门:Workers 和 Fastly Compute 拥有成熟的 CI/CD,但与 Node 或 Python 中的 Lambda 相比,Wasm 工具链仍然有粗糙的优势。这个成本需要包含在计算中。

另请阅读

  • [Cloudflare Workers:无服务器边缘计算实用指南8
  • [生产中的 Cloudflare Workers:hello world 之后发生了什么变化9
  • [Cloudflare Workers 与 Pages:选择之前最重要的区别10
  • [浏览器之外的WebAssembly:缺失的通用执行层11
  • [边缘和物联网的 RISC-V:为什么开放架构很重要12
  • [2025 年使用 AWS Lambda 和 Cloudflare Workers 开发无服务器应用程序13