python - NGINX + Flask，没有 Gunicorn？

Question

我对此很陌生，但是通过将 gunicorn 与flask/werkzeug 的代码进行比较，我无法理解在nginx 和flask 之间插入gunicorn 的真正好处。想得到一些专家的意见。
就我目前所了解的而言，归结为将 gunicorn 与 werkzeug 的开发服务器进行比较。简而言之，我不明白为什么 werkzeug 的服务器被称为开发服务器，而 gunicorn 被认为是生产就绪的。我能想到的选择gunicorn而不是werkzeug的论点:

表现。 Gunicorn 基于 prefork 模型，而 werkzeug 可以为每个请求动态分离线程或进程。但是史蒂文斯在他的 UNP 书中有一个比较，而 prefork 在他的测试中并不是一个明显的赢家。在 linux 上分拆一个线程(而不是进程)应该相当便宜，不需要处理预 fork 的进程池。所以对于 CPU 绑定(bind)的服务，python GIL 使得 werkzeug 的线程模型没有那么吸引人，但是对于 IO 绑定(bind)的服务，werkzeug 应该够好吗？

Gunicorn 支持 gevent/eventlet/tornado，而 werkzeug 不支持。但是由于 asyncio 正在成为 Python 3 的原生库，这些绿色线程库似乎不那么重要了？

安全？再说一次，我不是这方面的专家，但 nginx 似乎已经是一个很好的捍卫者了？此外，与werkzeug 的开发服务器相比，gunicorn 在这方面似乎没有提供额外的保护。

SSL。 Flask 和 werkzeug 服务器似乎无法处理这个问题。但是nginx已经可以处理了，所以flask不需要吗？

Unix 套接字。 Werkzeug 的服务器似乎不处理 unix 套接字。因此，如果 nginx 需要使用 unix 套接字将流量转发到后端，无论是因为这是唯一的方法还是因为它是最有效的方法，那么对于 gunicorn 来说似乎是一个很好的论据。

上述理由是否成立？其他原因是什么？
顺便说一句，我已经阅读了 SO post 1和 SO post 2但他们似乎还没有完全回答我的问题。

Answer 1

Werkzeug 可以使用多个进程，但每次请求都会启动一个新进程。如果您将一些东西放在一起会彻底污染其环境，以至于在每次请求后丢弃进程是必要的，那太好了，但这并不是部署应用程序的最性能友好的方法。
gunicorn(或我更喜欢的 uwsgi)提供的流程管理比 Werkzeug 提供的要灵活得多。
不过，您可能会相信，通过将一个简单的应用程序放在一起，将其设置为 4 个进程，一个实验使用 werkzeug，另一个使用 gunicorn 或 uwsgi，然后在您向它转换流量时测量其性能。