前言:

又是WSGI ,這是我曾經(jīng)比較熟悉的協(xié)議，以前針對實現(xiàn)了wsgi server的unicorn和uwsgi都寫過源碼解析的文章。  其實他們的實現(xiàn)也很簡單，就是給flask、django這樣的application傳遞environ,start_response 。

什么是WSGI協(xié)議，什么是WSGI Server，他們的區(qū)別是什么？

上線的架構圖很容易誤導別人，乍一看有nginx這樣的web服務器，又有gunicorn這樣的wsgi server。  我們先說明wsgi 跟 wsgi server的關系，wsgi是個協(xié)議，是web底層跟application解耦的協(xié)議。wsgi server是自己做web服務器借用wsgi協(xié)議來調(diào)用application。 我們需要明確一點，nginx是無法直接跟flask application做通信，需要借用wsgi server。flask本身也有個web服務器是werkzeug，so 才能啟動服務并監(jiān)聽端口。記得以前uwsgi沒名氣的時候，我們都在使用apache + mode_wsgi模式，apache也無法直接跟tornado通信，是借用mod_wsgi把torando做成了unix socket服務，說白了也是啟動了一個服務，靠apache來轉發(fā)。

nginx、apache在這里只是啟動了proxy的作用，那為什么不直接把uwsgi和gunicorn給暴露出去，因為nginx的靜態(tài)文件處理能力極強。

WSGI怎么工作的

wsgi主要是兩層，服務器方 和 應用程序 :

1  服務器方：從底層解析http解析，然后調(diào)用應用程序，給應用程序提供(環(huán)境信息)和(回調(diào)函數(shù))， 這個回調(diào)函數(shù)是用來將應用程序設置的http header和status等信息傳遞給服務器方.

2  應用程序：用來生成返回的header,body和status,以便返回給服務器方。

WSGI把來自socket的數(shù)據(jù)包解析為http格式，然后進而變化為environ變量，這environ變量里面有wsgi本身的信息(比如 host， post，進程模式等)，還有client的header及body信息。start_respnse是一個函調(diào)函數(shù)，必須要附帶兩個參數(shù)，一個是status(http狀態(tài))，response_headers(響應的header頭信息)。

像flask、django、tornado都會暴露WSGI協(xié)議入口，我們只需要自己實現(xiàn)WSGI協(xié)議，wsgi server然后給flask傳遞environ，及start_response, 等到application返回值之后，我再socket send返回客戶端。

WSGI的優(yōu)點、缺點是什么？

優(yōu)點:

多樣的部署選擇和組件之間的高度解耦

由于上面提到的高度解耦特性，理論上，任何一個符合WSGI規(guī)范的App都可以部署在任何一個實現(xiàn)了WSGI規(guī)范的Server上，這給Python Web應用的部署帶來了極大的靈活性。

Flask自帶了一個基于Werkzeug的調(diào)試用服務器。根據(jù)Flask的文檔，在生產(chǎn)環(huán)境不應該使用內(nèi)建的調(diào)試服務器，而應該采取以下方式之一進行部署：

GUNICORN

UWSGI