精华速览

亚马逊云科技近日推出 Lambda Web Functions，允许开发者将基于 Express、Hono、Fastify、Next.js 等 Node.js 框架构建的标准 HTTP 服务器直接部署到 Lambda，无需适配层。新函数支持并发请求与流式响应，计费依据活跃 CPU 时间和内存，而非等待下游服务的时间；多区域路由可将请求分发至最近区域，预热环境可同时处理多个并发请求以降低冷启动影响。原有 Lambda 函数更名为 Lambda Event Functions，无需改动。该服务目前仅支持 Node.js，已在北弗吉尼亚、俄亥俄、俄勒冈、东京和爱尔兰五个区域推出。社区讨论认为，部分工作负载可绕过 API Gateway，但也带来同步与互斥等新编程问题。

要点透视

  • Lambda Web Functions 支持 Express、Hono、Fastify、Next.js 等 Node.js 框架，开发者只需让服务器监听标准端口，通过一条命令或 CloudFormation 即可部署，无需编写适配器。
  • 新函数支持并发 HTTP 请求和流式响应，单个预热执行环境可同时处理多个请求，官方称可显著减少冷启动；计费基于活跃 CPU 时间和内存，等待数据库或下游 API 期间不计 CPU 时间。
  • 端点默认使用 Lambda 提供的域名；如需自定义域名、边缘缓存或 AWS WAF，可在前端部署 Amazon CloudFront 并将 Lambda Web Functions 作为源站。
  • 现有 Lambda 函数更名为 Lambda Event Functions，无须任何改动；Lambda Web Functions 目前仅支持 Node.js，Python、Java、.NET 仍通过传统 Lambda 函数使用。
  • 该服务已在北弗吉尼亚、俄亥俄、俄勒冈、东京和爱尔兰五个区域推出，面向全栈 Web 应用、REST 与 GraphQL API、可独立扩展的微服务以及服务器端渲染和流式 AI 输出等 HTTP 工作负载。
  • 社区反馈总体积极，有用户指出许多工作负载现在可以完全绕过 API Gateway，Lambda 的 HTTP 编程模型从“一次调用对应一个请求”转向并发处理，开发者需开始关注同步和互斥锁问题。
  • Google Cloud Run 和 Azure Container Apps 同样支持无适配层的 Web 应用、缩容至零和可配置并发，Lambda Web Functions 面临同类无服务器容器方案的直接对比。
  • 今年早些时候亚马逊云科技还推出 Lambda MicroVM，为运行不可信代码或用户生成代码提供隔离的有状态沙箱环境，并允许客户自行管理生命周期。

文章拆解

Lambda Web Functions 的推出，实质上是 AWS 对 Lambda 编程模型的一次重要扩展。过去 Lambda 以事件驱动为核心，一次调用对应一个请求，开发者若想运行 Express 等传统 Web 框架，往往需要借助适配层或额外托管服务。新方案让标准 Node.js HTTP 服务器直接跑在 Lambda 上，并由平台接管扩缩容、多区域分发和 HTTPS 端点，这降低了将传统 Web 应用迁移到无服务器架构的改造成本。

从计费逻辑看，按活跃 CPU 时间和内存计费、等待下游服务期间不计 CPU 时间，对 I/O 密集型负载较为友好。服务器端渲染、API 后端和流式 AI 推理等场景通常有大量时间花在等待数据库或外部接口上，这种计费方式可能比按整个执行时长计费更经济。但内存按执行环境整个生命周期计费，意味着长驻的预热环境仍会产生内存成本，实际节省幅度取决于负载特征，尚待具体场景验证。

对用户和行业而言，最直接的变化是 API Gateway 在部分 HTTP 工作负载中的必要性下降。社区讨论已指出，许多场景可以完全绕过 API Gateway，这简化了架构，但也把并发请求下的同步、互斥和状态管理问题交还给开发者。原先“一次调用一个请求”的模型天然隔离了请求，并发之后，共享资源竞争和线程安全问题需要重新审视。

值得关注的变量包括：Node.js 之外的语言支持何时跟进，这决定该功能能否覆盖更广泛的存量工作负载；五个区域的可用范围是否满足全球业务部署需求；以及与 Cloud Run、Azure Container Apps 等竞品在冷启动、并发控制和定价上的实际差异。潜在风险在于，开发者可能低估并发模型带来的编程复杂度，或在未充分评估内存计费的情况下产生预期外成本。此外，绕过 API Gateway 后，认证、限流和可观测性等职责如何重新划分，也需要在架构设计中明确。

查看原文