歡迎光臨
每天分享高質量文章

Python Web部署方式全彙總

學過PHP的都瞭解,php的正式環境部署非常簡單,改幾個檔案就OK,用FastCgi方式也是分分鐘的事情。相比起來,Python在web應用上的部署就繁雜的多,主要是工具繁多,主流服務器支持不足。

轉載宣告:本文轉載自「Python開發者」

ID:「PythonCoder」

在瞭解Python的生產環境部署方式之前,先明確一些概念!很重要

CGI:

CGI即通用網關接口(Common Gateway Interface),是外部應用程式(CGI程式)與Web服務器之間的接口標準,是在CGI程式和Web服務器之間傳遞信息的規程。CGI規範允許Web服務器執行外部程式,並將它們的輸出發送給Web瀏覽器,CGI將Web的一組簡單的靜態超媒體文件變成一個完整的新的交互式媒體。通俗的講CGI就像是一座橋,把網頁和WEB服務器中的執行程式連接起來,它把HTML接收的指令傳遞給服務器的執行程式,再把服務器執行程式的結果返還給HTML頁。CGI 的跨平臺性能極佳,幾乎可以在任何操作系統上實現。

CGI方式在遇到連接請求(用戶請求)先要創建cgi的子行程,激活一個CGI行程,然後處理請求,處理完後結束這個子行程。這就是fork-and-execute樣式。所以用cgi方式的服務器有多少連接請求就會有多少cgi子行程,子行程反覆加載是cgi性能低下的主要原因。當用戶請求數量非常多時,會大量擠占系統的資源如記憶體,CPU時間等,造成效能低下。

CGI腳本工作流程:

  1. 瀏覽器通過HTML表單或超鏈接請求指向一個CGI應用程式的URL。

  2. 服務器執行務器收發到請求。所指定的CGI應用程式。

  3. CGI應用程式執行所需要的操作,通常是基於瀏覽者輸入的內容。

  4. CGI應用程式把結果格式化為網絡服務器和瀏覽器能夠理解的文件(通常是HTML網頁)。

  5. 網絡服務器把結果傳回到瀏覽器中。

python有cgi模塊可支持原生cgi程式

FastCGI:

  FastCGI是一個可伸縮地、高速地在HTTP server和動態腳本語言間通信的接口。多數流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等,同時,FastCGI也被許多腳本語言所支持,其中就有Python。FastCGI是從CGI發展改進而來的。傳統CGI接口方式的主要缺點是性能很差,因為每次HTTP服務器遇到動態程式時都需要重新啟動腳本解析器來執行解析,然後結果被傳回給HTTP服務器。這在處理高併發訪問時,幾乎是不可用的。FastCGI像是一個常駐(long-live)型的CGI,它可以一直執行著,只要激活後,不會每次都要花費時間去fork一次(這是CGI最為人詬病的fork-and-execute 樣式)。CGI 就是所謂的短生存期應用程式,FastCGI 就是所謂的長生存期應用程式。由於 FastCGI 程式並不需要不斷的產生新行程,可以大大降低服務器的壓力並且產生較高的應用效率。它的速度效率最少要比CGI 技術提高 5 倍以上。它還支持分佈式的運算, 即 FastCGI 程式可以在網站服務器以外的主機上執行並且接受來自其它網站服務器來的請求。

FastCGI是語言無關的、可伸縮架構的CGI開放擴展,其主要行為是將CGI解釋器行程保持在記憶體中並因此獲得較高的性能。眾所周知,CGI解釋器的反覆加載是CGI性能低下的主要原因,如果CGI解釋器保持在記憶體中並接受FastCGI行程管理器調度,則可以提供良好的性能、伸縮性、Fail-Over特性等等。FastCGI接口方式採用C/S結構,可以將HTTP服務器和腳本解析服務器分開,同時在腳本解析服務器上啟動一個或者多個腳本解析守護行程。當HTTP服務器每次遇到動態程式時,可以將其直接交付給FastCGI行程來執行,然後將得到的結果傳回給瀏覽器。這種方式可以讓HTTP服務器專一地處理靜態請求或者將動態腳本服務器的結果傳回給客戶端,這在很大程度上提高了整個應用系統的性能。

FastCGI的工作流程:

  1. Web Server啟動時載入FastCGI行程管理器(PHP-CGI或者PHP-FPM或者spawn-cgi)

  2. FastCGI行程管理器自身初始化,啟動多個CGI解釋器行程(可見多個php-cgi)並等待來自Web Server的連接。

  3. 當客戶端請求到達Web Server時,FastCGI行程管理器選擇並連接到一個CGI解釋器。Web server將CGI環境變數和標準輸入發送到FastCGI子行程php-cgi。

  4. FastCGI子行程完成處理後將標準輸出和錯誤信息從同一連接傳回Web Server。當FastCGI子行程關閉連接時,請求便告處理完成。FastCGI子行程接著等待並處理來自FastCGI行程管理器(運行在Web Server中)的下一個連接。 在CGI樣式中,php-cgi在此便退出。

