1. 程式人生 > >Nginx, WSGI, Django之間的關係

Nginx, WSGI, Django之間的關係

概覽

對 Nginx,WSGI(或者 uWSGI,uwsgi),Django,這幾者的關係一存存在疑惑。通過查閱了些資料,總算把它們的關係理清了。  總括來說,客戶端從傳送一個 HTTP 請求到 Django處理請求,分別經過了 web伺服器層,WSGI層,web框架層,這三個層次。不同的層次其作用也不同,下面簡要介紹各層的作用。

                      web伺服器,web框架與WSGI的三層關係

圖1:web伺服器,web框架與 WSGI 的三層關係

Web伺服器層

對於傳統的客戶端 - 伺服器架構,其請求的處理過程是,客戶端向伺服器傳送請求,伺服器接收請求並處理請求,然後給客戶端返回響應。在這個過程中,伺服器的作用是:

  1. 接收請求
  2. 處理請求
  3. 返回響應

Web伺服器是一類特殊的伺服器,其作用是主要是接收 HTTP 請求並返回響應。提起 web伺服器大家都不會陌生,常見的 web伺服器有 Nginx,Apache,IIS等。在上圖1的三層結構中,web伺服器是最先接收使用者請求的,並將響應結果返回給使用者。

Web框架層

Web框架的作用主要是方便我們開發 web應用程式,HTTP請求的動態資料就是由 web框架層來提供的。常見的 web框架有Flask,Django等,我們以 Django框架為例子,展示 web框架的作用:

建立一個 web應用程式物件 appapp 監聽機器所有 ip 的 8080 埠,接受使用者的請求連線。我們知道,HTTP 協議使用 URL 來定位資源,上面的程式會將路徑 /hello

 的請求交由 hello_world 方法處理,hello_world 返回 ‘Hello World!’ 字串。對於 web框架的使用者來說,他們並不關心如何接收 HTTP 請求,也不關心如何將請求路由到具體方法處理並將響應結果返回給使用者。Web框架的使用者在大部分情況下,只需要關心如何實現業務的邏輯即可。

WSGI層

WSGI 不是伺服器,也不是用於與程式互動的API,更不是真實的程式碼,WSGI 只是一種介面,它只適用於 Python 語言,其全稱為 Web Server Gateway Interface,定義了 web伺服器和 web應用之間的介面規範。也就是說,只要 web伺服器和 web應用都遵守WSGI協議,那麼 web伺服器和 web應用就可以隨意的組合。

值得指出的是,WSGI 是一種協議,需要區分幾個相近的名詞:

  • uwsgi  同 wsgi 一樣也是一種協議,uWSGI伺服器正是使用了 uwsgi 協議
  • uWSGI  實現了 uwsgi 和 WSGI 兩種協議的web伺服器。注意 uWSGI 本質上也是一種 web伺服器,處於上面描述的三層結構中的 web伺服器層。
  • CGI  通用閘道器介面,並不限於 Python 語言,定義了 web伺服器是如何向客戶端提供動態的內容。例如,規定了客戶端如何將引數傳遞給 web伺服器,web伺服器如何將引數傳遞給 web應用,web應用如何將它的輸出如何傳送給客戶端,等等。  生產環境下的 web應用都不使用 CGI 了,CGI程序(類似 Python 直譯器)針對每個請求建立,用完就拋棄,效率低下。WSGI 正是為了替代 CGI 而出現的。

我們基本理清了 WSGI 在 web伺服器與 web框架之間作用:WSGI 就像一條紐帶,將 web伺服器與 web框架連線起來。回到本文的題目,Nginx 屬於一種 web伺服器,Django屬於一種 web框架,因此,WSGI 與 Nginx、Django 的作用就不明而喻了。

最後以 Nginx,WSGI,Django 之間的對話結束本文。 Nginx:Hey,WSGI,我剛收到了一個請求,我需要你作些準備,然後由Flask來處理這個請求。 WSGI:OK,Nginx。我會設定好環境變數,然後將這個請求傳遞給Flask處理。 Django:Thanks WSGI!給我一些時間,我將會把請求的響應返回給你。 WSGI:Alright,那我等你。 Django:Okay,我完成了,這裡是請求的響應結果,請求把結果傳遞給Nginx。 WSGI:Good job!Nginx,這裡是響應結果,已經按照要求給你傳遞回來了。 Nginx:Cool,我收到了,我把響應結果返回給客戶端。大家合作愉快~