无服务器-在Lambda函数中运行Express实例好不好？

Question

在学习无服务器框架时，我遇到了一些教程，展示了如何在Lambda中运行Express实例。在我看来，这似乎是一种过大的手段，违背了Lambda函数的目的。

该方法通常涉及在Lambda中运行Express实例，并将API网关请求代理到Express路由器以进行内部处理。

对我来说，简单的方法是仅在API网关中创建一个API，并将单个请求路由到Lambda进行处理。我想念什么吗？

考虑到Lambdas的执行时间为15分钟，就内存而言，仅分解Express实例不是很昂贵吗？此外，限制并发执行Lambda 100次会产生瓶颈，不是吗？在这种情况下，EC2实例是否会更合适？像这样使用Lambda似乎是一种矫kill过正。

在Lambda中运行Express实例的唯一两个好处是：

1. 如果要迁移用Express编写的现有应用程序，则可以将其缓慢分解为API Gateway端点。
2. 内部处理路由，而不是依赖于API网关请求/响应模型（代理Express路由器）。

如果我丢失了某些东西，这种方法有什么好处？

一些资源推广这种方法：

• Express.js and AWS Lambda — a serverless love story (Slobodan Stojanović, freeCodeCamp)
• awslabs/aws-serverless-express (GitHub)
• Deploy a REST API using Serverless, Express and Node.js (Alex DeBrie, Serverless Framework Blog)

Answer 1

您的大多数点都是有效的，在API网关后面的Lambda函数内部运行Express的确可以称为反模式。

应注意，初始化时间与 无关。虽然单个调用的执行时间限制为15分钟，但单个Lambda实例在启动后将处理多个请求。频繁调用的单个Lambda实例通常具有6到9个小时的生命周期，并且在闲置约30分钟后被处置。 （请注意，AWS不会公开披露这些参数，这些数字仅应用作参考）。不幸的是，谁愿意冷启动并吃了初始化延迟，则可能会在数千毫秒内获得额外的延迟。

如您所说，此方法的主要优点是为具有现有Express知识和应用程序的现有Node开发人员提供了迁移路径。从头开始开发应用程序并实施惯用的无服务器模式（例如，使用API​​网关路由）时，通常不应考虑这种方法。

只需重申一下，这种方法的主要缺点：

• 由于放弃了API网关功能（路由等），因此不必要的整体代码复杂度更高
• 更长的初始化时间导致更长的冷启动时间
• 由于依赖更多，代码占用量更大
• 由于丢失树状摇动而导致的代码占用量大/由于内部路由而造成的独立包装

P.S。这些天的主要竞争者可能不是专用的EC2实例，而是在Node.js中运行Express的Fargate容器。这种模式与无服务器模式具有许多相同的优点，同时又可以使现有的开发模式和工具保持完整。