WSGI 容器与 AWS Lambda 相关吗？

Question

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

\n

Flask 文档说：

\n

\n

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

\n

\n

在独立服务器上，Python 是单线程的（全局解释器锁（GIL）等），因此如果没有应有的谨慎和注意，就无法很好地处理多个请求。

\n

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

\n

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

\n

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

\n

\n
• 成本
\n
• 资源（例如数据库连接）
\n
• 虫子
\n
• 启动性能
\n
• 每个请求的开销
\n

\n

Answer 1

当文档谈到“Flask 的内置服务器”时，它指的是运行命令时获得的服务器flask run（或者在较旧的应用程序中运行命令，例如python my_application.py在主函数中使用一行命令，如app.run()）。

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

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