文章目錄

• WSGI / uwsgi / uWSGI
• Web Server和App Server
• 瀏覽器訪問Django開發的Web應用流程
• 圖解
• 為什麼多了個Nginx
• 參考資料

WSGI / uwsgi / uWSGI

WSGI（Web Server Gateway Interface） ：一種通訊協議，定義了 Web 伺服器與 Web 應用程式間的通訊規範。

uwsgi： 一種線路協議（不是通訊協議），常用於在 uWSGI 伺服器與其他網路伺服器的資料通訊。

uWSGI ：一個全功能的 HTTP 伺服器，實現了 WSGI 協議、uwsgi 協議、http 協議等。它要做的就是把 HTTP 協議轉化成語言支援的網路協議。比如把 HTTP 協議轉化成 WSGI 協議，讓 Python 可以直接使用。

Web Server和App Server

我們再來看下WSGI的定義：一種通訊協議，定義了 Web 伺服器與 Web 應用程式間的通訊規範。

Web應用程式本質上也是伺服器。

那為什麼要把服務端分成Web Server和App Server呢？

不難看出，對於一個大專案，不同的App 會載入在不同的 Server。

Web Server和App Server的解耦有助於專案後期的維護、更新。Web Server 可以實現負載均衡。同時，一個App Server掛掉，也不至於影響其他App Server。

那解耦後，它們間是如何進行互動的呢？一般來說，是Web 伺服器呼叫 App 伺服器。

另外還有一個問題，就是Web Server對於用不同Web框架開發出來的App ，支援性也不同。這種支援性意味著有的Web Server無法呼叫一些App Server。

由此，我們可以設立一個標準，只要Web Server支援這個標準，框架也支援這個標準，那麼他們就可以配合使用。一旦標準確定，雙方各自實現。這樣，伺服器可以支援更多支援標準的框架，框架也可以使用更多支援標準的伺服器。

這就是WSGI的由來。

瀏覽器訪問Django開發的Web應用流程

圖解

1、使用者發起Http Request後，首先Nginx伺服器會收到，解包、分析。
如果是靜態請求，則根據Nginx配置的靜態檔案目錄，返回請求的資源。
如果是動態的請求,Nginx根據配置檔案,將請求傳遞給uWSGI。

2、uWSGI 將接收到的包進行處理，並轉發給Django的wsgi。

3、wsgi根據請求呼叫Django工程的某個檔案或函式，處理完後Django將處理結果交給wsgi，wsgi將返回值進行打包，轉發給uWSGI。

4、uWSGI接收後轉發給Nginx，Nginx最終將處理結果返回給客戶端(如瀏覽器)。

*注:不同的元件之間傳遞資訊涉及到資料格式和協議的轉換

為什麼多了個Nginx

可以發現，相比我們在本地開發時，整個流程還多了個Nginx。

我們知道uWSGI是一個伺服器，既然有了uWSGI，那為什麼還要額外增設一個Nginx（Web Server）呢？

原因是uWSGI的效能不行，在本地跑跑測試還行，但面臨高併發的情況就會歇菜了。

再來說下Nginx，它是一個高效能的 HTTP 和反向代理服務，也是一個 IMAP/POP3/SMTP 服務。

Nginx 的優勢：

支援反向代理：所謂的反向代理，即既可以充當客戶端（瀏覽器）到目標伺服器的代理伺服器，又可以接著充當目標伺服器到客戶端的代理伺服器。

安全：因為所有請求都要經過代理伺服器，這樣就避免了外部程式直接攻擊 Web 伺服器。

負載均衡：根據請求情況和伺服器負載情況，將請求分配給不同的目標伺服器（當然處理結果是一樣的），保證伺服器效能。

參考資料

[1] https://blog.csdn.net/c465869935/article/details/53242126?utm_source=blogxgwz3
[2] https://blog.csdn.net/qq_35318838/article/details/61198183?utm_source=blogxgwz0