分享一篇文章犁苏，總結了很多Python Web 部署的內(nèi)容礁击，原文位于：Python Web部署方式總結

不要讓服務器裸奔

學過PHP的都了解官册，php的正式環(huán)境部署非常簡單看彼，改幾個文件就OK豁遭，用FastCgi方式也是分分鐘的事情叭喜。相比起來，Python在web應用上的部署就繁雜的多蓖谢，主要是工具繁多捂蕴，主流服務器支持不足譬涡，在了解Python的生產(chǎn)環(huán)境部署方式之前，先明確一些概念啥辨！很重要涡匀！

CGI：

CGI即通用網(wǎng)關接口(Common Gateway Interface)，是外部應用程序（CGI程序）與Web服務器之間的接口標準溉知，是在CGI程序和Web服務器之間傳遞信息的規(guī)程陨瘩。CGI規(guī)范允許Web服務器執(zhí)行外部程序，并將它們的輸出發(fā)送給Web瀏覽器级乍，CGI將Web的一組簡單的靜態(tài)超媒體文檔變成一個完整的新的交互式媒體舌劳。通俗的講CGI就像是一座橋，把網(wǎng)頁和WEB服務器中的執(zhí)行程序連接起來玫荣，它把HTML接收的指令傳遞給服務器的執(zhí)行程序甚淡，再把服務器執(zhí)行程序的結果返還給HTML頁。CGI 的跨平臺性能極佳捅厂，幾乎可以在任何操作系統(tǒng)上實現(xiàn)贯卦。

CGI方式在遇到連接請求（用戶請求）先要創(chuàng)建cgi的子進程，激活一個CGI進程焙贷，然后處理請求脸侥，處理完后結束這個子進程。這就是fork-and-execute模式盈厘。所以用cgi方式的服務器有多少連接請求就會有多少cgi子進程睁枕，子進程反復加載是cgi性能低下的主要原因。當用戶請求數(shù)量非常多時沸手，會大量擠占系統(tǒng)的資源如內(nèi)存外遇，CPU時間等，造成效能低下契吉。

CGI腳本工作流程：

1. 瀏覽器通過HTML表單或超鏈接請求指向一個CGI應用程序的URL跳仿。
2. 服務器執(zhí)行務器收發(fā)到請求。所指定的CGI應用程序捐晶。
3. CGI應用程序執(zhí)行所需要的操作菲语，通常是基于瀏覽者輸入的內(nèi)容。
4. CGI應用程序把結果格式化為網(wǎng)絡服務器和瀏覽器能夠理解的文檔（通常是HTML網(wǎng)頁）惑灵。
5. 網(wǎng)絡服務器把結果返回到瀏覽器中山上。

python有cgi模塊可支持原生cgi程序。

FastCGI：

FastCGI是一個可伸縮地英支、高速地在HTTP server和動態(tài)腳本語言間通信的接口佩憾。多數(shù)流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等妄帘，同時楞黄，F(xiàn)astCGI也被許多腳本語言所支持，其中就有Python抡驼。FastCGI是從CGI發(fā)展改進而來的鬼廓。傳統(tǒng)CGI接口方式的主要缺點是性能很差，因為每次HTTP服務器遇到動態(tài)程序時都需要重新啟動腳本解析器來執(zhí)行解析致盟，然后結果被返回給HTTP服務器桑阶。這在處理高并發(fā)訪問時，幾乎是不可用的勾邦。FastCGI像是一個常駐(long-live)型的CGI蚣录，它可以一直執(zhí)行著，只要激活后眷篇，不會每次都要花費時間去fork一次(這是CGI最為人詬病的fork-and-execute 模式)萎河。CGI 就是所謂的短生存期應用程序，F(xiàn)astCGI 就是所謂的長生存期應用程序蕉饼。由于 FastCGI 程序并不需要不斷的產(chǎn)生新進程虐杯，可以大大降低服務器的壓力并且產(chǎn)生較高的應用效率。它的速度效率最少要比CGI 技術提高 5 倍以上昧港。它還支持分布式的運算, 即 FastCGI 程序可以在網(wǎng)站服務器以外的主機上執(zhí)行并且接受來自其它網(wǎng)站服務器來的請求擎椰。

