在学习无服务器框架时，我遇到了几个教程，展示了如何在 Lambda 中运行 Express 实例。在我看来，这似乎是一种矫枉过正，违背了 Lambda 函数的目的。
该方法通常涉及在 Lambda 中运行 Express 实例并将 API 网关请求代理到 Express 路由器以进行内部处理。
对我来说，简单的方法是在 API Gateway 中创建一个 API，并将单个请求路由到 Lambda 进行处理。我错过了什么吗？
考虑到 Lambdas 的执行时间是 15 分钟，就内存而言，仅仅启动 Express 实例是不是非常昂贵？此外，限制为 100 个并发 Lambda 执行会造成瓶颈，不是吗？ EC2 实例不是更适合这种情况吗？像这样使用 Lambda 似乎有点矫枉过正。
我在 Lambda 中运行 Express 实例的唯一两个好处是:
如果我遗漏了什么，这种方法有什么好处？
一些推广这种方法的资源:
最佳答案
您的大部分观点都是有效的，它确实可以称为反模式，以在 API 网关后面的 Lambda 函数中运行 Express。
应该注意的是，初始化时间不是那么重要。虽然单个调用的执行时间上限为 15 分钟，但单个 Lambda 实例在启动后将处理多个请求。频繁调用的单个 Lambda 实例通常有 6 到 9 个小时的生命周期，并在大约 30 分钟不事件时被处理掉。 (请注意，AWS 不会公开披露这些参数，这些数字只能用作大致引用)。然而，谁是获得冷启动并吃掉初始化延迟的不幸者，可能会获得数千毫秒的额外延迟。
正如您所说，这种方法的唯一主要优点是，为具有现有 Express 知识和应用程序的现有 Node 开发人员提供了迁移路径。在从头开发应用程序时，您通常不应该考虑这种方法，而是实现惯用的无服务器模式(例如，利用 API 网关路由)。
重申一下，这种方法的主要缺点是:
附言现在的主要竞争者可能不是专用的 EC2 实例，而是在 Node.js 中运行 Express 的 Fargate 容器。这种模式具有许多与 Serverless 相同的好处，同时保持现有的开发模式和工具在很大程度上保持不变。
关于aws-lambda - 无服务器 - 在 Lambda 函数中运行 Express 实例，好还是坏？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55454539/