边缘功能速度提高 5 倍：V8 隔离至 Firecracker MicroVM

Netlify 每天运行大约十亿个 Edge Functions——Sunweb 个性化页面、基于 cookie 检查的 Loto-Québec 路由流量，以及数十万个其他网站，执行从个性化到路由再到身份验证的所有操作。所有这些都在完整的 JavaScript 运行时上运行，该运行时可根据客户的流量进行扩展。这带来了重大的技术挑战，因为我们努力使延迟尽可能低。为了每秒运行数万个，有时是数十万个边缘功能，我们需要处理每个请求，正确路由它，分配计算能力，并启动我们的平台代码和客户的代码。所有这一切都必须在几毫秒内发生。在过去的几个月里，我们的团队与 Unikraft 团队密切合作，重建了 Edge Functions 背后的基础设施，Unikraft 撰写了他们的经验。过去，请求发送到托管执行服务。如今，它们在我们自己的边缘网络内的 MicroVM 上运行——平均速度大约快 5 倍。这种转变还提高了安全性和可靠性，并为在边缘运行复杂计算提供了更多可能性。这不会改变 Edge Functions 的编写或使用方式——URL 导入、npm 包、Node 内置、netlify.toml 声明、本地开发——所有这些都与以前一样工作。现在速度更快、更有弹性。在本文中，我们希望分享有关新架构的更多信息，以及我们在构建能够以低性能开销提供大容量服务的新计算平台方面的经验。数字，第一个边缘函数在站点前面针对与其匹配的每个请求运行。所花费的时间就是客户等待的时间，因此这里的毫秒比几乎其他任何地方都更重要。热调用（路由到计算节点、进入 MicroVM、运行函数、生成响应标头）现在的成本：中值 (p50) 约为 5–6 毫秒，低于我们之前基础设施上的 25–40 毫秒 p99 调用速度加快 47.4% 可用性 99.998% 边缘函数日志传送速度加快 5 倍 冷调用也值得一提。当请求到达之前没有计算节点见过的区域时，它需要先获取相关图像，然后才能运行任何内容。这种情况发生在大约 1.2% 的调用中，平均需要大约 9 毫秒。请求期间发生的情况接下来是单个请求所采取的路径（按顺序）：它到达边缘节点，转换为规范，路由到计算节点，然后根据它是冷调用还是热调用传递给可能已经存在或可能不存在的 MicroVM。请求到达边缘节点 每个请求都会到达距离客户端最近的 Netlify 边缘节点。节点终止 TLS 连接，并根据该部署的 Edge Functions 路由检查请求路径。如果没有匹配的内容，请求将像往常一样继续到缓存和源。如果路由确实匹配，则这就是请求离开我们网络的点。使用我们的旧基础设施，它通过互联网发出，运行边缘功能，然后返回给我们传递。使用新的计算平台，请求将被转发到我们网络内的计算节点。创建边缘功能服务 当计算节点收到带有机器规范和服务 ID 的请求时，它首先检查具有该 ID 的服务是否已存在。如果是，它会将请求转发到服务中，以便将其发送到 MicroVM 中。服务允许我们拥有与同一站点的边缘功能关联的多个 MicroVM，并允许我们配置何时扩展和扩展 MicroVM 的参数。例如，我们将每个服务配置为仅允许 MicroVM 在关闭之前处理固定数量的请求，以避免 MicroVM 无限期运行。我们使用相同的参数来了解何时急切地启动另一个 MicroVM，以应对其中一个 MicroVM 的关闭。如果计算节点上尚不存在用于站点边缘功能的服务，则会创建一个服务，然后我们检查磁盘上是否拥有机器规范中的所有图像。如果有任何丢失，它们将从边缘节点获取并写入磁盘。这种方法意味着我们只获取在该区域接收流量的边缘函数图像。边缘节点编写规范 在请求到达任何地方之前，边缘节点会为将运行功能的机器编写规范。该规范命名了三个图像：运行时、我们的平台图像和边缘函数图像。它还设置 CPU、内存和连接限制。对于每个请求，规范都会随请求而变化。其哈希值和特定于站点的信息经过计算后成为服务 ID。这允许隔离，因为具有不同代码或不同环境变量的两个部署是不同的服务，并且它们从不共享 MicroVM。这种隔离对于我们不希望发生的故障最为重要。可能受到损害的部署在 sepa 中运行