Python bottle vs uwsgi/bottle vs nginx/uwsgi/bottle

Question

我正在开发一个基于 Python 的应用程序(HTTP -- REST 或 jsonrpc 接口(interface))，它将用于生产自动化测试环境。这将连接到运行所有测试脚本的 Java 客户端。即，无需人工访问(测试应用程序本身除外)。

我们希望将其部署在 Raspberry Pi 上，因此我希望它速度相对较快且占用空间小。它可能不会收到大量请求(在最大负载下，可能每秒几个)，但它应该能够运行并在很长一段时间内保持稳定。

由于 Bottle 的简单性(一个文件)，我决定将其作为一个框架。这是一场与 Flask 的较量。如果有人认为 Flask 可能更好，请告诉我原因。

我一直不太确定 Bottle 内置 HTTP 服务器的稳定性，所以我正在评估这三个选项:

1. 仅使用 Bottle -- 作为 http 服务器 + 应用程序
2. 在 uwsgi 之上使用 Bottle -- 使用 uwsgi 作为 HTTP 服务器
3. 将 Bottle 与 nginx/uwsgi 结合使用

问题:

• 如果我除了 Python/uwsgi 什么都不做，是否有任何理由将 nginx 添加到组合中？
• uwsgi/bottle(或 Flask)组合是否被视为生产就绪？
• 使用与 Bottle 的内置服务器不同的 HTTP 服务器，我是否可能会有所收获？

Answer 1

Flask 与 Bottle 对我来说归结为两点。

1. 应用程序有多简单。如果它非常简单，那么 bottle 是我的选择。如果没有，那么我得到了 Flask。 bottle 是单个文件这一事实使得部署非常简单，只需将文件包含在我们的源代码中即可。但是 bottle 是单个文件这一事实应该很好地表明它没有实现完整的 wsgi 规范及其所有边缘情况。
2. 该应用程序有什么作用。如果它必须渲染 Python->JSON 以外的任何东西，那么我会选择 Flask，因为它内置了对 Jinja2 的支持。如果我需要进行身份验证和/或授权，那么 Flask 已经有一些非常好的扩展来处理这些需求。如果我需要进行缓存，那么 Flask-Cache 存在并且只需最少的设置就可以很好地完成工作。我不完全确定什么可用于 Bottle 扩展，所以这可能仍然值得一看。

使用 bottle 的内置服务器的问题在于它将是单进程/单线程，这意味着您一次只能处理一个请求。

要处理该限制，您可以不按特定顺序执行以下任何操作。

1. Eventlet 的 wsgi 包装 bottle.app(单线程、非阻塞 I/O、单进程)
2. uwsgi 或 gunicorn(后者更简单)通常设置为单线程、多进程(worker)
3. nginx 在 uwsgi 之前。

如果您有静态 Assets 要提供，3 是最重要的，因为您可以直接使用 nginx 提供这些 Assets 。
2 真的很容易上手(尤其是 gunicorn)——虽然我大部分时间都使用 uwsgi，因为它具有更多的可配置性来处理我想要的一些事情。
1 真的很简单而且性能很好......而且没有外部配置或命令行标志需要记住。