无服务器-在Lambda函数中运行Express实例，好还是坏？

Question

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

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

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

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

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

1. 在迁移使用Express编写的现有应用程序的情况下，允许将应用程序缓慢分解为API Gateway端点。
2. 路由的内部处理，而不是依赖于API网关请求/响应模型（代理到Express路由器）。

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

一些促进这种方法的资源：

• Express.js和AWS Lambda ？？？无服务器的爱情故事（Slobodan Stojanovi？，freeCodeCamp）
• awslabs / aws-serverless-express（GitHub）
• 使用无服务器，Express和Node.js部署REST API（无服务器框架博客，Alex DeBrie）

Answer 1

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

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

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

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

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

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