原创：杂谈_浅谈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…
发表回复