nginx+gunicorn/uwsgi+python web 的前世此生

咱們在部署 flask、django 等 python web 框架時，網上最多的教程就是 nginx+gunicorn/uwsgi 的部署方式，那爲何要這麼部署呢，本文就來系統地解釋這個問題。

 

必備概念

WSGI

這裏必需要知道的一個概念，WSGI，web service gateway interface，網絡服務網關接口

它不是 web server，也不是 web application，它是架在 server 和 application 之間的一種協議和規範。

 

WSGI 的目的就是解耦 web server 和 web application，它包括兩個部分，server 和 application，server 用來接收 web 客戶端的請求，application 用來接收 server 傳來的請求，而後傳給 web server

 

gunicorn 

gunicorn 和 uWsgi 就是實現了 WSGI 協議的 web server；

而 flask、django 等 web 框架也是用的 wsgi 協議，因此須要在 web framework 以前加上 gunicorn 或者 uwsgi

 

話說回來，python web 框架都自帶 wsgi 服務器，爲何還要 這倆呢？一句話，性能太差，只能用於開發環節，具體不作過多解釋

 

nginx

nginx 是幹什麼的呢？參考個人博客 nginx

 

多層部署的原理

這三者結合起來的效果是什麼呢， 我作個簡單比喻

flask webServer + flask app：弱雞版的server，單進程（單 worker），該進程掛掉，web 服務掛掉；沒法管理

gunicorn + flask app：多進程（多 worker）server，失敗自動重啓該 worker，看起來不錯哦；簡單管理

nginx + gunicorn + flask app：反向代理，負載均衡，是否是更牛了；

多 nginx + 多 gunicorn + 多 web app：大型多實例 web server，通常還會給 gunicorn 掛上 supervisor；

 

四種模式詳解

第一種 server 是 web framework 自帶的框架，很容易掛掉，單 worker 工做對多核 cpu 服務器來講是一種浪費；

沒法對 worker 進行管理，掛了你不知道，你知道了也只能重啓；

而 gunicorn 是能夠對 worker 進行管理的

 

第二種 server 加上了 gunicorn，gunicorn 至關因而開啓了多個進程，它具備如下優勢：

1. 能夠調節 worker 的數量，在請求較多時，自動新增 worker，請求較少時，自動減小 worker；

2. 幫咱們管理 worker，worker 掛了自動重啓

3. 支持多種配置

4. 各類框架都適用，且部署方法相同

 

補充：gunicorn 的 管理機制

在管理 worker 上，gunicorn 使用了 pre-fork 模式，即一個 master 進程管理多個 worker 進程，全部請求和響應都由 worker 執行，master 就是一個 loop，監聽 worker 不一樣進程信號而且做出響應。

好比接受到 TTIN 提高 worker 數量，TTOU 下降運行 Worker 數量。若是 worker 掛了，發出 CHLD, 則重啓失敗的 worker, 同步的 Worker 一次處理一個請求。

 

看起來不錯，但存在如下問題：

1. gunicorn 若是要實現複雜功能，其配置比較複雜

2. gunicorn 有些功能是沒法實現的，好比 訪問控制、限速、限制鏈接數等

3. gunicorn 不支持 https，固然高版本支持，可是不如 nginx 

4. gunicorn 不支持 http1.1

5. gunicorn 沒法扛住巨大的併發量

 

第三種 server 加上 nginx，只爲更加高效更加健壯的 web 服務，nginx 的做用

1. 負載均衡：有效的調度 request，而 gunicorn 雖然是多進程，可是沒不能 主動地 對 request 進行調度

2. 動靜分離：通過配置後，nginx 能夠直接處理靜態請求，而無需通過 python web 服務器，這一點 gunicorn 沒有

3. 緩存 request 和 response：web 請求包含各類瀏覽器和各類網絡，故 http 請求的發起是一個比較慢的過程，而 gunicorn 須要等待整個請求結束，才處理該請求，而且等 web server 接收完這個請求後，才繼續下一個；

nginx 能夠緩存客戶端的請求，收完整個請求後，轉發給 gunicorn，等 gunicorn 返回 response 後，再轉發給客戶端；

這是 nginx 擅長，而 gunicorn 不擅長

 

第四種 server 能夠經過 nginx 實現 多後端、跨語言後端等 高可用 的負載均衡 web 服務器

 

總結

只作適合的事，沒有絕對的誰只能作什麼事；

nginx 功能強大，適合作管理，適合大規模的 web

gunicorn 多進程，充分利用服務器資源，能夠支持一些併發量不大的web

 

總圖

 

 

 

 

參考資料：

https://zhuanlan.zhihu.com/p/36268647　　WSGI及gunicorn指北（一）

https://www.zhihu.com/question/297267614/answer/505683007　　nginx和gunicorn和flask的關係？

https://www.zhihu.com/question/38528616