學(xué)過(guò)PHP的都了解,php的正式環(huán)境部署非常簡(jiǎn)單,改幾個(gè)文件就OK,用FastCgi方式也是分分鐘的事情。相比起來(lái),Python在web應用上的部署就繁雜的多,主要是工具繁多,主流服務(wù)器支持不足。
在了解Python的生產(chǎn)環(huán)境部署方式之前,先明確一些概念!很重要
CGI:
CGI即通用網(wǎng)關(guān)接口(Common Gateway Interface),是外部應用程序(CGI程序)與Web服務(wù)器之間的接口標準,是在CGI程序和Web服務(wù)器之間傳遞信息的規程。CGI規范允許Web服務(wù)器執行外部程序,并將它們的輸出發(fā)送給Web瀏覽器,CGI將Web的一組簡(jiǎn)單的靜態(tài)超媒體文檔變成一個(gè)完整的新的交互式媒體。通俗的講CGI就像是一座橋,把網(wǎng)頁(yè)和WEB服務(wù)器中的執行程序連接起來(lái),它把HTML接收的指令傳遞給服務(wù)器的執行程序,再把服務(wù)器執行程序的結果返還給HTML頁(yè)。CGI 的跨平臺性能極佳,幾乎可以在任何操作系統上實(shí)現。
CGI方式在遇到連接請求(用戶(hù)請求)先要創(chuàng )建cgi的子進(jìn)程,激活一個(gè)CGI進(jìn)程,然后處理請求,處理完后結束這個(gè)子進(jìn)程。這就是fork-and-execute模式。所以用cgi方式的服務(wù)器有多少連接請求就會(huì )有多少cgi子進(jìn)程,子進(jìn)程反復加載是cgi性能低下的主要原因。當用戶(hù)請求數量非常多時(shí),會(huì )大量擠占系統的資源如內存,CPU時(shí)間等,造成效能低下。
CGI腳本工作流程:
瀏覽器通過(guò)HTML表單或超鏈接請求指向一個(gè)CGI應用程序的URL。
服務(wù)器執行務(wù)器收發(fā)到請求。所指定的CGI應用程序。
CGI應用程序執行所需要的操作,通常是基于瀏覽者輸入的內容。
CGI應用程序把結果格式化為網(wǎng)絡(luò )服務(wù)器和瀏覽器能夠理解的文檔(通常是HTML網(wǎng)頁(yè))。
網(wǎng)絡(luò )服務(wù)器把結果返回到瀏覽器中。
python有cgi模塊可支持原生cgi程序
FastCGI:
FastCGI是一個(gè)可伸縮地、高速地在HTTP server和動(dòng)態(tài)腳本語(yǔ)言間通信的接口。多數流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等,同時(shí),FastCGI也被許多腳本語(yǔ)言所支持,其中就有Python。FastCGI是從CGI發(fā)展改進(jìn)而來(lái)的。傳統CGI接口方式的主要缺點(diǎn)是性能很差,因為每次HTTP服務(wù)器遇到動(dòng)態(tài)程序時(shí)都需要重新啟動(dòng)腳本解析器來(lái)執行解析,然后結果被返回給HTTP服務(wù)器。這在處理高并發(fā)訪(fǎng)問(wèn)時(shí),幾乎是不可用的。FastCGI像是一個(gè)常駐(long-live)型的CGI,它可以一直執行著(zhù),只要激活后,不會(huì )每次都要花費時(shí)間去fork一次(這是CGI最為人詬病的fork-and-execute 模式)。CGI 就是所謂的短生存期應用程序,FastCGI 就是所謂的長(cháng)生存期應用程序。由于 FastCGI 程序并不需要不斷的產(chǎn)生新進(jìn)程,可以大大降低服務(wù)器的壓力并且產(chǎn)生較高的應用效率。它的速度效率最少要比CGI 技術(shù)提高 5 倍以上。它還支持分布式的運算, 即 FastCGI 程序可以在網(wǎng)站服務(wù)器以外的主機上執行并且接受來(lái)自其它網(wǎng)站服務(wù)器來(lái)的請求。
FastCGI是語(yǔ)言無(wú)關(guān)的、可伸縮架構的CGI開(kāi)放擴展,其主要行為是將CGI解釋器進(jìn)程保持在內存中并因此獲得較高的性能。眾所周知,CGI解釋器的反復加載是CGI性能低下的主要原因,如果CGI解釋器保持在內存中并接受FastCGI進(jìn)程管理器調度,則可以提供良好的性能、伸縮性、Fail-Over特性等等。FastCGI接口方式采用C/S結構,可以將HTTP服務(wù)器和腳本解析服務(wù)器分開(kāi),同時(shí)在腳本解析服務(wù)器上啟動(dòng)一個(gè)或者多個(gè)腳本解析守護進(jìn)程。當HTTP服務(wù)器每次遇到動(dòng)態(tài)程序時(shí),可以將其直接交付給FastCGI進(jìn)程來(lái)執行,然后將得到的結果返回給瀏覽器。這種方式可以讓HTTP服務(wù)器專(zhuān)一地處理靜態(tài)請求或者將動(dòng)態(tài)腳本服務(wù)器的結果返回給客戶(hù)端,這在很大程度上提高了整個(gè)應用系統的性能。
FastCGI的工作流程:
Web Server啟動(dòng)時(shí)載入FastCGI進(jìn)程管理器(PHP-CGI或者PHP-FPM或者spawn-cgi)
FastCGI進(jìn)程管理器自身初始化,啟動(dòng)多個(gè)CGI解釋器進(jìn)程(可見(jiàn)多個(gè)php-cgi)并等待來(lái)自Web Server的連接。
當客戶(hù)端請求到達Web Server時(shí),FastCGI進(jìn)程管理器選擇并連接到一個(gè)CGI解釋器。Web server將CGI環(huán)境變量和標準輸入發(fā)送到FastCGI子進(jìn)程php-cgi。
FastCGI子進(jìn)程完成處理后將標準輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進(jìn)程關(guān)閉連接時(shí),請求便告處理完成。FastCGI子進(jìn)程接著(zhù)等待并處理來(lái)自FastCGI進(jìn)程管理器(運行在Web Server中)的下一個(gè)連接。 在CGI模式中,php-cgi在此便退出。
FastCGI 的特點(diǎn):
打破傳統頁(yè)面處理技術(shù)。傳統的頁(yè)面處理技術(shù),程序必須與 Web 服務(wù)器或 Application 服務(wù)器處于同一臺服務(wù)器中。這種歷史已經(jīng)早N年被FastCGI技術(shù)所打破,FastCGI技術(shù)的應用程序可以被安裝在服務(wù)器群中的任何一臺服務(wù)器,而通過(guò) TCP/IP 協(xié)議與 Web 服務(wù)器通訊,這樣做既適合開(kāi)發(fā)大型分布式 Web 群,也適合高效數據庫控制。
明確的請求模式。CGI 技術(shù)沒(méi)有一個(gè)明確的角色,在 FastCGI 程序中,程序被賦予明確的角色(響應器角色、認證器角色、過(guò)濾器角色)。
WSGI:
Python Web服務(wù)器網(wǎng)關(guān)接口(Python Web Server Gateway Interface,縮寫(xiě)為WSGI)是為Python語(yǔ)言定義的Web服務(wù)器和Web應用程序或框架之間的一種簡(jiǎn)單而通用的接口。自從WSGI被開(kāi)發(fā)出來(lái)以后,許多其它語(yǔ)言中也出現了類(lèi)似接口。WSGI是作為Web服務(wù)器與Web應用程序或應用框架之間的一種低級別的接口,以提升可移植Web應用開(kāi)發(fā)的共同點(diǎn)。WSGI是基于現存的CGI標準而設計的。
WSGI區分為兩個(gè)部份:一為“服務(wù)器”或“網(wǎng)關(guān)”,另一為“應用程序”或“應用框架”。在處理一個(gè)WSGI請求時(shí),服務(wù)器會(huì )為應用程序提供環(huán)境上下文及一個(gè)回調函數(Callback Function)。當應用程序完成處理請求后,透過(guò)先前的回調函數,將結果回傳給服務(wù)器。所謂的 WSGI 中間件同時(shí)實(shí)現了API的兩方,因此可以在WSGI服務(wù)和WSGI應用之間起調解作用:從WSGI服務(wù)器的角度來(lái)說(shuō),中間件扮演應用程序,而從應用程序的角度來(lái)說(shuō),中間件扮演服務(wù)器?!爸虚g件”組件可以執行以下功能:
重寫(xiě)環(huán)境變量后,根據目標URL,將請求消息路由到不同的應用對象。
允許在一個(gè)進(jìn)程中同時(shí)運行多個(gè)應用程序或應用框架。
負載均衡和遠程處理,通過(guò)在網(wǎng)絡(luò )上轉發(fā)請求和響應消息。
進(jìn)行內容后處理,例如應用XSLT樣式表。
以前,如何選擇合適的Web應用程序框架成為困擾Python初學(xué)者的一個(gè)問(wèn)題,這是因為,一般而言,Web應用框架的選擇將限制可用的Web服務(wù)器的選擇,反之亦然。那時(shí)的Python應用程序通常是為CGI,FastCGI,mod_python中的一個(gè)而設計,甚至是為特定Web服務(wù)器的自定義的API接口而設計的。WSGI沒(méi)有官方的實(shí)現, 因為WSGI更像一個(gè)協(xié)議。只要遵照這些協(xié)議,WSGI應用(Application)都可以在任何服務(wù)器(Server)上運行, 反之亦然。WSGI就是Python的CGI包裝,相對于Fastcgi是PHP的CGI包裝。
WSGI將 web 組件分為三類(lèi): web服務(wù)器,web中間件,web應用程序, wsgi基本處理模式為 : WSGI Server -> (WSGI Middleware)* -> WSGI Application 。
uwsgi:
uwsgi協(xié)議是一個(gè)uWSGI服務(wù)器自有的協(xié)議,它用于定義傳輸信息的類(lèi)型(type of information),每一個(gè)uwsgi packet前4byte為傳輸信息類(lèi)型描述,它與WSGI相比是兩樣東西。據稱(chēng)其效率是fcgi的10倍。具體的協(xié)議內容請參考:the uwsgi protocol(http://uwsgi-docs.readthedocs.org/en/latest/Protocol.html)
以上四者都可以理解為協(xié)議!協(xié)議!協(xié)議!實(shí)現了這樣的協(xié)議,就可以實(shí)現Web服務(wù)器與Web應用程序相關(guān)聯(lián)的web服務(wù)!
uWSGI:
uWSGI項目旨在為部署分布式集群的網(wǎng)絡(luò )應用開(kāi)發(fā)一套完整的解決方案。uWSGI主要面向web及其標準服務(wù),已經(jīng)成功的應用于多種不同的語(yǔ)言。由于uWSGI的可擴展架構,它能夠被無(wú)限制的擴展用來(lái)支持更多的平臺和語(yǔ)言。目前,你可以使用C,C++和Objective-C來(lái)編寫(xiě)插件。項目名稱(chēng)中的“WSGI”是為了向同名的Python Web標準表示感謝,因為WSGI為該項目開(kāi)發(fā)了第一個(gè)插件。uWSGI是一個(gè)Web服務(wù)器,它實(shí)現了WSGI協(xié)議、uwsgi、http等協(xié)議。uWSGI,既不用wsgi協(xié)議也不用FastCGI協(xié)議,而是自創(chuàng )了上文說(shuō)將的uwsgi協(xié)議。
uWSGI的主要特點(diǎn)如下:
超快的性能。
低內存占用(實(shí)測為apache2的mod_wsgi的一半左右)。
多app管理。
詳盡的日志功能(可以用來(lái)分析app性能和瓶頸)。
高度可定制(內存大小限制,服務(wù)一定次數后重啟等)。
Gunicorn:
和uWSGi類(lèi)似的工具,從rails的部署工具(Unicorn)移植過(guò)來(lái)的。但是它使用的協(xié)議是前文所講的WSGI,這是python2.5時(shí)定義的官方標準(PEP 333 ),根紅苗正,而且部署比較簡(jiǎn)單,詳細的使用教程請點(diǎn)擊這里(http://gunicorn.org/)。Gunicorn采用prefork模式,Gunicorn 服務(wù)器與各種 Web 框架兼容,只需非常簡(jiǎn)單的執行,輕量級的資源消耗,以及相當迅速。它的特點(diǎn)是與 Django 結合緊密,部署特別方便。 缺點(diǎn)也很多,不支持 HTTP 1.1,并發(fā)訪(fǎng)問(wèn)性能不高,與 uWSGI,Gevent 等有一定的性能差距。
1. Gunicorn設計
Gunicorn 是一個(gè) master 進(jìn)程,spawn 出數個(gè)工作進(jìn)程的 web 服務(wù)器。master 進(jìn)程控制工作進(jìn)程的產(chǎn)生與消亡,工作進(jìn)程只需要接受請求并且處理。這樣分離的方式使得 reload 代碼非常方便,也很容易增加或減少工作進(jìn)程。 工作進(jìn)程這塊作者給了很大的擴展余地,它可以支持不同的IO方式,如 Gevent,Sync 同步進(jìn)程,Asyc 異步進(jìn)程,Eventlet 等等。master 跟 worker 進(jìn)程完全分離,使得 Gunicorn 實(shí)質(zhì)上就是一個(gè)控制進(jìn)程的服務(wù)。
2. Gunicorn源碼結構
從 Application.run() 開(kāi)始,首先初始化配置,從文件讀取,終端讀取等等方式完成 configurate。然后啟動(dòng) Arbiter,Arbiter 是實(shí)質(zhì)上的 master 進(jìn)程的核心,它首先從配置類(lèi)中讀取并設置,然后初始化信號處理函數,建立 socket。然后就是開(kāi)始 spawn 工作進(jìn)程,根據配置的工作進(jìn)程數進(jìn)行 spawn。然后就進(jìn)入了輪詢(xún)狀態(tài),收到信號,處理信號然后繼續。這里喚醒進(jìn)程的方式是建立一個(gè) PIPE,通過(guò)信號處理函數往 pipe 里 write,然后 master 從 select.select() 中喚醒。
工作進(jìn)程在 spawn 后,開(kāi)始初始化,然后同樣對信號進(jìn)行處理,并且開(kāi)始輪詢(xún),處理 HTTP 請求,調用 WSGI 的應用端,得到 resopnse 返回。然后繼續。
Sync 同步進(jìn)程的好處在于每個(gè) request 都是分離的,每個(gè) request 失敗都不會(huì )影響其他 request,但這樣導致了性能上的瓶頸。
Tornado:
Tornado即使一款python 的開(kāi)發(fā)框架,也是一個(gè)異步非阻塞的http服務(wù)器,它本身的數據產(chǎn)出實(shí)現沒(méi)有遵從上文所說(shuō)的一些通用協(xié)議,因為自身就是web服務(wù)器,所以動(dòng)態(tài)請求就直接通過(guò)內部的機制,輸出成用戶(hù)所請求的動(dòng)態(tài)內容。如果把它作為一個(gè)單獨服務(wù)器,想用它來(lái)配合其他的框架如Flask來(lái)部署,則需要采用WSGI協(xié)議,Tornado內置了該協(xié)議,tornado.wsgi.WSGIContainer。
wsgiref:
Python自帶的實(shí)現了WSGI協(xié)議的的wsgi server。wsgi server可以理解為一個(gè)符合wsgi規范的web server,接收request請求,封裝一系列環(huán)境變量,按照wsgi規范調用注冊的wsgi app,最后將response返回給客戶(hù)端。Django的自帶服務(wù)器就是它了。
以上都可以理解為實(shí)現!實(shí)現!實(shí)現!實(shí)現了協(xié)議的工具!
注:mod_wsgi(apache的模塊)其實(shí)也是實(shí)現了wsgi協(xié)議的一個(gè)模塊,現在幾乎不廢棄了,所以也不多說(shuō)了,感興趣的自己查一下吧。
所以如果你采用Django框架開(kāi)發(fā)了應用之后,想部署到生產(chǎn)環(huán)境,肯定不能用Django自帶的,可以用使用uwsgi協(xié)議的uWSGI服務(wù)器,也可以采用實(shí)現了WSGI協(xié)議的gunicorn或者Tornado,亦可以用FastCGI、CGI模式的Nginx、lighttpd、apache服務(wù)器。其他框架亦如此!明白了這些概念在部署的時(shí)候就可以做到心中有數,各種工具之間的搭配也就“知其然,并知其所以然”了。
在我們組的項目中有兩種框架Django和Tornado,生產(chǎn)環(huán)境也用到了兩種部署方式。uWSGI和Gunicorn:
Django項目用Nginx+uWSGI方式部署,Tornado項目用Nginx+Gunicorn方式部署:
Nginx都作為負載均衡以及靜態(tài)內容轉發(fā)。Tornado項目用supervisord來(lái)管理Gunicorn,用Gunicorn管理Tornado。眾所周知,由于Python的GIL存在,所以Python的并發(fā)都采用多進(jìn)程模式,所以我們部署的方式是一個(gè)核心兩個(gè)進(jìn)程。
-
cpu
+關(guān)注
關(guān)注
68文章
10525瀏覽量
207449 -
服務(wù)器
+關(guān)注
關(guān)注
12文章
8302瀏覽量
83229 -
python
+關(guān)注
關(guān)注
53文章
4700瀏覽量
83648
原文標題:Python Web部署方式全匯總
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關(guān)注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論