一. 爲什麼要使用gunicorn或者uWSGI?
1. 平時開發直接啓動項目,沒有任何配置依然可以訪問?
- 因爲djaong或者flask自帶了一個實現了WSGI協議的server 和 application, 各個web framework也基本上都有自己實現的WSGI server, 但這個server基本上只能用來調試,不能用於生產環境,性能沒保障。
- django 通過自帶的runserver (python manage.py runserver 0.0.0.0:8000)命令啓動,啓動文件地址:/Users/fxx/Study/Venv/Heat_venv/lib/python3.7/site-packages/django/core/management/commands/runserver.py 作爲WSGI server的啓動入口,可從這裏開始查看源代碼。
2. gunicorn和uWSGI是實現了WSGI協議的web服務器
- uWSGI:是一個全功能的HTTP服務器,實現了WSGI協議、uwsgi協議、http協議等。
- 用於接受http請求並轉換爲WSGI協議,以供實現了WSGI協議的flask使用,並且gunicorn得益於gevent等技術,大幅度提高了性能,在生產環境以替代框架自帶的WSGI server。
- tornado之類的框架只支持單核,gunicorn可以提供多進程支持,提升多核服務器的處理性能。
3. WSGI協議
全稱Web Server Gateway Interface
,WSGI
是一種規範,用來描述web server
如何與web application
通信的規範。
- 要實現WSGI協議,必須同時實現web server和web application,
uWSGI
和gunicorn都是實現了WSGI server
協議的服務器,Django/Flask是實現了WSGI
application協議的web框架,因此uWSGI 接收了http請求後轉化爲WSGI協議,uWSGI便能和flask進行通信。 - WSGI協議的server: 是把HTTP協議轉化成支持的網絡協議。比如把HTTP協議轉化成WSGI協議,讓Python可以直接使用。
總結:囉裏八嗦一大堆,一句話還重複說幾次。總之就是實現協議轉換,把接收到的http請求在內部轉換成WSIG協議格式的請求,這樣應用就可以處理這些請求了。
一般併發量不是特別高的情況下,使用gunicorn或者uWSGI部署項目就足夠了。
二. 爲什麼還要加一成nginx?
1. nginx也是一種web服務器,但功能和gunicorn/uWSGI有些差別
-
nginx沒有實現WSGI協議,如果是nginx+flask的組合的話就必須使用框架自帶的WSGI server,性能渣。
-
靜態文件支持,經過配置之後,nginx可以直接處理靜態文件請求而不用經過應用服務器,避免佔用寶貴的運算資源;還能緩存靜態資源,使訪問靜態資源的速度提高。
-
抗併發壓力。可以吸收一些瞬時的高併發請求,讓nginx先保持住連接(緩存http請求),然後後端慢慢消化。如果讓Gunicorn直接提供服務,瀏覽器發起一個請求,鑑於瀏覽器和網絡情況都是未知的,http請求的發起過程可能比較慢,而Gunicorn只能等待請求發起完成後,纔去真正處理請求,處理完成後,等客戶端完全接收請求後,才繼續下一個。
-
HTTP 請求緩存頭處理得也比 gunicorn和uWSGI 完善。
-
多臺服務器時,可以提供負載均衡和反向代理。
大意如圖: