nginx 和 gunicorn 和 flask 的关系？

简单说下几种部署方式
Flask 内置 WebServer + Flask App = 弱鸡版本的 Server, 单进程（单 worker) / 失败挂掉 / 不易 Scale

Gunicorn + Flask App= 多进程（多 worker) / 多线程 / 失败自动帮你重启 Worker / 可简单Scale

多 Nginx + 多 Gunicorn + Flask App = 小型多实例 Web 应用，一般也会给 gunicorn 挂 supervisor在生产环境中：一般都是请求的走向都是 Nginx->gunicorn->flask/django app

1、Flask 作为一个 Web 框架，内置了一个 webserver, 但这自带的 Server 到底能不能用？显然是可以的，但不要这么做。
2、Gunicorn 作为 Server 相对而言可以有什么提升。第一个问题，Flask 作为一个 Web 框架，内置了一个 webserver, 但这自带的 Server 到底能不能用？
3、nginx和Gunicorn区别是什么?

第一个问题，

Flask 作为一个 Web 框架，内置了一个 webserver, 但这自带的 Server 到底能不能用？
很显然，内置的 webserver 是能用的。但不适合放在生产环境。这个 server 本来就是给开发者用的。框架本身并不提供生产环境的 web 服务器，SpringBoot 这种内置 Tomcat 生产级服务器 是例外。
我们查看 flask 代码的时候也可以看到这个 WebServer 的名称也叫做 run_simple , too simple 的东西往往不太适合生产。

来看看为什么？ 假设我们使用的是 Nginx+Flask Run 来当作生产环境，全部部署在一台机器上。 劣势如下： 1、『单 Worker』只有一个进程在跑所有的请求，而由于实现的简陋性，内置 webserver 很容易卡死。并且只有一个 Worker 在跑请求。在多核 CPU 下，仅仅占用一核。当然，其实也可以多起几个进程。\2、『缺乏 Worker 的管理』接上，加入负载量上来了，Gunicorn 可以调节 Worker 的数量。而这个东西，内置的 Webserver 是不适合做这种事情的。一言以蔽之，太弱，几个请求就打满了。

第二个问题，

Gunicorn 作为 Server 相对而言可以有什么提升。 gunicorn 的优点如下， 帮我 scale worker, 进程挂了帮我重启用 python 的框架 flask/django/webpy 配置起来都差不多。还有信号机制。可以支持多种配置。其他在管理 worker 上，使用了 pre-fork 模型，即一个 master 进程管理多个 worker 进程，所有请求和响应均由 Worker 处理。Master 进程是一个简单的 loop, 监听 worker 不同进程信号并且作出响应。比如接受到 TTIN 提升 worker 数量，TTOU 降低运行 Worker 数量。如果 worker 挂了，发出 CHLD, 则重启失败的 worker, 同步的 Worker 一次处理一个请求。

第三个问题，

服务器和客户端的通信，我们简略的分为三个部分：request，request handling，和response，即客户端向服务器发起请求，服务器端响应并处理请求，和将请求结果返回客户端，这三个过程。通常，request handling这部分即服务端的计算，拼的是服务器的性能，处理是比较高效和稳定的，而request和response部分，影响因素比较多，如果这三个过程放到同一个进程中同步处理，如果request和response部分耗时比较多，会使计算资源被占据并无法及时释放，导致计算资源无法有效利用，降低服务器的处理能力。上述“慢客户端行为”，指的就是request（或response）部分耗时比较多的情况，Gunicorn恰好会把上面三个过程放到同一个进程中，当出现“慢客户端行为”时，效率很低：Gunicorn 是一个pre-forking的软件，这类软件对低延迟的通信，如负载均衡或服务间的互相通信，是非常有效的。但pre-forking系统的不足是，每个通信都会独占一个进程，当向服务器发出的请求多于服务器可用的进程时，由于服务器端没有更多进程响应新的请求，其响应效率会降低。对于Web网站或服务而言，由于request和response延时是不可控的，我们需要在考虑处理高延迟客户端请求的情况。这些请求会占据服务器端的进程。当慢客户端直接与服务通信时，由于慢客户端请求会占据进程，可用于处理新请求的进程就会减少，如果有很多慢客户端请求把所有进程都占据后，新的请求只能等待有进程被释放掉后，得到响应。另外，如果应用希望有更高的并发，服务器与客户端的通信要更高效，异步的通信会比同步的通信更有效。Nginx这类异步的服务器软件擅长用很少的内存和cpu开销来处理大量的请求。由于他们擅长于同时处理大量客户端请求，所以慢客户端请求对他们影响不大。就Nginx而言，现在一般的服务器硬件条件下，同时处理上万个请求都不在话下。所以把Nginx挡在pre-forking服务前面处理请求是一种很好的选择。Nginx能够异步、高并发的响应客户端request（慢客户端请求对Nginx影响不大），Nginx一旦接收到的请求后立刻转给Gunicorn服务处理，处理结果再由Nginx以response的形式发回给客户端。这样，整个服务端和客户端的通信，就由原来仅通过Gunicorn的同步通信，变成了基于Nginx和Gunicorn的异步通信，通信效率和并发能力得到大大提升。对于网站而言，除了要考虑上面介绍的情况，还要考虑各种静态文件的托管问题。静态文件既包括CSS、JavaScript等前端文件，也包括图片、视频和各类文档等，所以静态文件要么可能会比较大，要么会调用比较频繁，静态文件的托管功能，就是要保证各类静态能正常的加载、预览或下载，这其实就是Response耗时长的“慢客户端行为”。用Gunicorn托管静态文件，也会严重影响Gunicorn的响应效率，而这恰恰又是Nginx擅长的工作，所以静态文件的托管也交给Nginx搞定就好。

参考资料：
https://www.zhihu.com/question/297267614?sort=created
https://www.zhihu.com/question/38528616