FastCGI是語言無關的、可伸縮架構的CGI開放擴展创肥，其主要行為是將CGI解釋器進程保持在內(nèi)存中并因此獲得較高的性能达舒。眾所周知，CGI解釋器的反復加載是CGI性能低下的主要原因叹侄，如果CGI解釋器保持在內(nèi)存中并接受FastCGI進程管理器調(diào)度巩搏，則可以提供良好的性能、伸縮性趾代、Fail-Over特性等等贯底。FastCGI接口方式采用C/S結構，可以將HTTP服務器和腳本解析服務器分開撒强，同時在腳本解析服務器上啟動一個或者多個腳本解析守護進程禽捆。當HTTP服務器每次遇到動態(tài)程序時，可以將其直接交付給FastCGI進程來執(zhí)行飘哨，然后將得到的結果返回給瀏覽器胚想。這種方式可以讓HTTP服務器專一地處理靜態(tài)請求或者將動態(tài)腳本服務器的結果返回給客戶端，這在很大程度上提高了整個應用系統(tǒng)的性能杖玲。

FastCGI的工作流程:

1. Web Server啟動時載入FastCGI進程管理器（PHP-CGI或者PHP-FPM或者spawn-cgi)
2. FastCGI進程管理器自身初始化顿仇，啟動多個CGI解釋器進程(可見多個php-cgi)并等待來自Web Server的連接。
3. 當客戶端請求到達Web Server時摆马，F(xiàn)astCGI進程管理器選擇并連接到一個CGI解釋器臼闻。Web server將CGI環(huán)境變量和標準輸入發(fā)送到FastCGI子進程php-cgi。
4. FastCGI子進程完成處理后將標準輸出和錯誤信息從同一連接返回Web Server囤采。當FastCGI子進程關閉連接時述呐，請求便告處理完成。FastCGI子進程接著等待并處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接蕉毯。 在CGI模式中乓搬，php-cgi在此便退出。

FastCGI 的特點：

1. 打破傳統(tǒng)頁面處理技術代虾。傳統(tǒng)的頁面處理技術进肯，程序必須與 Web 服務器或 Application 服務器處于同一臺服務器中。這種歷史已經(jīng)早N年被FastCGI技術所打破棉磨，F(xiàn)astCGI技術的應用程序可以被安裝在服務器群中的任何一臺服務器江掩，而通過 TCP/IP 協(xié)議與 Web 服務器通訊，這樣做既適合開發(fā)大型分布式 Web 群乘瓤，也適合高效數(shù)據(jù)庫控制环形。
2. 明確的請求模式。CGI 技術沒有一個明確的角色衙傀，在 FastCGI 程序中抬吟，程序被賦予明確的角色（響應器角色、認證器角色统抬、過濾器角色）火本。

WSGI：

Python Web服務器網(wǎng)關接口（Python Web Server Gateway Interface，縮寫為WSGI）是為Python語言定義的Web服務器和Web應用程序或框架之間的一種簡單而通用的接口聪建。自從WSGI被開發(fā)出來以后发侵，許多其它語言中也出現(xiàn)了類似接口。WSGI是作為Web服務器與Web應用程序或應用框架之間的一種低級別的接口妆偏，以提升可移植Web應用開發(fā)的共同點刃鳄。WSGI是基于現(xiàn)存的CGI標準而設計的。

WSGI區(qū)分為兩個部份：一為“服務器”或“網(wǎng)關”钱骂，另一為“應用程序”或“應用框架”叔锐。在處理一個WSGI請求時，服務器會為應用程序提供環(huán)境上下文及一個回調(diào)函數(shù)（Callback Function）见秽。當應用程序完成處理請求后愉烙，透過先前的回調(diào)函數(shù)，將結果回傳給服務器解取。所謂的 WSGI 中間件同時實現(xiàn)了API的兩方步责，因此可以在WSGI服務和WSGI應用之間起調(diào)解作用：從WSGI服務器的角度來說，中間件扮演應用程序，而從應用程序的角度來說蔓肯，中間件扮演服務器遂鹊。“中間件”組件可以執(zhí)行以下功能：

1. 重寫環(huán)境變量后蔗包，根據(jù)目標URL秉扑，將請求消息路由到不同的應用對象。
2. 允許在一個進程中同時運行多個應用程序或應用框架调限。
3. 負載均衡和遠程處理舟陆，通過在網(wǎng)絡上轉(zhuǎn)發(fā)請求和響應消息。
4. 進行內(nèi)容后處理耻矮，例如應用XSLT樣式表秦躯。

