Python瓶子vs uwsgi/瓶子vs nginx/uwsgi/b

Question

我正在开发一个基于Python的应用程序（HTTP--REST或jsonrpc接口），将在生产自动化测试环境中使用。这将连接到运行所有测试脚本的Java客户机。一、 e.不需要人工访问（除了测试应用程序本身）。

我们希望在覆盆子果酱上使用这个，所以我希望它比较快并且有一个小的脚印。它可能不会得到大量的请求（在最大负载下，可能是每秒几次），但是它应该能够运行并在很长一段时间内保持稳定。

我已经决定把瓶子作为一个框架，因为它很简单（一个文件）。这是一个tossup vs烧瓶。任何认为烧瓶更好的人，告诉我原因。

我对Bottle内置的HTTP服务器的稳定性有点不确定，所以我正在评估这三个选项：

1. 只使用瓶子--作为http服务器+应用程序
2. 在uwsgi上使用瓶子——将uwsgi用作HTTP服务器
3. 与nginx/uwsgi一起使用瓶子

问题：

• 如果我除了Python/uwsgi什么都不做，有没有理由将nginx添加到混合中？
• uwsgi/瓶（或烧瓶）组合是否视为生产就绪？
• 我是否有可能通过使用一个独立的HTTP服务器来获得任何好处？

Answer 1

瓶子和瓶子对我来说有几件事。

1. 这个应用程序有多简单。如果它非常简单，那么瓶子就是我的选择。如果没有，我就拿着烧瓶。瓶子是一个单独的文件这一事实使得在我们的源代码中包含该文件的部署变得非常简单。但是，bottle是一个单独的文件这一事实应该很好地表明它没有实现完整的wsgi规范及其所有的边缘案例。
2. 这个应用程序是做什么的。如果它需要呈现Python->；JSON以外的任何内容，那么我将使用Flask来构建它以支持Jinja2。如果我需要进行身份验证和/或授权，那么Flask已经有了一些很好的扩展来处理这些需求。如果我需要做缓存，再一次，烧瓶缓存存在，并做了一个很好的工作与最小的设置。我不完全确定什么是可用的瓶子延长明智，所以这可能仍然值得一看。

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

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

1. Eventlet让wsgi包装bottle.app（单线程、非阻塞I/O、单进程）
2. uwsgi或gunicorn（后者更简单），通常设置为单线程、多进程（workers）
3. nginx在uwsgi前面。

3是最重要的，如果你有静态资产，你想服务，因为你可以与nginx直接服务。
2非常容易使用（特别是gunicorn）-虽然我大部分时间都使用uwsgi，因为它有更多的可配置性来处理一些我想要的事情。
我真的很简单而且表现很好。。。另外，没有要记住的外部配置或命令行标志。