FastCGI 的特點:

  1. 打破傳統頁面處理技術。傳統的頁面處理技術,程式必須與 Web 服務器或 Application 服務器處於同一臺服務器中。這種歷史已經早N年被FastCGI技術所打破,FastCGI技術的應用程式可以被安裝在服務器群中的任何一臺服務器,而通過 TCP/IP 協議與 Web 服務器通訊,這樣做既適合開發大型分佈式 Web 群,也適合高效資料庫控制。

  2. 明確的請求樣式。CGI 技術沒有一個明確的角色,在 FastCGI 程式中,程式被賦予明確的角色(響應器角色、認證器角色、過濾器角色)。

WSGI:

  Python Web服務器網關接口(Python Web Server Gateway Interface,縮寫為WSGI)是為Python語言定義的Web服務器和Web應用程式或框架之間的一種簡單而通用的接口。自從WSGI被開發出來以後,許多其它語言中也出現了類似接口。WSGI是作為Web服務器與Web應用程式或應用框架之間的一種低級別的接口,以提升可移植Web應用開發的共同點。WSGI是基於現存的CGI標準而設計的。

WSGI區分為兩個部份:一為“服務器”或“網關”,另一為“應用程式”或“應用框架”。在處理一個WSGI請求時,服務器會為應用程式提供環境背景關係及一個回呼函式(Callback Function)。當應用程式完成處理請求後,透過先前的回呼函式,將結果回傳給服務器。所謂的 WSGI 中間件同時實現了API的兩方,因此可以在WSGI服務和WSGI應用之間起調解作用:從WSGI服務器的角度來說,中間件扮演應用程式,而從應用程式的角度來說,中間件扮演服務器。“中間件”組件可以執行以下功能:

  1. 重寫環境變數後,根據標的URL,將請求訊息路由到不同的應用物件。

  2. 允許在一個行程中同時運行多個應用程式或應用框架。

  3. 負載均衡和遠程處理,通過在網絡上轉發請求和響應訊息。

  4. 進行內容後處理,例如應用XSLT樣式表。

以前,如何選擇合適的Web應用程式框架成為困擾Python初學者的一個問題,這是因為,一般而言,Web應用框架的選擇將限制可用的Web服務器的選擇,反之亦然。那時的Python應用程式通常是為CGI,FastCGI,mod_python中的一個而設計,甚至是為特定Web服務器的自定義的API接口而設計的。WSGI沒有官方的實現, 因為WSGI更像一個協議。只要遵照這些協議,WSGI應用(Application)都可以在任何服務器(Server)上運行, 反之亦然。WSGI就是Python的CGI包裝,相對於Fastcgi是PHP的CGI包裝。

WSGI將 web 組件分為三類: web服務器,web中間件,web應用程式, wsgi基本處理樣式為 : WSGI Server -> (WSGI Middleware)* -> WSGI Application 。

uwsgi:

