如何选择 Python web 程序的部署方案

python web 的部署方式很多,其中有些方式已经非常陈旧。但是放狗一搜,大多还是搜到这些过时的文章,很多时候让人非常困惑。综合来说:高性能的python web站点部署方式首推nginx+uwsgi, 稳定性和性能都达到非常令人满意的程度。如果怕麻烦又不要求性能,apache+mod_wsgi 也是很简单稳定的方式。如果是API服务器,直接用tornado或者gevent写。

mod_python

非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说,使用 Apache 部署是一个不错的选择。较早的时候,使用 mode_python 部署python的web应用十分流行,在Django 0.96 的时候官方文档甚至推荐这种方式。

它将Python解释器嵌入到Apache server,以提供一个访问Apache server内部的接口。mod_python 在现在看来性能是不佳的,每一个http请求 mod_python 都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。

mod_wsgi

如果非要用Apache来部署python应用,mod_wsgi是一个更好的选择,他的主页在这里 http://code.google.com/p/modwsgi/。WSGI 全称是 Web Server Gateway Interface ,由 PEP-333 定义 http://www.python.org/dev/peps/pep-3333/。 基本上所有的python web框架都实现了wsgi接口,用mod_wsgi 能部署任何实现了wsgi的框架。实际上,不需要任何框架也可以用mod_wsgi 部署python程序。

WSGI应用其实就是一个callable的对象。举一个最简单的例子,假设存在如下的一个应用:

def application(environ, start_response): status = ‘200 OK’ output = ‘World!’ response_headers = [(’Content-type’, ‘text/plain’), (’Content-Length’, str(12)] write = start_response(status, response_headers) write(’Hello ‘) return [output]

上面这段代码可以直接由mod_wsgi部署,因为它实现了wsgi接口。

LoadModule wsgi_module modules/mod_wsgi.so WSGIScriptAlias /appname /var/www/wsgi.py/ Alias /appname/static /var/www/appname/static/ AddType text/html .py <Directory /var/www/wsgiapp/> Order deny,allow Allow from all </Directory>

使用mod_wsgi的daemon模式,python程序会常驻内存,不会有很大的初始化和销毁进程方面的开销,所以性能是好于mod_python的。这里有使用daemon的介绍 http://modwsgi.readthedocs.org/en/latest/configuration-directives/WSGIDaemonProcess.html

综合来说,使用Apache部署python web程序,推荐使用mod_wsgi的daemon模式。

Fastcgi

先说观点:不建议用fastcgi的方式部署Python web。

前几年由于lighttpd风头正劲和豆瓣的成功案例,fastcgi是一种很流行的部署方式。fastcgi与具体语言无关,也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强,CGI程序运行在独立的进程中,并对每个Web请求建立一个进程。面对大量请求,进程的大量建立和消亡使操作系统性能大大下降。

与为每个请求创建一个新的进程不同,FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理,而不是web服务器。 当进来一个请求时,web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地)或者一个TCP connection(FastCGI进程在远端的server farm)传递给FastCGI进程。

主流的web服务器,Apache,lighttpd,nginx 都支持fastcgi,在几年前,lighttpd的mod_fcgi模块性能强劲,lighttpd+fastcgi十分流行。无论是python,ruby还是php,都有大量的站点使用这种方式部署。由于nginx的崛起,现在很少有人使用lighttpd了。

fastcgi 并不是专门为python设计,并不是所有的python框架天然的支持fastcgi,通常需要flup这样的容器来配适。flup由python编写,和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看,部署python web程序,fastcgi 都已经是过去式。

uwsgi

前几年nginx还未内置uwsgi模块的时候,部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块,uwsgi已经是最可靠,最方便的高性能python web程序的部署方式了。

在1U的四核XEON服务器上,一个简单的wsgi handler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。 同时,uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定,在一个渣HP 1U 服务器上,基本不用管它。

uwsgi部署的详细方式请移步 uwsgi的部署和优化

上面提到的部署方式都是相对于web网站的方式,在移动互联网的时代,我们需要的是高性能的API服务,上面这些都是过时的东西。

tornado

tornado 号称高性能,如果拿他写网站,其实一般般,只不过跟uwsgi加一些简单框架差不多而已。它真正的作用,是用来写API服务器和长连接的服务器。

由于tornado能够直接处理http请求,很多人直接拿他来裸奔直接提供服务。这种方式是不可取的,单线程的tornado只能利用cpu的一个核心,并且一旦阻塞直接就废了。通常情况下,由supervisor启动多个tornado进程,通过nginx进行反向代理负载均衡。nginx 1.14 以后的版本反向代理支持长连接,配合tornado的comet效果很好。

tornado还有一些比较奇葩的用法,比如用来做wsgi容器之类的。不知道有没有人真的这样用在生产环境。

gevent

gevent是一个神器,能做的事情很多。在web方面,处理http请求,用起来其实跟tornado差不多,但是要简陋很多,cookie之类的都没有。用gevent写的一些API服务,部署方式还是类似tornado,用supervisor管理多个守护进程,通过nginx做负载均衡。 同样的它的奇葩用法也和tornado一样,可以当wsgi容器用。

如何选择 Python web 程序的部署方案

相关文章:

你感兴趣的文章:

标签云: