python有很多web 開發(fā)框架,代碼寫完了,部署上線是個大事,通常來說,web應(yīng)用一般是三層結(jié)構(gòu)
web server ---->application -----> DB server
- 主流的web server 一個巴掌就能數(shù)出來,apache,lighttpd,nginx,iis
- application,中文名叫做應(yīng)用服務(wù),就是你基于某個web framework寫的應(yīng)用代碼
- DB server 泛指存儲服務(wù),web開發(fā)中用mysql比較多,最近幾年因為網(wǎng)站規(guī)模擴大,memcache,redis這種key-value等存儲也流行開來
放在最前面的web server有3個功能
- 高效率處理靜態(tài)文件,web server都是用c開發(fā),調(diào)用是native的函數(shù),對IO,文件傳輸都做針對性的優(yōu)化
- 充當(dāng)一個簡易的網(wǎng)絡(luò)防火墻,可以denny一些ip,簡單的控制并發(fā)連接數(shù)量等等,聊勝于無
- 處理高并發(fā)短連接請求,把成千上萬用戶的request 通過內(nèi)網(wǎng)的幾十個長連接進行轉(zhuǎn)發(fā),原因一個是web server處理高并發(fā)很專業(yè),另外一個原因是大部分的application所用的框架都不具備處理高并發(fā)的能力
實際上,市面上有部分web framework由于內(nèi)置了支持epoll/kqueue 等高效網(wǎng)絡(luò)庫,而具備了處理高并發(fā)的能力,比如說 python的tornado,java系的tomcat,jetty等等,有人就去掉前端的web server,直接裸奔,但是在部署公網(wǎng)應(yīng)用時候,最好別這樣做,因為前面提到的1,2兩個原因,用戶brower到web server的網(wǎng)絡(luò)狀況是千奇百怪,你無法想象的,
web server 強烈建議使用nginx,原因有三
- 性能非常卓越,非常穩(wěn)定
- 安裝簡單,依賴包少
- conf文件非常容易配置,比apache/lighttpd都要簡單
部署python開發(fā)的web程序有9種方法
-
mod_python,這是apache內(nèi)置的模塊,很嚴(yán)重的依賴于mod_python編譯使用的python版本,和apache配套使用,不推薦
-
cgi,這個太old,不推薦,而且nginx不支持cgi方式,只能用lighttpd或者apache
-
fastcgi ,這個是目前流行最廣的做法,通過flup模塊來支持的,在nginx里對應(yīng)的配置指令是 fastcgi_pass
-
spawn-fcgi,這個是fastcgi多進程管理程序,lighttpd安裝包附帶的,和 flup效果一樣,區(qū)別是flup是 python代碼級引入,spawn-fcgi是外部程序。spawn-fcgi用途很廣,可以支持任意語言開發(fā)的代碼,php,python,perl,只要你代碼實現(xiàn)了fastcgi接口,它都可以幫你管理你的進程
-
scgi,全名是Simple Common Gateway Interface,也是cgi的替代版本,scgi協(xié)議很簡單,我覺得和fastcgi差不多,只是沒有怎么推廣開來,nginx對應(yīng)的配置指令是scgi_pass,你想用就用,flup也支持。
-
http,nginx使用proxy_pass轉(zhuǎn)發(fā),這個要求后端appplication必須內(nèi)置一個能處理高并發(fā)的http server,在python的web框架當(dāng)中,只能選擇tornado.
python程序員喜歡發(fā)明輪子,tornado除了是一個web framework之外,它還可以單獨提供高性能http server,所以,如果你采用其他python框架寫代碼,比如說bottle,也一樣可以通過import tornado 來啟動一個高性能的http server,同樣的可以采用http協(xié)議和nginx一起來部署。擴展開來,python包里面能處理高并發(fā)的http server還有很多,比如說gevent,也可以被其他框架引用來支持http方式部署。
現(xiàn)實當(dāng)中,用java來做web程序,通常就用http和nginx配合,應(yīng)用服務(wù)器選擇tomcat或者jetty
-
uwsgi,包括4部分組成,
- uwsgi協(xié)議
- web server內(nèi)置支持協(xié)議模塊
- application服務(wù)器協(xié)議支持模塊
- 進程控制程序
nginx從0.8.4開始內(nèi)置支持uwsgi協(xié)議,uwsgi協(xié)議非常簡單,一個4個字節(jié)header+一個body,body可以是很多協(xié)議的包,比如說http,cgi等(通過header里面字段標(biāo)示),我曾經(jīng)做個一個小規(guī)模的性能對比測試,結(jié)果表明,uwsgi和fastcgi相比,性能沒有太明顯的優(yōu)勢,也可能是數(shù)據(jù)集較小的原因
uwsgi的特點在于自帶的進程控制程序.它是用c語言編寫,使用natvie函數(shù),其實和spawn-fcgi/php-fpm類似。所以uwsgi可以支持多種應(yīng)用框架,包括(python,lua,ruby,erlang,go)等等
-
Gunicorn,和uwsgi類似的工具,從rails的部署工具(Unicorn)移植過來的。但是它使用的協(xié)議是 WSGI,全稱是Python Web Server Gateway Interface ,這是python2.5時定義的官方標(biāo)準(zhǔn)(PEP 333 ),根紅苗正,而且部署比較簡單,http:/// 上有詳細(xì)教程
-
mod_wsgi,apache的一個module,也是支持WSGI協(xié)議,https://code.google.com/p/modwsgi/
fastcgi協(xié)議和http協(xié)議在代碼部署中的的優(yōu)劣對比
-
fastcgi雖然是二進制協(xié)議,相對于http協(xié)議,并不節(jié)省資源。二進制協(xié)議,只能節(jié)省數(shù)字的表達,比如 1234567,用字符串表示需要7個Byte,用數(shù)字就是4個Byte,而字符串到哪里都一樣
-
fastcgi在傳輸數(shù)據(jù)的時候,為了兼容cgi協(xié)議,還要帶上一堆cgi的環(huán)境變量,所以和http協(xié)議相比,用fastcgi傳輸數(shù)據(jù)并不省,反而多一些
-
fastcgi 唯一的優(yōu)點是,它是長連接的,用戶并發(fā)1000個request,fastcgi可能就用10個 鏈接轉(zhuǎn)發(fā)給后端的appplication,如果用http協(xié)議,那來多少給多少,會向后端appplication 發(fā)起1000個請求
-
http代理轉(zhuǎn)發(fā)方式,在面對超高并發(fā)的情況下會出問題,因為,tcp協(xié)議棧當(dāng)中,port是int16整型 你本地新建一個connect,需要消耗一個端口,最多能到65536。外部并發(fā)幾十萬個請求,port池耗干,你的服務(wù)器只能拒絕響應(yīng)了
總結(jié)
我個人習(xí)慣是用 fastcgi 協(xié)議部署python程序,簡單省事,選擇技術(shù)方案,一定要選擇最簡單最常見的,本博客的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 ,這是未來發(fā)展方向
|