爲什麼要使用gunicorn和nginx部署項目？

一. 爲什麼要使用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 完善。

• 多臺服務器時，可以提供負載均衡和反向代理。

大意如圖：