以前，如何選擇合適的Web應用程序框架成為困擾Python初學者的一個問題裆装，這是因為踱承，一般而言，Web應用框架的選擇將限制可用的Web服務器的選擇米母，反之亦然勾扭。那時的Python應用程序通常是為CGI，F(xiàn)astCGI铁瞒，mod_python中的一個而設計妙色，甚至是為特定Web服務器的自定義的API接口而設計的。WSGI沒有官方的實現(xiàn), 因為WSGI更像一個協(xié)議慧耍。只要遵照這些協(xié)議,WSGI應用(Application)都可以在任何服務器(Server)上運行, 反之亦然身辨。WSGI就是Python的CGI包裝，相對于Fastcgi是PHP的CGI包裝芍碧。

WSGI將 web 組件分為三類： web服務器煌珊，web中間件,web應用程序， wsgi基本處理模式為 ： WSGI Server -> (WSGI Middleware)* -> WSGI Application 泌豆。

image

uwsgi：

uwsgi協(xié)議是一個uWSGI服務器自有的協(xié)議定庵，它用于定義傳輸信息的類型（type of information），每一個uwsgi packet前4byte為傳輸信息類型描述踪危，它與WSGI相比是兩樣東西蔬浙。據(jù)稱其效率是fcgi的10倍。具體的協(xié)議內(nèi)容請參考：the uwsgi protocol（http://uwsgi-docs.readthedocs.org/en/latest/Protocol.html）

以上四者都可以理解為協(xié)議贞远！協(xié)議畴博！協(xié)議！實現(xiàn)了這樣的協(xié)議蓝仲，就可以實現(xiàn)Web服務器與Web應用程序相關聯(lián)的web服務俱病！

uWSGI：

uWSGI項目旨在為部署分布式集群的網(wǎng)絡應用開發(fā)一套完整的解決方案官疲。uWSGI主要面向web及其標準服務，已經(jīng)成功的應用于多種不同的語言亮隙。由于uWSGI的可擴展架構途凫，它能夠被無限制的擴展用來支持更多的平臺和語言。目前咱揍，你可以使用C颖榜，C++和Objective-C來編寫插件棚饵。項目名稱中的“WSGI”是為了向同名的Python Web標準表示感謝煤裙，因為WSGI為該項目開發(fā)了第一個插件。uWSGI是一個Web服務器噪漾，它實現(xiàn)了WSGI協(xié)議硼砰、uwsgi、http等協(xié)議欣硼。uWSGI题翰，既不用wsgi協(xié)議也不用FastCGI協(xié)議，而是自創(chuàng)了上文說將的uwsgi協(xié)議诈胜。

uWSGI的主要特點如下：

1. 超快的性能豹障。
2. 低內(nèi)存占用（實測為apache2的mod_wsgi的一半左右）。
3. 多app管理焦匈。
4. 詳盡的日志功能（可以用來分析app性能和瓶頸）血公。
5. 高度可定制（內(nèi)存大小限制，服務一定次數(shù)后重啟等）缓熟。

Gunicorn：

和uWSGi類似的工具累魔，從rails的部署工具(Unicorn)移植過來的。但是它使用的協(xié)議是前文所講的WSGI够滑，這是python2.5時定義的官方標準(PEP 333 )垦写，根紅苗正，而且部署比較簡單彰触，詳細的使用教程請點擊這里（http://gunicorn.org/）梯投。Gunicorn采用prefork模式，Gunicorn 服務器與各種 Web 框架兼容况毅，只需非常簡單的執(zhí)行分蓖，輕量級的資源消耗，以及相當迅速俭茧。它的特點是與 Django 結合緊密咆疗，部署特別方便。 缺點也很多母债，不支持 HTTP 1.1午磁，并發(fā)訪問性能不高尝抖，與 uWSGI，Gevent 等有一定的性能差距迅皇。

1. Gunicorn設計

Gunicorn 是一個 master 進程昧辽，spawn 出數(shù)個工作進程的 web 服務器。master 進程控制工作進程的產(chǎn)生與消亡登颓，工作進程只需要接受請求并且處理搅荞。這樣分離的方式使得 reload 代碼非常方便，也很容易增加或減少工作進程框咙。 工作進程這塊作者給了很大的擴展余地咕痛，它可以支持不同的IO方式，如 Gevent,Sync 同步進程喇嘱，Asyc 異步進程茉贡，Eventlet 等等。master 跟 worker 進程完全分離者铜，使得 Gunicorn 實質(zhì)上就是一個控制進程的服務腔丧。

