python專案部署
Web框架和Wen伺服器之間需要進行通訊,如果在設計時它們之間無法相互匹配,那麼對框架的選擇就會限制對Web伺服器的選擇,這顯然是不合理的。這時候需要設計一套雙方都遵守的介面。WSGI是Python Web Server Gateway Interface的簡稱。WSGI標準在PEP 333中定義並被許多框架實現,它規定了一種在Web伺服器之間具有可移植性。在後來的PEP 3333中添加了Python 3的支援和更多相關的說明。有了通用的WSGI協議,Web開發者就能夠任意選擇適合自己的組合,而Web伺服器和Web框架的開發者們也能夠把精力集中到各自的領域
常見的WSGI容器
WSGI是一個同步介面,所以Tornado的WSGI容器是無法實現非同步的。主流的選擇是Gunicorn和uWSGI。
Gunicorn
Gunicorn易於配置,相容性好,CPU消耗很少,在豆瓣使用廣泛。它支援多種Worker模式,推薦的模式有如如下幾種:
-
同步Worker:預設模式,也就是一次只處理一個請求
-
非同步Worker:通過Eventlet、Gevent實現的非同步模式
-
非同步IO Worker:目前支援gthread和gaiohttp兩種型別
安裝Gunicorn:
pip install gunicorn
Gunicorn的啟動非常簡單,語法如下:
gunicorn [OPTIONS] MODULE_NAME:VARIABLE_NAME
舉個栗子,manager.py:
from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): return "Hello World" if __name__ == "__main__": app.run()
啟動應用:
gunicorn manager:app -b 0.0.0.0:9000
gunicorn --workers=3manager:app -b 0.0.0.0:9000
uWSGI
uWSGI是使用C編寫的,顯示了自有的uwsgi協議的Web伺服器。它自帶豐富的元件,其中核心元件包含程序管理、監控、IPC等功能,實現應用伺服器介面的請求外掛支援多種語言和平臺,比如WSGI、Rack、Lua WSAPI,網管元件實現了負載均衡、代理和理由功能。
pip install uwsgi uwsgi --http 0.0.0.0:9000 --wsgi-file manager.py --callable app --processes 4 --threads 2 --stats 0.0.0.0:5000
上面的命令表示啟動了4個程序,每個程序使用2個執行緒,而且開啟了5000的Web介面,返回監控uWSGI的資訊,一級不同程序和執行緒的詳細使用情況。使用uWSGI有兩點十分重要:
–http-socket
和–http
其實是完全不同的兩個選項。如果想直接裸跑uWSGI,應該使用–http
,它產生一個額外的程序將請求轉發給Workers,如果希望它被反向代理(比如和Nginx一起使用),應該使用–http-socket
。
合理的程序數和執行緒數不能簡單的通過CPU * 2來計算得出,需要不斷的嘗試而找到最佳值。
uWSGI命令常用引數如下:
引數名 | 含義 |
---|---|
–http | 協議型別和埠號 |
–processes | 開啟的程序數量 |
–callable | uWSGI載入的模組哪個變數將被呼叫 |
–workers | 開啟的進行數量,等同於processes |
–chdir | 指定執行目錄 |
–wsgi-file | 載入wsgi-file(載入wsgi.py檔案) |
–stats | 在指定的地址上開啟狀態服務 |
–threads | 開啟的執行緒數量 |
–master | 允許主程序存在 |
–daemonize | 使程序在後臺執行,並將日誌輸出到指定的日誌檔案或者UDP伺服器 |
–pidfile | 指定PID檔案的位置,記錄主程序的PID號 |
–vacuum | 當伺服器退出時自動清理環境,刪除Unix Socket檔案和PID檔案 |