原创：杂谈_浅谈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大缺点

『单 Worker』只有一个过程在跑所有的申请，而因为实现的简陋性，内置 webserver 很容易卡死。并且只有一个 Worker 在跑申请。在多核 CPU 下，仅仅占用一核。当然，其实也能够多起几个过程。『不足 Worker 的治理』接上，退出负载量上来了，Gunicorn 能够调节 Worker 的数量。而这个货色，内置的 Webserver 是不适宜做这种事件的。

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

帮我 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/be2...
Nginx、Gunicorn在服务器中别离起什么作用？：https://www.zhihu.com/questio...
nginx+uwsgi 和nginx+gunicorn区别、如何部署:https://www.jianshu.com/p/be2...