2. Gunicorn源碼結構

從 Application.run() 開始，首先初始化配置作烟，從文件讀取愉粤，終端讀取等等方式完成 configurate。然后啟動 Arbiter拿撩，Arbiter 是實質(zhì)上的 master 進程的核心衣厘，它首先從配置類中讀取并設置，然后初始化信號處理函數(shù)绷雏，建立 socket头滔。然后就是開始 spawn 工作進程，根據(jù)配置的工作進程數(shù)進行 spawn涎显。然后就進入了輪詢狀態(tài)坤检，收到信號，處理信號然后繼續(xù)期吓。這里喚醒進程的方式是建立一個 PIPE早歇，通過信號處理函數(shù)往 pipe 里 write，然后 master 從 select.select() 中喚醒讨勤。

工作進程在 spawn 后箭跳，開始初始化，然后同樣對信號進行處理潭千，并且開始輪詢谱姓，處理 HTTP 請求，調(diào)用 WSGI 的應用端刨晴，得到 resopnse 返回屉来。然后繼續(xù)路翻。

Sync 同步進程的好處在于每個 request 都是分離的，每個 request 失敗都不會影響其他 request茄靠，但這樣導致了性能上的瓶頸茂契。

Tornado：

Tornado即使一款python 的開發(fā)框架，也是一個異步非阻塞的http服務器慨绳，它本身的數(shù)據(jù)產(chǎn)出實現(xiàn)沒有遵從上文所說的一些通用協(xié)議掉冶，因為自身就是web服務器，所以動態(tài)請求就直接通過內(nèi)部的機制脐雪，輸出成用戶所請求的動態(tài)內(nèi)容厌小。如果把它作為一個單獨服務器，想用它來配合其他的框架如Flask來部署喂江，則需要采用WSGI協(xié)議召锈，Tornado內(nèi)置了該協(xié)議旁振，tornado.wsgi.WSGIContainer获询。

wsgiref：

Python自帶的實現(xiàn)了WSGI協(xié)議的的wsgi server。wsgi server可以理解為一個符合wsgi規(guī)范的web server拐袜，接收request請求吉嚣，封裝一系列環(huán)境變量，按照wsgi規(guī)范調(diào)用注冊的wsgi app蹬铺，最后將response返回給客戶端尝哆。Django的自帶服務器就是它了。

以上都可以理解為實現(xiàn)甜攀！實現(xiàn)秋泄！實現(xiàn)！實現(xiàn)了協(xié)議的工具规阀！

注：mod_wsgi（apache的模塊）其實也是實現(xiàn)了wsgi協(xié)議的一個模塊恒序，現(xiàn)在幾乎被廢棄了，所以也不多說了谁撼，感興趣的自己查一下吧歧胁。

所以如果你采用Django框架開發(fā)了應用之后，想部署到生產(chǎn)環(huán)境厉碟，肯定不能用Django自帶的喊巍，可以用使用uwsgi協(xié)議的uWSGI服務器，也可以采用實現(xiàn)了WSGI協(xié)議的gunicorn或者Tornado箍鼓，亦可以用FastCGI崭参、CGI模式的Nginx、lighttpd款咖、apache服務器何暮。其他框架亦如此逢并！明白了這些概念在部署的時候就可以做到心中有數(shù)，各種工具之間的搭配也就“知其然郭卫，并知其所以然”了砍聊。

在我們組的項目中有兩種框架Django和Tornado，生產(chǎn)環(huán)境也用到了兩種部署方式贰军。uWSGI和Gunicorn：

Django項目用Nginx+uWSGI方式部署玻蝌，Tornado項目用Nginx+Gunicorn方式部署：

Nginx都作為負載均衡以及靜態(tài)內(nèi)容轉(zhuǎn)發(fā)。Tornado項目用supervisord來管理Gunicorn词疼，用Gunicorn管理Tornado俯树。眾所周知，由于Python的GIL存在贰盗，所以Python的并發(fā)都采用多進程模式许饿，所以我們部署的方式是一個核心兩個進程。