devgo.cn核心观点
- Lambda 网络团队用近十年时间做「隐形工程」：优化 iptables 规则、绕开内核锁竞争、重写报文头——成功时无人察觉，正如在飞行中把螺旋桨飞机改装成喷气式。
- 主攻目标是 VPC 冷启动：Lambda 迁移到 Firecracker 微 VM 后冷启动从 10 秒+ 降到 1 秒内，但为每个函数建立通往客户 VPC 的 Geneve 隧道仍需约 300ms。
- 瓶颈的根因很隐蔽：Geneve 隧道需要设置 VNI（虚拟网络标识符），而 VNI 要到函数初始化才有，Linux 又不允许建隧后修改——导致每个包都要走一遍隧道重建。
- 故事的价值不在于单一优化，而在于「网络拓扑即设计决策」：在共享硬件上跑数百万微 VM，每个设备的每次新增都有延迟、CPU、内存代价，且随密度成倍放大。
内容精讲
AWS 的大部分基础设施改进都在「看不见的地方」发生：工程团队花数年时间增量重建数百万客户依赖的系统，同时让系统满负荷运行、不停机。这个过程的比喻是「在飞行中把螺旋桨飞机改装成喷气式」——犯一个错飞机就掉下去，但做对了，没人会注意。优化 iptables 规则、绕开内核锁竞争、重写包头部——这类工作的成功是沉默的，回报是「你知道它比上周更好了，下一支团队不会再撞上你刚拆掉的约束」。
**网络拓扑为什么是地基。** 网络拓扑是设备、连接和规则如何决定数据在系统各点之间流动的安排——可以理解为管道系统。它决定存在哪些路径、流量如何路由、租户间如何隔离、数据包从 A 到 B 走哪条路。云环境里的管道是软件定义的：虚拟设备、隧道、路由规则和数据包过滤器，而不是物理线缆和交换机。跑单个应用时拓扑微不足道；但当你在共享硬件上运行数百万个轻量虚拟机、每个都要独立网络路径、独立安全边界、还要能连客户的私有网络时，拓扑就成了最重大的设计决策之一——每加一台设备、每条规则、每条隧道都有延迟、CPU、内存成本，而且这些成本随密度成倍放大。
**VPC 冷启动问题。** Lambda 冷启动发生在没有温热执行环境、需要新建微 VM 来处理调用时：分配微 VM、下载客户代码、启动语言运行时、跑初始化代码，全部发生在调用负载到达 handler 之前。VPC 冷启动在此基础上还要完成额外的网络配置——让微 VM 能到达客户私有网络里的资源。这正是 VPC 冷启动历史上慢于非 VPC 冷启动的原因。2019 年 Lambda 迁移到 Firecracker 微 VM 后，冷启动从超过 10 秒降到 1 秒以内；但建立 Geneve 隧道（把函数流量路由到正确的客户 VPC）加上 DHCP，仍要消耗约 300 毫秒。对部分工作负载这个代价可接受，但对响应性应用是实打实的障碍，而且实验显示随着微 VM 密度上升，尾延迟从几百毫秒涨到数秒。
**根因比表面更深。** 团队对全链路做了插桩，在并发、密度、创建与销毁操作组合上做了一系列实验，发现主导因素是隧道创建本身。每个穿过 Geneve 隧道的包都携带一个 VNI，而 VNI 必须在隧道创建时设置——在 Lambda 的场景里，VNI 直到函数初始化才可用，而 Linux 不提供建隧后更新 VNI 的办法。写一个自定义内核驱动曾是选项之一，但长期维护 Lambda 专属补丁的代价不可接受。解决方案的细节固然精彩，但更值得记录的是方法：用测量定位真实瓶颈、理解「为什么 Linux 不做 X」的系统约束、再找不破坏上游兼容性的路径。
**为什么这类工程值得单独写。** 大型发布（如 S3 Files）解决的是看得见的客户问题，而这批网络工程师做的是「把不可能变得可能」的底层工作——让延迟敏感工作负载能跑在 serverless 函数里这件事，十年前被认为是做不到的。拓扑上的每一次渐进优化，都在重构 AWS 能构建什么的天花板。对任何大型系统，这条经验都成立：最有价值的工作常常发生在客户看不见的层，而它的衡量标准不是「上了头条」，而是「下一支团队不再受制于你刚拆除的约束」。
阅读价值
对平台与基础设施工程师，这是一个深度案例：从指标异常到根因定位（VNI 与 Linux 约束）的完整排查路径可作方法论；对 Serverless 使用者，它解释了 VPC 冷启动的历史与现状，也示范了「把延迟敏感负载搬进 serverless」背后要做的隐形功课。
内容与图片版权归原作者所有 · 原文: https://www.allthingsdistributed.com/2026/04/the-invisible-engineering-behind-lambdas-network.html?utm_campaign=inbound&utm_source=rss