Netlify 平台每日处理约十亿次 Edge Functions 调用，支撑着从 Sunweb 页面个性化到 Loto-Québec Cookie 路由等数十万站点的复杂任务。这些任务均运行在一个可随流量弹性扩展的全 JavaScript 运行时之上。
为应对毫秒级低延迟挑战，Netlify 团队在过去几个月与 Unikraft 紧密合作，彻底重构了 Edge Functions 底层基础设施。请求不再发送至托管执行服务，而是直接在 Netlify 自有边缘网络内的 MicroVM（微型虚拟机）中运行。这一变革使中位数速度提升约 5 倍，同时增强了安全性与可靠性，为边缘复杂计算开辟了新可能。
对开发者而言，Edge Functions 的使用方式保持不变：URL 导入、npm 包、Node 内置模块及本地开发体验均与此前一致。新架构仅在性能与韧性上实现了显著跃升。
核心性能数据
边缘函数直接面向用户，其响应速度至关重要。在新架构下，“热”调用（Warm Invocation，含路由、进入 MicroVM、执行及生成响应头）的性能表现如下：
- 中位数延迟（p50）：约为 5–6ms，而旧基础设施为 25–40ms；
- p99 延迟：速度加快 47.4%；
- 可用性：达到 99.998%；
- 日志传输：速度提升 5 倍。
此外，“冷”调用（Cold Invocation，即请求到达无缓存节点需获取镜像）约占所有调用的 1.2%，平均耗时约 9ms。
请求处理全流程解析
单个请求的处理路径经过精心优化，以确保低开销与高并发能力：
1. 请求到达边缘节点
请求首先抵达距离客户端最近的 Netlify 边缘节点，终止 TLS 连接并匹配路由规则。若匹配成功，在旧架构中请求需经由互联网往返外部服务；而在新架构中，请求直接转发至网络内部的计算节点。
2. 创建边缘函数服务
计算节点接收请求后，检查是否存在对应服务 ID。若存在，请求被送入关联的 MicroVM；若不存在，则创建新服务并检查磁盘镜像。缺失的镜像将从边缘节点获取并写入磁盘，确保仅拉取当前区域有流量的函数镜像。
3. 规范写入与服务隔离
边缘节点为每个请求写入包含运行时、平台及函数镜像的规范，并设定 CPU、内存限制。规范的哈希值与服务 ID 绑定，确保不同部署或环境变量的函数运行在独立的 MicroVM 中。这种强隔离机制防止了潜在受损部署污染其他客户或计算层，弥补了 V8 隔离机制的安全短板。
4. 计算节点选择与缓存策略
采用 Rendezvous Hashing 算法，同一服务的请求通常落在同一计算节点上，以维持 MicroVM 热状态并利用磁盘缓存。为避免单点热点资源耗尽，当流量超过阈值时，系统会自动将服务分散至一组节点，平衡负载并吸收突发流量。
5. MicroVM 启动与快照机制
每个函数运行在独立的 Firecracker MicroVM 中，启动时间低于 1ms（p99 约 2ms）。函数文件以未压缩 EROFS 镜像形式挂载，实现按需读取。当函数闲置时，MicroVM 缩容至零并生成内存映射快照；下次调用时直接从快照恢复，无需重新加载整个内存状态。这一生命周期管理由 Unikraft 提供支持。
6. 运行与响应
计算节点运行本地 DNS 解析器，并收集启动时间、端口打开时间等详细指标。通过多重熔断器机制，系统能及时重新路由或退役异常节点。整个流程完全在 Netlify 自有网络内闭环，热实例额外开销仅约 6ms。
构建高韧性计算基础设施
新架构兼顾终端用户体验与部署韧性。计算节点基于 Unikraft 基础镜像构建，与边缘节点解耦，允许独立扩展及使用不同实例类型。控制平面实时监控节点健康状态，通过灰度发布策略，新集群在健康后才接管流量，确保快速迭代与安全回滚。
正式上线与未来展望
目前，新架构已全面承载生产流量，定价不变且无需任何迁移操作。自有计算基础设施的建立打破了以往的限制，带来三项关键改进：
- npm 包支持正式化：依托真正的 VM 和文件系统，解决了原生二进制文件和运行时导入的限制，npm 包支持将从测试版走向成熟；
- 资源限制放宽：原有的 50ms CPU、512MB 内存等限制源于旧的隔离器模型，新架构为重新评估和提升这些上限提供了空间；
- 网络控制权增强：计算完全在自有网络内进行，使得构建不依赖互联网第三方路径的网络功能成为可能。
Netlify 表示，针对以往无法触及的限制与粗糙之处的优化工作仍在继续，更多更新值得期待。