中文精炼导读
核心观点
- Werner Vogels 撰文讲述 Lambda 网络团队历时近十年的"隐形工程"：他们逐步重构 Lambda 的网络拓扑，把 VPC 冷启动里的 Geneve 隧道延迟从 150 毫秒降到 200 微秒（降幅约 750 倍），并最终把网络容量扩展了 20 倍——整个过程没有任何产品发布或新闻稿，成功是无声的。
- 大多数 AWS 基础设施改进都在"隐形"地进行：工程团队花数年时间增量重建数百万客户依赖的系统，系统却全程满负荷运行不中断——Marc Olson 把这种工作比作"飞机飞行中把螺旋桨飞机改装成喷气式飞机"，一个错误飞机就坠毁，做对了却没人注意。
- 核心技术决策是在 DPDK 与 eBPF 之间选择 eBPF：当时鲜有人用（Cilium 等项目正在证明其规模化价值），它开销更低、且让团队掌控自己的基础设施——用 eBPF 程序在出口/入口改写 Geneve 头部，把昂贵的隧道创建移出热路径。
- 解决 SnapStart 带来的双拓扑问题是另一个里程碑：不再按需创建网络，而是在 worker 启动时一次性预创建全部 4,000 个网络——Colm MacCárthaigh 称之为"恒功"（constant work），像咖啡壶无论来三个人还是三百人都保持几百杯热。
- 这项工作的沉淀被封装成服务，DSQL 团队直接安装在自己的 worker 上，自动获得 Lambda 级别的网络密度——"下一次团队不会再撞上你刚移除的约束"，这正是隐形工程的价值。
内容精讲
文章开头用 xkcd 漫画和一个比喻点出主题：把螺旋桨飞机改装成喷气式飞机要在飞行中完成，一个错误飞机就坠毁，做对了却没人注意。AWS 大多数基础设施改进就是这样——团队花数年增量重建系统，系统继续满负荷运行。Vogels 明确区分了两类工作：像 S3 Files 这样解决可见客户问题的大型发布，和同样令人印象深刻、却在客户视野之外安静发生的工作。Lambda 网络团队的故事属于后者。
故事从网络拓扑讲起。网络拓扑是设备、连接与规则的安排，决定数据如何在系统各点之间流动——可以把它想成管道：定义了哪些路径存在、流量如何路由、租户之间如何隔离、数据包从 A 到 B 要经历什么。在云环境里，这种管道是软件定义的——由虚拟设备、隧道、路由规则和数据包过滤器构成，而非物理线缆与交换机。跑单应用单机时拓扑微不足道；但在共享硬件上跑数百万轻量虚拟机、每台都要隔离网络路径、安全边界和连接客户私有网络的能力时，拓扑就成了你做的最重大的设计决策之一——每加一个设备、一条规则、一条隧道都有延迟、CPU 和内存成本，且这些成本随密度倍增。Lambda 的起点是一个"服务非 VPC 函数很好、但连接客户 VPC 时真有代价"的拓扑。
核心痛点是 VPC 冷启动。冷启动发生在 Lambda 必须新建 micro VM 来处理调用、且没有现成的热执行环境时——包括分配 micro VM、下载客户代码、启动语言运行时、运行客户初始化代码，全在调用负载到达 handler 之前。VPC 冷启动还要加上"microVM 到达客户私有网络内资源"所需的额外网络设置，这就是它历史上比非 VPC 冷启动慢的原因。2019 年 Lambda 迁移到 Firecracker microVM 时，冷启动开销从超过 10 秒降到 1 秒以内；但设置路由 Lambda 流量到正确客户 VPC 的 Geneve 隧道、加上 DHCP，仍要消耗 300 毫秒。对某些负载这是可接受的折衷，但对响应式应用是真实障碍，而且实验表明密度提高时会更糟：团队追踪 VPC 与非 VPC 冷启动指标，发现在更高 microVM 密度下尾部延迟从几百毫秒涨到几秒。根因并不明显，他们给全路径加探针做了一连串实验，发现主导贡献者是隧道创建本身：每个穿过 Geneve 隧道的包都携带一个 VNI（虚拟网络标识符），VNI 必须在隧道创建时设置——而 Lambda 的 VNI 要等函数初始化才可用，Linux 又不提供创建后更新它的方式。写自定义内核驱动曾是个选项，但长期维护 Lambda 专属的 upstream 补丁是他们不愿接受的交易。真正的选择在 DPDK 与 eBPF 之间：eBPF 是较少人走的路，但 Cilium 等项目正在证明它在规模上的价值；团队将成为 Lambda 内最早在生产中使用它的人之一，还要面对它能否扛住规模、能否通过安全审查的真实疑问——但它比 DPDK 开销更低，更重要的是让团队掌控自己的基础设施。他们做了概念验证：池化时用"哑" VNI 创建隧道，函数初始化拿到真实 VNI 后，eBPF 程序把哑 VNI 映射到真实 VNI，出口改写 Geneve 头部、入口反向还原。Geneve 隧道延迟从 150 毫秒降到 200 微秒，昂贵的隧道创建彻底移出热路径——还顺带移除了在每个 worker 上塞更多 microVM 的根本障碍、减少冷启动突发时的 CPU 发热，提升了平台吸收流量峰值和处理可用区撤离的能力。
隧道延迟不再是瓶颈后，团队又面对 Lambda SnapStart 带来的新挑战。SnapStart 不再逐个从零初始化函数，而是对已初始化的执行环境拍快照、克隆它服务多个并发调用——初始化只发生在快照时刻而非每次调用，冷启动时间大幅下降（尤其初始化开销最高的 Java 负载）。但每个克隆都需要自己的隔离网络命名空间（tap、bridge、veth、tunnel 设备），且必须在 VM 启动前就绪——原设计是按需创建，SnapStart 则需要预创建、随时可挂接。每台宿主机最多容纳 2,500 个 microVM；SnapStart 上线时两种拓扑跑在同一批主机上，2,500 个槽位被拆成 200（快照拓扑）与 2,300（按需）。200 上限是刻意的交易：这些网络每个 VM 需要两倍的 Linux 网络设备，创建销毁成本随密度增长。团队估计有一年窗口，于是选择先用低上限上线、之后再回来解决扩展问题。但 Lambda 正朝"所有负载都用快照 VM"方向走，两个拓扑长期并存是他们不愿交的税——必须收敛并把快照网络从 200 扩到 2,500。
于是一个接一个地拔瓶颈。首先撞上的是网络创建本身：Linux 网络设备（tap、veth、namespace）创建在密度升高时变慢，创建与销毁并行更糟——每次创建新设备，Linux 都要遍历现有设备列表，第 N+1 个网络的创建成本随 N 增长。最佳解法是"干脆不再按需创建"：把所有成本移到 worker 初始化阶段，在 worker 开始服务任何请求前一次性预创建全部 4,000 个网络。表面上"花三分钟创建网络才能干活"听起来不稳，但 Lambda worker 的更换频率远低于 microVM——"一次性在启动时吸收成本，而不是运行期间持续支付"，函数执行期间的 CPU 消耗消失了。这正符合 Colm MacCárthaigh 说的"恒功"：无论负载多少都做相同的工作，像咖啡壶无论来三个人还是三百人都保持几百杯热——worker 总是支付相同的启动成本。这只是其中一层，还有 NAT 实现等其他瓶颈。
文章最后讲述了这项工作的沉淀：团队把完整网络栈封装成一个服务（设备管理、防火墙规则、NAT 转换、释放后安全复用的卫生处理），DSQL 可以直接在自己的 worker 上安装运行，需要时请求网络、用完释放；Lambda 拥有并持续发布新版本，每项优化自动流向 DSQL——为 DSQL 团队省下数月的工程时间，第一天就拥有 Lambda 级别的网络密度。结尾回归主题：AWS 建的绝大部分东西没人会看见——客户部署一个连接 VPC 的 Lambda 函数、毫秒级启动，不会去想底下的 Geneve 隧道、iptables 规则和被绕过的内核互斥锁，他们也不该想。这个持续近十年的努力没有产品发布、没有新闻稿，团队收敛了两个拓扑、消除每层瓶颈、容量扩展 20 倍——完成后函数启动更快、运行更高效，多数客户从未注意到。Vogels 引用亚里士多德的"Arete"（卓越）：优化 iptables 规则不会上头条，但"即使没人看着，也把事做对"的专业骄傲、那些彻夜不倒的隐形系统、干净的部署、不被察觉的回滚——这定义了最好的建造者与团队。
阅读价值
适合对云基础设施、网络工程与"大型系统演进方法论"感兴趣的工程师和技术管理者：文章把一个"网络拓扑重构"的技术故事（Geneve/eBPF、恒功设计、双拓扑收敛）与"隐形工程"的价值论结合起来，既有可落地的技术决策（eBPF vs DPDK、预创建 vs 按需创建），也展现了 AWS 内部长期演进系统的工程文化与沉淀方式；对做平台基础设施的人尤其有共鸣。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.allthingsdistributed.com/2026/04/the-invisible-engineering-behind-lambdas-network.html?utm_campaign=inbound&utm_source=rss