概念
WSGI是Web服務器網關接口。它是一個規范，描述了Web服務器如何與Web應用程序通信，以及Web應用程序如何鏈接在一起以處理一個請求，（接收請求，處理請求，響應請求）
基於wsgi運行的框架有bottle,DJango,Flask,用於解析動態HTTP請求
支持WSGI的服務器
wsgiref
python自帶的web服務器
Gunicorn
用於linux的 python wsgi Http服務器，常用於各種django，flask結合部署服務器。
mode_wsgi
實現了Apache與wsgi應用程序的結合
uWSGI
C語言開發，快速，自我修復，開發人員友好的WSGI服務器，用於Python Web應用程序的專業部署和開發。
在部署python程序web應用程序時，可以根據性能的需求，選擇合適的wsgi server，不同的wsgi server區別在於並發支持上，有單線程，多進程，多線程，協程的區別，其功能還是近似，無非是請求路由，執行對應的函數，返回處理結果。
Django部署
Django的主要部署平台是 WSGI，這是用於Web服務器和應用程序的Python標准。
Django的 startproject管理命令設置一個簡單的默認WSGI配置，可以根據需要為您的項目進行調整，並指示任何符合WSGI的應用程序服務器使用。
application
使用WSGI部署的關鍵概念是應用程序服務器用於與代碼通信的 application 可調用。它通常在服務器可訪問的Python模塊中作為名為 application 的對象提供。
startproject 命令創建包含這樣的 application 可調用的文件 <project_name>/wsgi.py. ，它被Django的開發服務器和生產WSGI部署使用。
WSGI服務器從其配置中獲取 application 可調用的路徑。 Django的內置服務器，即 runserver 命令，從 WSGI_APPLICATION 設置讀取它。
1 首先nginx 是對外的服務接口，外部瀏覽器通過url訪問nginx,
2nginx 接收到瀏覽器發送過來的http請求，將包進行解析，分析url，如果是靜態文件請求就直接訪問用戶給nginx配置的靜態文件目錄，直接返回用戶請求的靜態文件，
如果不是靜態文件，而是一個動態的請求，那么nginx就將請求轉發給uwsgi,uwsgi 接收到請求之后將包進行處理，處理成wsgi可以接受的格式，並發給wsgi,wsgi 根據請求調用應用程序的某個文件，某個文件的某個函數，最后處理完將返回值再次交給wsgi,wsgi將返回值進行打包，打包成uwsgi能夠接收的格式，uwsgi接收wsgi 發送的請求，並轉發給nginx,nginx最終將返回值返回給瀏覽器。
3要知道第一級的nginx並不是必須的，uwsgi完全可以完成整個的和瀏覽器交互的流程，但是要考慮到某些情況
1 安全問題，程序不能直接被瀏覽器訪問到，而是通過nginx,nginx只開放某個接口，uwsgi本身是內網接口，這樣運維人員在nginx上加上安全性的限制，可以達到保護程序的作用。
2負載均衡問題，一個uwsgi很可能不夠用，即使開了多個work也是不行，畢竟一台機器的cpu和內存都是有限的，有了nginx做代理，一個nginx可以代理多台uwsgi完成uwsgi的負載均衡。
3靜態文件問題，用django或是uwsgi這種東西來負責靜態文件的處理是很浪費的行為，而且他們本身對文件的處理也不如nginx好，所以整個靜態文件的處理都直接由nginx完成，靜態文件的訪問完全不去經過uwsgi以及其后面的東西。
為什么要用nginx,uwsgi
梳理
nginx、WSGI、uwsgi、uWSGI、django這幾個關系梳理一下
wsgi 全稱web server gateway interface，wsgi不是服務器，也不是python模塊，只是一種協議，描述web server如何和web application通信的規則。
運行在wsgi上的web框架有bottle，flask，django
uwsgi 和wsgi一樣是通信協議，是uWSGI服務器的單獨協議，用於定義傳輸信息的類型
uWSGI 是一個web服務器，實現了WSGI協議，uwsgi協議。a
nginx web服務器，更加安全，更好的處理處理靜態資源，緩存功能，負載均衡，因此nginx的強勁性能，配合uWSGI服務器會更加安全，性能有保障。
django 高級的python web框架，用於快速開發，解決web開發的大部分麻煩，程序員可以更專注業務邏輯，無須重新造輪子
web服務器
傳統的c/s架構，請求的過程是
客戶端 > 服務器
服務器 > 客戶端
服務器就是：1.接收請求 2.處理請求 3.返回響應
web框架層
HTTP的動態數據交給web框架，例如django遵循MTV模式處理請求。
HTTp協議使用url定位資源，urls.py將路由請求交給views視圖處理，然后返回一個結果，完成一次請求。
web框架使用者只需要處理業務的邏輯即可。
如果將一次通信轉化為“對話”的過程
Nginx：hello wsgi，我剛收到一個請求，你准備下然后讓django來處理吧
WSGI：好的nginx，我馬上設置環境變量，然后把請求交給django
Django：謝謝WSGI，我處理完請求馬上給你響應結果
WSGI：好的，我在等着
Django：搞定啦，麻煩wsgi吧響應結果傳遞給nginx
WSGI：太棒了，nginx，響應結果請收好，已經按照要求傳遞給你了
nginx：好滴。我把響應交給用戶。合作愉快
uwsgi啟動python web
讓你的django在linux上，支持並發形式啟動，支持多進程，多線程，乃至於協程的一個C語言編寫的高性能工具
1.安裝uwsgi工具
pip3 install -i https://pypi.douban.com/simple uwsgi
2.編寫uwsgi.ini配置文件，以多進程形式啟動tf_crm
touch uwsgi.ini #手動創建此uwsgi的配置文件，寫入如下的內容參數，去啟動crm
# 寫入如下的功能性的參數配置，用於啟動項目
# 這些部署的流程，是國外的uwsgi官網，給與的用法，我們照着用即可
# 注意要根據你自己的目錄，修改如下的參數
[uwsgi]
# Django-related settings
# the base directory (full path)
# 填寫crm項目的第一層絕對路徑
chdir = /opt/sssss/
# Django's wsgi file
# 填寫crm項目第二層的相對路徑，找到第二層目錄下的wsgi.py
# 這里填寫的不是路徑，是以上一個參數為相對，找到第二層項目目錄下的wsgi.py文件
module = sssss.wsgi
# the virtualenv (full path)
# 填寫虛擬環境解釋器的第一層工作目錄
home = /opt/sssss/saas
# process-related settings
# master
master = true
# maximum number of worker processes
# 代表定義uwsgi運行的多進程數量，官網給出的優化建議是 2*cpu核數+1 ，單核的cpu填寫幾?
# 如果是單進程，十萬個請求，都丟給一個進程去處理
# 3個工作進程，十萬個請求，就分給了3個進程去分攤處理
processes = 3
# the socket (use the full path to be safe
# 這里的socket參數，是用於和nginx結合部署的unix-socket參數，這里臨時先暫停使用
# socket = 0.0.0.0:8000
# 線上不會用http參數，因為對后端是不安全的，使用socket參數是安全的連接，用nginx反向代理去訪問
# 后端程序是運行在防火牆內部，外網是無法直接訪問的
# 臨時使用http參數，便於我們用瀏覽器調試訪問
http = 0.0.0.0:8000
# ... with appropriate permissions - may be needed
# chmod-socket = 664
# clear environment on exit
vacuum = true
3.此時可以用命令，基於uwsgi協議的一個高性能web后端啟動了
uwsgi --ini ./uwsgi.ini #指定配置文件啟動后端
4.此時crm項目，已經用uwsgi支持了3個進程的啟動了，但是由於uwsgi對靜態文件的解析性能很弱，線上是丟給nginx去處理的
配置uwsgi
[uwsgi]
#使用nginx連接時使用，Django程序所在服務器地址
socket=0.0.0.0:8001
#直接做web服務器使用，Django程序所在服務器地址
#http=192.168.88.128:8003
#項目目錄
chdir=/home/yulinapp
#項目中wsgi.py文件的目錄，相對於項目自錄
wsgi-file=yulinapp/industrial_infomation_api/wsgi.py
#進程數
processes=4
#線程數
threads=2
#uwsgi服務器的角色
master=True
#存放進程編號的文件
pidfile=uwsgi. pid
#用戶
uid=root
gid=root