全面解读python web 程序的9种部署方式

你的名字 2021-12-04 04:53 77阅读 0赞

# 全面解读python web 程序的9种部署方式 #

时间：2013-03-18 03:42:55 类别：[Python][] 访问: *10114* 次

python有很多web 开发框架，代码写完了，部署上线是个大事，通常来说，web应用一般是三层结构

> web server ---->application -----> DB server

*  主流的web server 一个巴掌就能数出来，apache，lighttpd，nginx，iis
 *  application,中文名叫做应用服务，就是你基于某个web framework写的应用代码
 *  DB server 泛指存储服务，web开发中用mysql比较多，最近几年因为网站规模扩大，memcache，redis这种key-value等存储也流行开来

放在最前面的**web server**有3个功能

1.  **高效率处理静态文件**,web server都是用c开发，调用是native的函数，对IO，文件传输都做针对性的优化
2.  **充当一个简易的网络防火墙**，可以denny一些ip，简单的控制并发连接数量等等，聊胜于无
3.  **处理高并发短连接请求**，把成千上万用户的request 通过内网的几十个长连接进行转发，原因一个是web server处理高并发很专业，另外一个原因是大部分的application所用的框架都不具备处理高并发的能力

实际上，市面上有部分web framework由于内置了支持epoll/kqueue 等高效网络库，而具备了处理高并发的能力，比如说 python的tornado，java系的tomcat,jetty等等，有人就去掉前端的web server，直接裸奔，但是在部署公网应用时候，最好别这样做，因为前面提到的1,2两个原因，用户brower到web server的网络状况是千奇百怪，你无法想象的，

web server 强烈建议使用nginx，原因有三

1.  性能非常卓越，非常稳定
2.  安装简单，依赖包少
3.  conf文件非常容易配置，比apache/lighttpd都要简单

### 部署python开发的web程序有9种方法 ###

*  **mod\_python**,这是apache内置的模块，很严重的依赖于mod\_python编译使用的python版本，和apache配套使用，不推荐
 *  **cgi**，这个太old，不推荐，而且nginx不支持cgi方式，只能用lighttpd或者apache
 *  **fastcgi** ，这个是目前流行最广的做法，通过flup模块来支持的，在nginx里对应的配置指令是 fastcgi\_pass
 *  **spawn-fcgi**，这个是fastcgi多进程管理程序，lighttpd安装包附带的，和flup效果一样，区别是flup是 python代码级引入，spawn-fcgi是外部程序。spawn-fcgi用途很广，可以支持任意语言开发的代码，php,python,perl,只要你代码实现了fastcgi接口，它都可以帮你管理你的进程
 *  **scgi**,全名是Simple Common Gateway Interface，也是cgi的替代版本，[scgi协议][scgi]很简单,我觉得和fastcgi差不多，只是没有怎么推广开来，nginx对应的配置指令是scgi\_pass，你想用就用，flup也支持。
 *  **http**，nginx使用proxy\_pass转发,这个要求后端appplication必须内置一个能处理高并发的http server，在python的web框架当中，只能选择tornado.
    
    python程序员喜欢发明轮子，tornado除了是一个web framework之外，它还可以单独提供高性能http server，所以，如果你采用其他python框架写代码，比如说bottle，也一样可以通过`import tornado` 来启动一个高性能的http server，同样的可以采用http协议和nginx一起来部署。扩展开来，python包里面能处理高并发的http server还有很多，比如说gevent，也可以被其他框架引用来支持http方式部署。
    
    现实当中，用java来做web程序，通常就用http和nginx配合，应用服务器选择tomcat或者jetty
 *  **uwsgi**,包括4部分组成，
    
     *  uwsgi协议
     *  web server内置支持协议模块
     *  application服务器协议支持模块
     *  进程控制程序
    
    nginx从0.8.4开始内置支持uwsgi协议，uwsgi协议非常简单，一个4个字节header+一个body，body可以是很多协议的包，比如说http，cgi等（通过header里面字段标示），我曾经做个一个小规模的性能对比测试，结果表明，uwsgi和fastcgi相比，性能没有太明显的优势,也可能是数据集较小的原因
    
     
    
    uwsgi的特点在于自带的进程控制程序.它是用c语言编写，使用natvie函数，其实和spawn-fcgi/php-fpm类似。所以uwsgi可以支持多种应用框架，包括(python,lua,ruby,erlang,go)等等
 *  **Gunicorn**,和uwsgi类似的工具，从rails的部署工具(Unicorn)移植过来的。但是它使用的协议是 WSGI，全称是Python Web Server Gateway Interface ，这是python2.5时定义的官方标准([PEP 333][] )，根红苗正，而且部署比较简单，[http://gunicorn.org/][http_gunicorn.org] 上有详细教程
 *  **mod\_wsgi**,apache的一个module，也是支持WSGI协议,[https://code.google.com/p/modwsgi/][https_code.google.com_p_modwsgi]

### fastcgi协议和http协议在代码部署中的的优劣对比 ###

*  fastcgi虽然是二进制协议，相对于http协议，并不节省资源。二进制协议，只能节省数字的表达，比如 1234567，用字符串表示需要7个Byte，用数字就是4个Byte，而字符串到哪里都一样
 *  fastcgi在传输数据的时候，为了兼容cgi协议，还要带上一堆cgi的环境变量，所以和http协议相比，用fastcgi传输数据并不省，反而多一些
 *  fastcgi 唯一的优点是，它是长连接的，用户并发1000个request，fastcgi可能就用10个 链接转发给后端的appplication，如果用http协议，那来多少给多少，会向后端appplication 发起1000个请求
 *  http代理转发方式，在面对超高并发的情况下会出问题，因为，**tcp协议栈当中，port是int16整型**你本地新建一个connect，需要消耗一个端口，最多能到65536。外部并发几十万个请求，port池耗干，你的服务器只能拒绝响应了

### 总结 ###

我个人习惯是用 fastcgi 协议部署python程序，简单省事，选择技术方案，一定要选择最简单最常见的，本博客的fastcgi运行脚本如下

1.  kill \-9\`cat /tmp/django.pid\`  
    
2.  echo 'restart django....'  
    
3.  python ./manage.py runfcgi \--settings=lutaf.settings\_r maxchildren=8  maxspare=3 minspare=1 method=prefork  pidfile=/tmp/django.pid host=127.0.0.1 port=9900 outlog=/tmp/dj.out errlog=/tmp/dj.error

推荐大家尝试 Gunicorn ，这是未来发展方向

**标签:** [django][][gunicorn][][fastcgi][][wsgi][]

本文地址: [http://lutaf.com/141.htm][http_lutaf.com_141.htm] 鲁塔弗原创文章，欢迎转载，请附带原文链接

转载于:https://www.cnblogs.com/DjangoBlog/p/4442092.html

[Python]: http://lutaf.com/category/python
[scgi]: http://lutaf.com/j?u=http://python.ca/scgi/protocol.txt
[PEP 333]: http://lutaf.com/j?u=http://www.python.org/dev/peps/pep-0333/
[http_gunicorn.org]: http://lutaf.com/j?u=http://gunicorn.org/
[https_code.google.com_p_modwsgi]: http://lutaf.com/j?u=https://code.google.com/p/modwsgi/
[django]: http://lutaf.com/tag/django
[gunicorn]: http://lutaf.com/tag/gunicorn
[fastcgi]: http://lutaf.com/tag/fastcgi
[wsgi]: http://lutaf.com/tag/wsgi
[http_lutaf.com_141.htm]: http://lutaf.com/141.htm