杂谈_浅谈nginx,gunicorn,flask差异比对

flask(django):Python的Web应用程序（如Flask,django）
nginx:web服务器，用户角度直接对接使用,请求响应的request-response出入口
WSGI（Web Server Gateway Interface），翻译为Python web服务器网关接口，即Python的Web应用程序（如Flask）和Web服务器(如Nginx)之间的一种通信协议。也就是说，如果让你的Web应用在任何服务器上运行，就必须遵循这个协议。

几种部署方式差异

Flask 内置 WebServer + Flask App = 弱鸡版本的 Server, 单进程（单 worker) / 失败挂掉 / 不易 Scale
Gunicorn + Flask App = 多进程（多 worker) / 多线程 / 失败自动帮你重启 Worker / 可简单Scale
多 Nginx + 多 Gunicorn + Flask App = 小型多实例 Web 应用，一般也会给 gunicorn 挂 supervisor

为何gunicorn

简单来说flask自带server太弱了 （几个请求就打满了）。
2大缺陷

1
2

『单 Worker』只有一个进程在跑所有的请求，而由于实现的简陋性，内置 webserver 很容易卡死。并且只有一个 Worker 在跑请求。在多核 CPU 下，仅仅占用一核。当然，其实也可以多起几个进程。
『缺乏 Worker 的管理』接上，加入负载量上来了，Gunicorn 可以调节 Worker 的数量。而这个东西，内置的 Webserver 是不适合做这种事情的。

Gunicorn 作为 Server 相对而言的提升。

1
2
3
4

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

为何nginx

01,负载均衡。tornado之类的框架只支持单核，所以多进程部署需要反向负载均衡。gunicorn本身就是多进程其实不需要
02,静态文件支持，经过配置之后，nginx可以直接处理静态文件请求而不用经过Python服务器，Python服务器也可以返回特殊的http01,头将请求rewrite到静态文件。我说的是经过配置之后，你配置了吗？
03,抗并发压力。虽然不能提升qps，但是多一层前端，的确可以吸收一些瞬时的并发请求，让nginx先保持住连接，然后后端慢慢消化，但说实话这种情况下服务体验已经很糟糕了。但的确比服务挂掉强一些。
04,rewrite之类的其他功能。配置了才有，配了吗？

服务器和客户端的通信，我们简略的分为三个部分：request，request handling，和response，即客户端向服务器发起请求，服务器端响应并处理请求，和将请求结果返回客户端，这三个过程。
对于Web网站或服务而言，由于request和response延时是不可控的，我们需要在考虑处理高延迟客户端请求的情况。这些请求会占据服务器端的进程。
Nginx这类异步的服务器软件擅长用很少的内存和cpu开销来处理大量的请求。由于他们擅长于同时处理大量客户端请求，所以慢客户端请求对他们影响不大
所以把Nginx挡在pre-forking服务前面处理请求是一种很好的选择。
Nginx能够异步、高并发的响应客户端request（慢客户端请求对Nginx影响不大），Nginx一旦接收到的请求后立刻转给Gunicorn服务处理，处理结果再由Nginx以response的形式发回给客户端。这样，整个服务端和客户端的通信，就由原来仅通过Gunicorn的同步通信，变成了基于Nginx和Gunicorn的异步通信，通信效率和并发能力得到大大提升。
对于网站而言，除了要考虑上面介绍的情况，还要考虑各种静态文件的托管问题。静态文件既包括CSS、JavaScript等前端文件，也包括图片、视频和各类文档等，所以静态文件要么可能会比较大，要么会调用比较频繁，静态文件的托管功能，就是要保证各类静态能正常的加载、预览或下载，这其实就是Response耗时长的“慢客户端行为”。用Gunicorn托管静态文件，也会严重影响Gunicorn的响应效率，而这恰恰又是Nginx擅长的工作，所以静态文件的托管也交给Nginx搞定就好。

综合

nginx可以缓冲请求和响应。如果让Gunicorn直接提供服务，浏览器发起一个请求，鉴于浏览器和网络情况都是未知的，http请求的发起过程可能比较慢，而Gunicorn只能等待请求发起完成后，才去真正处理请求，处理完成后，等客户端完全接收请求后，才继续下一个。
nginx缓存客户端发起的请求，直到收完整个请求，转发给Gunicorn，等Gunicorn处理完成后，拿到响应，再发给客户端，这个流程是nginx擅长处理，而Gunicorn不擅长处理的。
因此将Gunicorn置于nginx后面，可以有效提高Gunicorn的处理能力。

参考

[线上环境部署Django，nginx+uwsgi 和nginx+gunicorn，这两种方案，应该如何选择？]：https://www.jianshu.com/p/be2b587a900e
Nginx、Gunicorn在服务器中分别起什么作用？：https://www.zhihu.com/question/38528616
nginx+uwsgi 和nginx+gunicorn区别、如何部署:https://www.jianshu.com/p/be2b587a900e