1、UWSGI介紹
Flask 中自帶了 web server，通過 Werkzeug，我們可以搭建 WSGI 服務，運行我們的網站，但 Flask 是 Web 框架，並不是 Web 服務器；
uWSGI 是一個全站式的託管服務，它實現了應用服務器（支持多種編程語言）、代理、進程管理器、監視器。取名爲 uWSGI 是因爲它最早實現的是 Python 語言的 WSGI。
uWSGI 包括四個部分：
• uwsgi協議
• web server 內置支持協議模塊
• application 服務器協議支持模塊
• 進程控制程序
uWSGI 是 C 語言寫的，性能比較高。
1. WSGI, uWSGI, uwsgi 的區別
WSGI
部署完一個應用程序，瀏覽網頁時具體的過程是：
首先得有一個 Web 服務器來處理 HTTP 協議的內容，Web 服務器獲得客戶端的請求，交給應用程序，應用程序處理完，返回給 Web 服務器，這時 Web 服務器再返回給客戶端。Web 服務器與應用程序之間顯然要進行交互，這時就出現了很多 Web 服務器與應用程序之間交互的規範，Python 專用的 WSGI 規範；
WSGI 全稱是 Web Server Gateway Interface，也就是 Web 服務器網關接口，它是 Python 語言定義出來的 Web 服務器和 Web 應用程序之間的簡單而通用的接口，基於現存的 CGI 標準設計，後來在很多其他語言中也出現了類似的接口。 總的來說，WSGI 可以分爲服務器和應用程序兩個部分，實際上可以將 WSGI 理解爲服務器與應用程序之間的一座橋，橋的一邊是服務器，另一邊是應用程序。
按照 web 組件分類，WSGI 內部可以分爲三類，web 應用程序，web 服務器，web 中間件。應用程序端的部分通過Python 語言的各種 Web 框架實現，比如 Flask，Django這些，有了框架，開發者就不需要處理 WSGI，框架會幫忙解決這些，開發者只需處理 HTTP 請求和響應，web 服務器的部分就要複雜一點，可以通過 uWSGI 實現，也可以用最常見的 Web 服務器，比如 Apache、Nginx，但這些 Web 服務器沒有內置 WSGI 的實現，是通過擴展完成的。如 Apache，通過擴展模塊 mod_wsgi 來支持WSGI，Nginx可以通過代理的方式，將請求封裝好，交給應用服務器，比如 uWSGI。uWSGI 可以完成 WSGI 的服務端，進程管理以及對應用的調用。WSGI 中間件的部分可以這樣理解：我們把 WSGI 看做橋，這個橋有兩個橋墩，一個是應用程序端，另一個是服務器端，那麼橋面就是 WSGI 中間件，中間件同時具備服務器、應用程序端兩個角色，當然也需要同時遵守 WSGI 服務器和 WSGI 應用程序兩邊的限制和需要。更詳細的內容可以看PEP-333 中間件的描述。
uWSGI、uwsgi
uWSGI 是一個 Web 服務器程序，WSGI，上面已經談到，是一種協議，uwsgi 也是一種協議，uWSGI 實現了 uwsgi、WSGI、http 等協議。uwsgi 是 uWSGI 使用的一個自有的協議，它用4個字節來定義傳輸數據類型描述。儘管都是協議，uwsgi 和 WSGI 並沒有聯繫，我們需要區分這兩個詞。
總結：
web服務器和web框架
web服務器即用來接受客戶端請求，建立連接，轉發響應的程序。至於轉發的內容是什麼，交由web框架來處理，即處理這些業務邏輯。如查詢數據庫、生成實時信息等。Nginx就是一個web服務器，Django或flask就是web框架。
-
WSGI是一種通信協議。WSGI 不是框架，也不是一個模塊，而是介於 Web應用程序（Web框架）與 Web Server 之間交互的一種規範。
-
uWSGI是一個Web服務器，它實現了WSGI協議、uwsgi、http等協議。Nginx中HttpUwsgiModule的作用是與uWSGI服務器進行交換。
-
uwsgi是一種通信協議，不過跟WSGI分屬兩種東西，該協議下速度比較快。
2、Nginx介紹
Nginx 是高效的 Web 服務器和反向代理服務器，可以用作負載均衡（當有 n 個用戶訪問服務器時，可以實現分流，分擔服務器的壓力），與 Apache 相比，Nginx 支持高併發，可以支持百萬級的 TCP 連接，十萬級別的併發連接，部署簡單，內存消耗少，成本低，但 Nginx 的模塊沒有 Apache 豐富。Nginx 支持 uWSGI 的 uwsgi 協議，因此我們可以將 Nginx 與 uWSGI 結合起來，Nginx 通過 uwsgi_pass 將動態內容交給 uWSGI 處理。
1. uWSGI 和 Nginx 的關係
從上面的講解中，我們知道，uWSGI 可以起到 Web 服務器的作用，那麼爲什麼有了 uWSGI 還需要 Nginx 呢？
最普遍的說法是 Nginx 對於處理靜態文件更有優勢，性能更好。其實如果是小網站，沒有靜態文件需要處理，只用 uWSGI 也是可以的，但加上 Nginx 這一層，優勢可以很具體：
1 對於運維來說比較方便，如果服務器被某個 IP 攻擊，在 Nginx 配置文件黑名單中添加這個 IP 即可，如果只用 uWSGI，那麼就需要在代碼中修改了。另一方面，Nginx 是身經百戰的 Web 服務器了，在表現上 uWSGI 顯得更專業，比如說 uWSGI 在早期版本里是不支持 https 的，可以說 Nginx 更安全。
2 Nginx 的特點是能夠做負載均衡和 HTTP 緩存，如果不止一臺服務器，Nginx 基本就是必選項了，通過 Nginx，將資源可以分配給不同的服務器節點，只有一臺服務器，也能很好地提高性能，因爲 Nginx 可以通過 headers 的Expires or E-Tag，gzip 壓縮等方式很好地處理靜態資源，畢竟是 C 語言寫的，調用的是 native 的函數，針對 I/O做了優化，對於動態資源來說，Nginx 還可以實現緩存的功能，配合 CDN 優化（這是 uWSGI 做不到的）。Nginx 支持epoll/kqueue 等高效網絡庫，能夠很好地處理高併發短連接請求，性能比 uWSGI 不知道高到哪裏去了。
3 如果服務器主機上運行了PHP，Python 等語言寫的多個應用，都需要監聽80端口，這時候 Nginx 就是必選項了。因爲我們需要一個轉發的服務。
所以說，Nginx 基本也是必選項。