WSGI 容器是否与 AWS Lambda 相关？

Question

我有一个基于 Flask 的 Web 应用程序，它通过 Zappa 部署到 AWS Lambda。一切都很好。

Flask documentation 说：

虽然轻量级且易于使用，但 Flask 的内置服务器不适合生产，因为它不能很好地扩展。此处记录了一些可用于在生产中正确运行 Flask 的选项。

在独立服务器上，Python 是单线程的（全局解释器锁 (GIL) 等），因此在没有应有的注意和注意的情况下不能很好地处理多个请求。

在 AWS Lambda（可能还有其他 FaaS 基础设施）上，每个 HTTP 请求都会获得一个单独的 Python 实例，因此 GIL 不是问题，Lambda 通过使用多个函数调用来处理扩展。

因此，在 AWS Lambda 上运行时，是否强烈推荐使用 WGSI 容器（Gunicorn、uWGSI 等）？为什么或为什么不？

我猜想可能相关的一些因素包括：

• 费用
• 资源（例如数据库连接）
• 错误
• 启动性能
• 每个请求的开销

Answer 1

当文档谈到“Flask 的内置服务器”时，它是在谈论运行命令 flask run 时获得的服务器（或者在 older applications running 中，类似 python my_application.py 的命令，在 main 中有一行功能类似于app.run())。

当您在 Lambda 上运行 Flask（使用 Zappa 或其他解决方案，如 aws-wsgi 或 serverless-wsgi）时，您根本没有使用 Flask 的内置服务器或任何服务器；包装器代码（在 Zappa 或其他任何东西中）正在将 lambda 事件转换为对您的 WSGI 应用程序的调用。

由于没有实际的 WSGI 服务器，因此无法使用 Gunicorn、uWGSI 等（嗯，有可能，但会非常复杂）。