uwsgi協議是一個uWSGI服務器自有的協議,它用於定義傳輸信息的型別(type of information),每一個uwsgi packet前4byte為傳輸信息型別描述,它與WSGI相比是兩樣東西。據稱其效率是fcgi的10倍。具體的協議內容請參考:the uwsgi protocol(http://uwsgi-docs.readthedocs.org/en/latest/Protocol.html)

以上四者都可以理解為協議!協議!協議!實現了這樣的協議,就可以實現Web服務器與Web應用程式相關聯的web服務!

uWSGI:

  uWSGI專案旨在為部署分佈式集群的網絡應用開發一套完整的解決方案。uWSGI主要面向web及其標準服務,已經成功的應用於多種不同的語言。由於uWSGI的可擴展架構,它能夠被無限制的擴展用來支持更多的平臺和語言。目前,你可以使用C,C++和Objective-C來編寫插件。專案名稱中的“WSGI”是為了向同名的Python Web標準表示感謝,因為WSGI為該專案開發了第一個插件。uWSGI是一個Web服務器,它實現了WSGI協議、uwsgi、http等協議。uWSGI,既不用wsgi協議也不用FastCGI協議,而是自創了上文說將的uwsgi協議。

uWSGI的主要特點如下:

  1. 超快的性能。

  2. 低記憶體占用(實測為apache2的mod_wsgi的一半左右)。

  3. 多app管理。

  4. 詳盡的日誌功能(可以用來分析app性能和瓶頸)。

  5. 高度可定製(記憶體大小限制,服務一定次數後重啟等)。

Gunicorn:

  和uWSGi類似的工具,從rails的部署工具(Unicorn)移植過來的。但是它使用的協議是前文所講的WSGI,這是python2.5時定義的官方標準(PEP 333 ),根紅苗正,而且部署比較簡單,詳細的使用教程請點擊這裡(http://gunicorn.org/)。Gunicorn採用prefork樣式,Gunicorn 服務器與各種 Web 框架兼容,只需非常簡單的執行,輕量級的資源消耗,以及相當迅速。它的特點是與 Django 結合緊密,部署特別方便。 缺點也很多,不支持 HTTP 1.1,併發訪問性能不高,與 uWSGI,Gevent 等有一定的性能差距。

1. Gunicorn設計

Gunicorn 是一個 master 行程,spawn 出數個工作行程的 web 服務器。master 行程控制工作行程的產生與消亡,工作行程只需要接受請求並且處理。這樣分離的方式使得 reload 代碼非常方便,也很容易增加或減少工作行程。 工作行程這塊作者給了很大的擴展餘地,它可以支持不同的IO方式,如 Gevent,Sync 同步行程,Asyc 異步行程,Eventlet 等等。master 跟 worker 行程完全分離,使得 Gunicorn 實質上就是一個控制行程的服務。

2. Gunicorn原始碼結構

從 Application.run() 開始,首先初始化配置,從檔案讀取,終端讀取等等方式完成 configurate。然後啟動 Arbiter,Arbiter 是實質上的 master 行程的核心,它首先從配置類中讀取並設置,然後初始化信號處理函式,建立 socket。然後就是開始 spawn 工作行程,根據配置的工作行程數進行 spawn。然後就進入了輪詢狀態,收到信號,處理信號然後繼續。這裡喚醒行程的方式是建立一個 PIPE,通過信號處理函式往 pipe 里 write,然後 master 從 select.select() 中喚醒。

工作行程在 spawn 後,開始初始化,然後同樣對信號進行處理,並且開始輪詢,處理 HTTP 請求,呼叫 WSGI 的應用端,得到 resopnse 傳回。然後繼續。

Sync 同步行程的好處在於每個 request 都是分離的,每個 request 失敗都不會影響其他 request,但這樣導致了性能上的瓶頸。

Tornado:

  Tornado即使一款python 的開發框架,也是一個異步非阻塞的http服務器,它本身的資料產出實現沒有遵從上文所說的一些通用協議,因為自身就是web服務器,所以動態請求就直接通過內部的機制,輸出成用戶所請求的動態內容。如果把它作為一個單獨服務器,想用它來配合其他的框架如Flask來部署,則需要採用WSGI協議,Tornado內置了該協議,tornado.wsgi.WSGIContainer。

wsgiref:

  Python自帶的實現了WSGI協議的的wsgi server。wsgi server可以理解為一個符合wsgi規範的web server,接收request請求,封裝一系列環境變數,按照wsgi規範呼叫註冊的wsgi app,最後將response傳回給客戶端。Django的自帶服務器就是它了。

以上都可以理解為實現!實現!實現!實現了協議的工具!

註:mod_wsgi(apache的模塊)其實也是實現了wsgi協議的一個模塊,現在幾乎不廢棄了,所以也不多說了,感興趣的自己查一下吧。

所以如果你採用Django框架開發了應用之後,想部署到生產環境,肯定不能用Django自帶的,可以用使用uwsgi協議的uWSGI服務器,也可以採用實現了WSGI協議的gunicorn或者Tornado,亦可以用FastCGI、CGI樣式的Nginx、lighttpd、apache服務器。其他框架亦如此!明白了這些概念在部署的時候就可以做到心中有數,各種工具之間的搭配也就“知其然,並知其所以然”了。

在我們組的專案中有兩種框架Django和Tornado,生產環境也用到了兩種部署方式。uWSGI和Gunicorn:

Django專案用Nginx+uWSGI方式部署,Tornado專案用Nginx+Gunicorn方式部署:

Nginx都作為負載均衡以及靜態內容轉發。Tornado專案用supervisord來管理Gunicorn,用Gunicorn管理Tornado。眾所周知,由於Python的GIL存在,所以Python的併發都採用多行程樣式,所以我們部署的方式是一個核心兩個行程。

來源:titanjf

www.cnblogs.com/titanjf/p/python-web-deploy.html

《Python人工智慧和全棧開發》2018年07月23日即將在北京開課,120天衝擊Python年薪30萬,改變速約~~~~

*宣告:推送內容及圖片來源於網絡,部分內容會有所改動,版權歸原作者所有,如來源信息有誤或侵犯權益,請聯繫我們刪除或授權事宜。

– END –


更多Python好文請點擊【閱讀原文】哦

↓↓↓

赞(0)

分享創造快樂