NGINX + Flask，没有 Gunicorn？

Question

我对此很陌生，但是通过将 gunicorn 与flask/werkzeug 的代码进行比较，我无法理解在nginx 和flask 之间插入gunicorn 的真正好处。想得到一些专家的意见。

就我目前所了解的而言，归结为将 gunicorn 与 werkzeug 的开发服务器进行比较。简而言之，我不明白为什么 werkzeug 的服务器被称为开发服务器，而 gunicorn 被认为是生产就绪的。我能想到的选择gunicorn而不是werkzeug的论点：

1. 表现。Gunicorn 基于 prefork 模型，而 werkzeug 可以为每个请求动态分离线程或进程。但是史蒂文斯在他的 UNP 书中有一个比较，而 prefork 在他的测试中并不是一个明显的赢家。在 linux 上分拆一个线程（而不是进程）应该相当便宜，不需要处理预分叉的进程池。所以对于 CPU 绑定的服务，python GIL 使得 werkzeug 的线程模型没有那么吸引人，但是对于 IO 绑定的服务，werkzeug 应该够好吗？
2. Gunicorn 支持 gevent/eventlet/tornado，而 werkzeug 不支持。但是由于 asyncio 正在成为 Python 3 的原生库，这些绿色线程库似乎不那么重要了？
3. 安全？再说一次，我不是这方面的专家，但 nginx 似乎已经是一个很好的捍卫者了？此外，与werkzeug 的开发服务器相比，gunicorn 在这方面似乎没有提供额外的保护。
4. SSL。Flask 和 werkzeug 服务器似乎无法处理这个问题。但是nginx已经可以处理了，所以flask不需要吗？
5. Unix 套接字。Werkzeug 的服务器似乎不处理 unix 套接字。因此，如果 nginx 需要使用 unix 套接字将流量转发到后端，无论是因为这是唯一的方法还是因为它是最有效的方法，那么对于 gunicorn 来说似乎是一个很好的论据。

上述理由是否成立？其他原因是什么？

顺便说一句，我已经阅读了SO post 1和SO post 2，但它们似乎还没有完全回答我的问题。

Answer 1

Werkzeug 可以使用多个进程，但会针对每个请求启动一个新进程。如果您将一些东西放在一起，彻底污染了其环境，以至于有必要在每个请求后丢弃该进程，那么这很好，但这并不是部署应用程序的最性能友好的方法。

Gunicorn（或者我更喜欢 uwsgi）提供的流程管理比 Werkzeug 提供的更加灵活。

不过，通过组合一个简单的应用程序，在一个实验中使用 werkzeug 将其设置为 4 个进程，在另一个实验中使用 Gunicorn 或 uwsgi，然后在向其投放流量时测量其性能，您可能会被说服。