• 前面文章中環(huán)境都配置好了，現(xiàn)在是正餐了。
  為什么要使用gunicorn和nginx部署項目：
• 1. 平時開發(fā)直接啟動項目，沒有任何配置依然可以訪問？
     因為djaong或者flask自帶了一個實現(xiàn)了WSGI協(xié)議的server 和 application， 各個web framework也基本上都有自己實現(xiàn)的WSGI server， 但這個server基本上只能用來調(diào)試，不能用于生產(chǎn)環(huán)境，性能沒保障。
     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是實現(xiàn)了WSGI協(xié)議的web服務器
     uWSGI：是一個全功能的HTTP服務器，實現(xiàn)了WSGI協(xié)議、uwsgi協(xié)議、http協(xié)議等。
     用于接受http請求并轉換為WSGI協(xié)議，以供實現(xiàn)了WSGI協(xié)議的flask使用，并且gunicorn得益于gevent等技術，大幅度提高了性能，在生產(chǎn)環(huán)境以替代框架自帶的WSGI server。
     tornado之類的框架只支持單核，gunicorn可以提供多進程支持，提升多核服務器的處理性能。

3. WSGI協(xié)議
   全稱Web Server Gateway Interface，WSGI是一種規(guī)范，用來描述web server如何與web application通信的規(guī)范。
   要實現(xiàn)WSGI協(xié)議，必須同時實現(xiàn)web server和web application，uWSGI和gunicorn都是實現(xiàn)了WSGI server協(xié)議的服務器，Django/Flask是實現(xiàn)了WSGI application協(xié)議的web框架，因此uWSGI 接收了http請求后轉化為WSGI協(xié)議，uWSGI便能和flask進行通信。
   WSGI協(xié)議的server： 是把HTTP協(xié)議轉化成支持的網(wǎng)絡協(xié)議。比如把HTTP協(xié)議轉化成WSGI協(xié)議，讓Python可以直接使用。
   總結：啰里八嗦一大堆，一句話還重復說幾次?？傊褪菍崿F(xiàn)協(xié)議轉換，把接收到的http請求在內(nèi)部轉換成WSIG協(xié)議格式的請求，這樣應用就可以處理這些請求了。
   一般并發(fā)量不是特別高的情況下，使用gunicorn或者uWSGI部署項目就足夠了。
   二. 為什么還要加一成nginx？
4. nginx也是一種web服務器，但功能和gunicorn/uWSGI有些差別
   nginx沒有實現(xiàn)WSGI協(xié)議，如果是nginx+flask的組合的話就必須使用框架自帶的WSGI server，性能渣。
   靜態(tài)文件支持，經(jīng)過配置之后，nginx可以直接處理靜態(tài)文件請求而不用經(jīng)過應用服務器，避免占用寶貴的運算資源；還能緩存靜態(tài)資源，使訪問靜態(tài)資源的速度提高。
   抗并發(fā)壓力?？梢晕找恍┧矔r的高并發(fā)請求，讓nginx先保持住連接(緩存http請求)，然后后端慢慢消化。如果讓Gunicorn直接提供服務，瀏覽器發(fā)起一個請求，鑒于瀏覽器和網(wǎng)絡情況都是未知的，http請求的發(fā)起過程可能比較慢，而Gunicorn只能等待請求發(fā)起完成后，才去真正處理請求，處理完成后，等客戶端完全接收請求后，才繼續(xù)下一個。
   HTTP 請求緩存頭處理得也比 gunicorn和uWSGI 完善。
   多臺服務器時，可以提供負載均衡和反向代理。
   大意如圖
   image.png
   
   原文鏈接：https://blog.csdn.net/Aifore/article/details/86703685

• 1. 由于是前后端分離的項目，前端使用vue-cli，前端文件需要打包
     至于打包的注意問題：http://www.itdecent.cn/p/45acfd463347
     然后執(zhí)行：npm run build 會得到一個dist文件夾。打開index.html就可以看到頁面了
     我將dist文件copy到后端Django目錄下，然后再centos中做部署。

安裝gunicorn：pip install gunicorn(我在批量安裝包的時候已經(jīng)安裝上去了)

先試著運行一下，進入項目的根目錄(不是wsgi的同級目錄，是wsgi的上一層目錄)，然后

• 1.gunicorn -w 3 -b 127.0.0.1:8080 MOTTA_mall.wsgi:application 啟動成功
  -w workers:處理工作進程的數(shù)量
  -D --daemon： 守護進程后臺運行
  -b ADDRESS, --bind ADDRESS
  Gunicorn綁定服務器套接字，Host形式的字符串格式。Gunicorn可綁定多個套接字，如：gunicorn -b 127.0.0.1:8000 -b [::1]:9000 manager:app
  參數(shù)參考：https://www.cnblogs.com/zgcblog/p/10923913.html

• 2.通過配置文件啟動，gunicorn -c gunicorn-config.py MOTTA_mall.wsgi:application
  

  還有更加復雜的，我是簡單的配置了下
  image.png
  
  啟動后：前端的項目是可以訪問了，就如訪問Django服務器一樣。但是要注意下
  

  1.前端項目的ip地址，是否在setting.py文件白名單中。
  2.關閉防火墻，不然會攔截（systemctl status firewalld.service查看狀態(tài)，如果是開啟的，關閉它）
  OK，前端項目正常訪問。

安裝nginx：yum install nginx

yum 安裝的 nginx，通常 nginx 命令會位于 /usr/sbin目錄下。
which nginx cd 在目錄中
目錄中啟動：sudo nginx 然后直接在瀏覽器輸入服務器端地址，看到了啟動的頁面

image.png