全面解讀python web 程式的9種部署方式

標籤：http   java   使用   os   io   strong   檔案   資料   

轉載自魯塔弗的部落格,本文地址http://lutaf.com/141.htm 

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協議很簡單,我覺得和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/ 上有詳細教程

• mod_wsgi,apache的一個module，也是支援WSGI協議,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