我正在开发一个基于Python的应用程序(HTTP-REST或jsonrpc接口),它将用于生产自动化测试环境.这将连接到运行所有测试脚本的Java客户端.即,不需要人工访问(除了测试应用程序本身).
我们希望在Raspberry Pi上部署它,所以我希望它相对快速且占用空间小.它可能不会得到大量的请求(在最大负载,可能是每秒几个),但它应该能够运行并在很长一段时间内保持稳定.
由于其简单性(一个文件),我已经确定了Bottle作为框架.这是对Flask的折腾.任何认为Flask可能更好的人,让我知道原因.
我对Bottle的内置HTTP服务器的稳定性有点不确定,所以我正在评估这三个选项：
>仅使用瓶子 – 作为http服务器应用程序
>在uwsgi之上使用Bottle – 使用uwsgi作为HTTP服务器
>使用Nginx / uwsgi瓶子
问题：
>如果我没有做除Python / uwsgi之外的任何事情,有没有理由在混合中添加Nginx？
> uwsgi / bottle(或Flask)组合是否会被视为生产就绪？
>我是否可能通过使用Bottle内置的单独的HTTP服务器获得任何收益？
>应用程序有多简单.如果它很简单,那么瓶子就是我的选择.如果没有,那我就得到了Flask.瓶子是单个文件这一事实使得只需将文件包含在我们的源代码中就可以非常简单地进行部署.但是瓶子是单个文件的事实应该是一个非常好的迹象,表明它没有实现完整的wsgi规范及其所有边缘情况.
>该应用程序做了什么.如果它必须渲染除了Python-> JSON以外的任何东西,那么我会使用Flask来内置对Jinja2的支持.如果我需要进行身份验证和/或授权,那么Flask已经有一些非常好的扩展来处理这些要求.如果我需要进行缓存,Flask-Cache仍然存在,并且在最小化设置的情况下做得非常好.我不完全确定什么可用于瓶子延伸,因此可能仍值得一看.
使用瓶子内置服务器的问题在于它将是单进程/单线程,这意味着您一次只能处理一个请求.
要处理该限制,您可以按顺序执行以下任何操作.
> Eventlet的wsgi包装bottle.app(单线程,非阻塞I / O,单个进程)
> uwsgi或gunicorn(后者更简单),其中大多数设置为单线程,多进程(工作人员)
>在uwsgi面前的Nginx.
如果您有想要提供的静态资产,那么3是最重要的,因为您可以直接为Nginx提供服务.
2很容易上手(尤其是gunicorn) – 虽然我大多数时候都使用uwsgi,因为它有更多的可配置性来处理我想要的东西.
1非常简单并且运行良好……而且没有外部配置或命令行标记要记住.
