Netlify 边缘计算架构重构：从 V8 Isolate 转向 Firecracker MicroVM，延迟降低约 5 倍
Netlify 目前每天在其平台上运行约 10 亿次边缘函数调用，服务于 Sunweb 的个性化页面、Loto-Québec 的 Cookie 检查流量路由以及大量其他网站。这些任务此前均基于完整的 JavaScript 运行时执行，随着客户流量的增长，低延迟成为核心技术挑战。在每秒处理数以万计的边缘函数请求时，所有操作必须在几毫秒内完成。
过去数月间，Netlify 团队重建了 Edge Functions 的基础设施。新架构不再将请求发送至托管的执行服务，而是直接运行在 Netlify 自有边缘网络中的微型虚拟机（MicroVM）上。这一转变使平均速度提升约 5 倍，同时增强了安全性与可靠性，并为在边缘运行复杂计算提供了更多可能性。
值得注意的是，此次底层架构升级并未改变开发者的使用体验。URL 导入、npm 包支持、Node 内置模块、netlify.toml 声明以及本地开发流程均保持不变。以下是新架构的关键性能数据及实现细节。
核心性能指标
边缘函数位于网站前端，需匹配每一个请求。由于处理时间直接计入用户等待时长，毫秒级的优化至关重要。在新架构下，热调用（Warm Invocation）的路由、输入 MicroVM、执行函数及生成响应头的总耗时显著降低：
- 中位数延迟（p50）：降至约 5–6ms，较此前基础设施的 25–40ms 大幅减少。
- 调用速度：提升 47.4%。
- 可用性：达到 99.998%。
- 日志交付：边缘函数日志交付速度提升 5 倍。
冷启动（Cold Start）同样经过优化。当请求到达一个未曾见过该函数的区域时，系统需获取相关镜像以准备运行环境。这种情况约占调用的 1.2%，平均耗时约为 9ms。
请求处理全流程解析
单个请求的处理路径如下：请求首先抵达边缘节点，随后转化为规范（Spec），路由至计算节点，最终传递给可能已存在或新建的 MicroVM。具体步骤取决于调用是“热”还是“冷”。
1. 请求抵达边缘节点
每个请求都会落在距离客户端最近的 Netlify 边缘节点。该节点终止 TLS 连接，并检查请求路径是否匹配部署中定义的 Edge Functions 路由。
若无匹配，请求按常规流向缓存和源服务器。若匹配成功，请求将通过互联网传输至边缘函数执行层，再返回给 Netlify。在新架构中，请求被直接转发至 Netlify 网络内部的计算节点。
2. 创建边缘功能服务
计算节点接收带有机器规格和服务 ID 的请求后，首先检查是否存在对应 ID 的服务。若存在，请求将被转发至该服务下的 MicroVM。
“服务”概念允许同一站点的多个 MicroVM 关联其边缘函数，并支持配置扩展参数。例如，系统可设定每个 MicroVM 在处理一定数量请求后关闭，以防止无限期运行；同样的参数也用于判断何时急切启动新的 MicroVM。
若计算节点上不存在该服务的实例，系统将创建服务，并检查磁盘上是否拥有机器规格所需的所有镜像。缺失的镜像将从边缘节点拉取并写入磁盘。这种按需加载机制确保仅在该区域有流量时才会拉取对应的边缘函数镜像。
3. 边缘节点编写规范
在请求分发前，边缘节点会为运行函数的机器编写规范。规范包含三个镜像：运行时镜像、平台镜像和边缘函数镜像，并设定 CPU、内存及连接限制。
标志物（Marker）随请求一同传输，其哈希值结合特定站点信息计算得出服务 ID。这实现了严格隔离：代码不同或环境变量不同的部署被视为不同服务，绝不共享 MicroVM。
这种隔离对于防止故障蔓延至关重要。即使某个潜在受损的部署逃逸出运行时，它也无法污染其他客户或计算层本身。相比之下，V8 Isolate 无法提供同等水平的隔离保护。
4. 选择计算节点
每个区域拥有一组计算节点。边缘节点通过一致性哈希选择服务节点，确保相同的服务始终落在同一节点上。这种粘性路由有助于保持 MicroVM 温暖，并使代码在首次读取后保留在磁盘和缓存中。
虽然将请求固定到单一节点能加速处理，但也可能导致热点形成。若某服务占据区域内大部分流量，单一节点负载过高会影响其他服务。为此，系统在超过特定阈值后会放松粘性，将服务分散到一小部分节点，以吸收突发流量。
一旦选定节点，若该节点曾服务过该函数，则无需重新引入代码；只有首个请求需承担此开销。
5. 启动 MicroVM
每个函数运行在独立的 Firecracker MicroVM 中。由于启动的是精简 Linux 环境而非完整操作系统，MicroVM 可在不到 1ms 内创建，p99 启动时间约为 2ms。
边缘函数文件以未压缩的 EROFS 镜像形式安装，并映射到内存中。这意味着虚拟机仅读取实际使用的捆绑部分，而非加载整个镜像。
MicroVM 启动后，JavaScript 服务器开始监听端口，系统随即对 MicroVM 进行快照。当边缘函数未被调用时，运行的 MicroVM 会缩减至零状态而非闲置。下次调用时，系统从快照恢复新的 MicroVM。由于快照采用内存映射技术，虚拟机可在无需等待整个快照读回内存的情况下开始执行。
虚拟机的生命周期管理（启动、快照、恢复、缩放到零）由 Unikraft 产品提供支持。Netlify 在迁移过程中与 Unikraft 紧密合作，以确保其满足高并发和特定流量模式的需求。
6. 运行与响应处理
多年的运营经验帮助团队最大化性能并增强调试能力。针对大规模场景下的各类问题（如虚拟交换机端口异常或 DNS 解析问题），新架构采取了多项措施：
- 确保计算节点运行本地 DNS 解析器。
- 扩大指标收集范围，记录启动时间、首个端口开启时间及用户代码启动时间。
- 设置断路器机制，以便快速重定向或退役故障计算节点。
在热实例中，整个请求路径增加约 6ms。Netlify 现已完全控制请求循环，可利用这些数据进一步优化从请求到达至响应返回的全过程。
弹性计算基础设施设计
构建此类系统需同时优化最终用户体验与发布弹性，即在快速推出变更的同时具备快速回滚的能力。
计算节点基于 Unikraft 发布的基础镜像构建并安装特定软件包。这些节点与边缘节点分离，以保持边缘节点的轻量化和高速度。
控制平面负责跟踪计算节点的存在与健康状态，边缘节点对该列表进行投票。部署过程采用蓝绿策略：新车队与正在运行的车队并行出现，仅在健康检查通过后接管流量。
建立计算基础设施需要与 Unikraft 团队密切协作，共同测试正确性、处理海量请求并为平台定制特定能力。
现状与未来展望
此次边缘计算架构的重建不仅提升了速度，更提供了一个更快、更具可控性的基础平台。目前，新架构已在生产环境中提供服务，价格不变且无需用户执行迁移步骤。
自主掌控计算资源意味着边缘函数的上限由 Netlify 定义。这使得以下三项长期受限的功能变得易于实现：
- NPM 包支持退出 Beta 阶段：真正的虚拟机和文件系统消除了此前 npm 包在边缘函数中运行时的诸多警告。
- 重新审视行动限制：此前基于 Isolate 的执行模型限制了每请求 50ms CPU、512MB 内存和 20MB 压缩代码。新架构有望突破这些瓶颈。
- 内部网络计算：任何依赖控制网络路径而非通过互联网接触第三方的操作现在均可在 Netlify 自己的网络内完成。
Netlify 表示工作尚未结束，团队正致力于解决此前无法触及的边缘计算局限性。
