NGINX + Flask，没有Gunicorn？

Question

我对此并不陌生，但是通过将 gunicorn 的代码与 flask/werkzeug 进行比较，我无法理解在 nginx 和 flask 之间插入 gunicorn 的真正好处。 想请教一下这方面的专家意见。

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

1. 表现。 Gunicorn 基于 prefork model，而 werkzeug 可以为每个请求动态分离一个线程或进程。 但是 Stevens 在他的 UNP 书中进行了比较，prefork 在他的测试中并不是一个明显的赢家。 在 linux 上分离一个线程（不是进程）应该相当便宜，不需要处理预分叉的进程池。 因此对于 CPU 绑定服务，python GIL 使 werkzeug 的线程 model 不那么有吸引力，但是对于 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 sockets 将流量转发到后端，无论是因为它是唯一的方式还是因为它是最有效的方式，那么对于 gunicorn 来说，这似乎是一个很好的论据。

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

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

Answer 1

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

gunicorn（或我更喜欢的 uwsgi）提供的流程管理比 Werkzeug 提供的要灵活得多。

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