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

hello886

原创:杂谈_浅谈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...

阅读 252
1 声望
0 粉丝
0 条评论
你知道吗?

1 声望
0 粉丝
宣传栏