今天我們來討論一下、django减江、flask和tornado的部署對比：

1. 概述

在python的web開發(fā)框架中豺裆，目前使用量最高的幾個是django淆攻、flask和tornado皇钞， 經(jīng)常會有人拿這幾個對比，相信大家的初步印象應該是 django大而全描姚、flask小而精涩赢、tornado性能高。

tornado性能比django和flask高很多是因為tornado在底層io處理機制上和django以及flask有著根本的區(qū)別：

1\. tornado轩勘、gevent筒扒、asyncio、aiohttp：底層使用的是事件循環(huán)+協(xié)程
2\. django和flask： 傳統(tǒng)的模型绊寻，阻塞io模型

雖然django和flask比tornado和asyncio性能低花墩，但是他們作為老牌的框架：生態(tài)豐富，代碼容易理解澄步，簡單氨ⅰ！但是我相信通過asyncio和tornado進行并發(fā)編程必定會成為未來的另一個主流方向驮俗。這里我個人更看好基于asyncio的框架懂缕。nodejs和go語言都得益于協(xié)程輕松實現(xiàn)了高并發(fā)。

但是今天我們要介紹的并不是協(xié)程王凑，而是從這些框架的部署來進行對比：

2. django和flask

在django和flask部署中搪柑，我們經(jīng)常會遇到以下幾個概念:

web框架、 wsgi索烹、  uwsgi工碾、   uWSGI、    nginx

這些概念是什么意思:

1. WSGI：全稱是Web Server Gateway Interface百姓，WSGI不是服務器渊额，python模塊，框架垒拢，API或者任何軟件旬迹，只是一種規(guī)范，描述web server如何與web application通信的規(guī)范求类。要實現(xiàn)WSGI協(xié)議奔垦，必須同時實現(xiàn)web server和web application，當前運行在WSGI協(xié)議之上的web框架有Bottle, Flask, Django尸疆。
2. uwsgi：與WSGI一樣是一種通信協(xié)議椿猎，是uWSGI服務器的獨占協(xié)議，用于定義傳輸信息的類型(type of information)
3. uWSGI：是一個web服務器寿弱，實現(xiàn)了WSGI協(xié)議犯眠、uwsgi協(xié)議、http協(xié)議等症革。
4. WSGI協(xié)議主要包括server和application兩部分：
5. WSGI server負責從客戶端接收請求筐咧，將request轉發(fā)給application，將application返回的response返回給客戶端噪矛；
6. WSGI application接收由server轉發(fā)的request量蕊，處理請求，并將處理結果返回給server摩疑。application中可以包括多個棧式的中間件(middlewares)危融，這些中間件需要同時實現(xiàn)server與application，因此可以在WSGI服務器與WSGI應用之間起調節(jié)作用：對服務器來說雷袋，中間件扮演應用程序吉殃，對應用程序來說，中間件扮演服務器楷怒。
7. WSGI協(xié)議其實是定義了一種server與application解耦的規(guī)范蛋勺，即可以有多個實現(xiàn)WSGI server的服務器，也可以有多個實現(xiàn)WSGI application的框架鸠删，那么就可以選擇任意的server和application組合實現(xiàn)自己的web應用抱完。例如uWSGI和Gunicorn都是實現(xiàn)了WSGI server協(xié)議的服務器，Django刃泡，F(xiàn)lask是實現(xiàn)了WSGI application協(xié)議的web框架巧娱，可以根據(jù)項目實際情況搭配使用碉怔。

image.png

像Django，F(xiàn)lask框架都有自己實現(xiàn)的簡單的WSGI server禁添，一般用于服務器調試撮胧，生產環(huán)境下建議用其他WSGI server。比如django啟動 manage.py runserver 就是啟動的這個老翘，這種只適用于本地開發(fā)的時候使用芹啥，線上運行還是需要配置nginx+uwsgi+django才行。

wsgi 除了解析 http 協(xié)議以及 http 端口偵聽外铺峭，還負責了流量轉發(fā)以及 wsgi application 進程管理的功能墓怀。一般 wsgi 框架內置的 wsgi server 都是一個單進程，一次只能處理一個請求卫键。而目的通用的 wsgi server(gunicorn, uwsgi)都至少支持 pre fork 模型傀履，這種模型會起一個 master 來偵聽請求，并啟動多個 slave(每個 slave 是一個 wsgi application)永罚， master 負責把請求轉發(fā)到空閑的 slave 上啤呼。除了這種傳統(tǒng)的基于進程的 pre fork 同步模型，不同的 wsgi server 也會支持一些其它模型呢袱，有基于線程的同步模型官扣，也有基于 asyncio 的異步模型。

3. nginx又有什么用呢羞福？

• Ningx是一個反向代理服務器

  什么是反向代理惕蹄？

  正向代理，例如FQ用的代理服務器就是正向代理治专，瀏覽器主動請求代理服務器卖陵，代理服務器轉發(fā)請求到對應的目標服務器
  反向代理，部署在Web服務器上张峰，代理所有外部網(wǎng)絡對內部網(wǎng)絡的訪問泪蔫。瀏覽器訪問服務器，必須經(jīng)過這個代理喘批，是被動的撩荣。
  正向代理的主動方是客戶端，反向代理的主動方是Web服務器饶深。

image.png

• 主要是因為 wsgi server 支持的并發(fā)量比較低餐曹，一般會用一個專門的 http server 來做一層緩沖，避免并發(fā)量過大時直接服務掛掉敌厘。

  反向代理的作用：
  1. 安全台猴，客戶端對Web服務器的訪問需要先經(jīng)過反向代理服務器。這樣可以防止外部程序對Web服務器的直接攻擊。
  2. 負載均衡饱狂，反向代理服務器可以根據(jù)Web服務器的負載情況曹步，動態(tài)地把HTTP請求交給不同的Web服務器來處理，前提是要有多個Web服務器嗡官。
  3. 提升Web服務器的IO性能箭窜。一個HTTP請求的數(shù)據(jù)毯焕，從客戶端傳輸給服務器衍腥，是需要時間的，例如N秒纳猫，如果直接傳給Web服務器婆咸，Web服務器就需要讓一個進程阻塞N秒，來接收IO芜辕，這樣會降低Web服務器的性能尚骄。如果使用反向代理服務器，先讓反向代理服務器接收完整個HTTP請求侵续，再把請求發(fā)給Web服務器倔丈，就能提升Web服務器的性能。還有一些靜態(tài)文件的請求状蜗，可以直接交給反向代理來處理需五，不需要經(jīng)過Web服務器。
  Nginx是一個高性能的HTTP和反向代理服務器轧坎。

4. Nginx+uWSGI+應用程序的架構

image.png

5. django如何編寫異步代碼呢宏邮？

1\. 直接用傳統(tǒng)的異步編程(進程，線程缸血，協(xié)程)蜜氨，雖然有些 wsgi server 支持 asynio 模型，但是這也需要用戶所寫的代碼做相應的支持捎泻。這就導致了如果我們在 wsgi application 的時候不能隨便使用線程和異步 IO 飒炎，如果用了就需要配置 wsgi server 使其支持我們自己的寫法。因此為了使得我們縮寫的 application 能部署在任意的 wsgi server(container)中笆豁，我們就只能寫同步代碼了郎汪。
2\. 使用分布式異步編程，使用類似 celery 的方式渔呵，將需要異步處理的東西發(fā)送到 worker 去處理怒竿。

python 傳統(tǒng)的這種 wsgi 模型，主要是為了方便框架開發(fā)者只需要專注框架層面扩氢，而非 http 處理層面耕驰。但這樣卻增加了服務部署的復雜度，需要同時部署和配置 http server 和 wsgi server 录豺，如果想支持異步還要部署 worker 朦肘，而使用 tornado 或 go 開發(fā)的應用因為自己實現(xiàn)了高效 http 處理的應用只需要部署自己就可以了饭弓。

6. asyncio VS tornado

asyncio作為python的原始協(xié)程庫，也是python最具野心和將來會重點打造的模塊媒抠，asyncio提供了更多的基礎功能弟断，tornado是web服務器和web框架，兩者原理是一樣的趴生，都有很不錯的發(fā)展阀趴。

• twisted 這種模型：

這種模型和上面的傳統(tǒng)模型處于一個時期，這種模型和 nodejs 差不多苍匆，都是基于回調的模型刘急，適用于高 IO 低 CPU 的場景。這種模型自己實現(xiàn)了一個基于回調 http server(event loop)浸踩，每一個請求都被注冊成一個異步函數(shù)來處理叔汁，然后主循環(huán)來不斷的循環(huán)這些函數(shù)。這樣就和 pre fork 模型有了區(qū)別检碗， pre fork 模型中每一個 slave 都是一個 wsgi application 据块，一個 wsgi application 都只能處理一個請求，而回調模型只有一個線程折剃，不僅極大的減少了內存的分配還減小了進城以及線程間的切換開銷另假，從而可以支持高 IO 并發(fā)。但是這種模型也有很明顯的缺點微驶，就是一旦應用程序有大量的 CPU 計算浪谴，就會讓這個線程堵住，所有的請求都會收到影響因苹，如果應用在處理一個請求時崩潰苟耻，所有的請求也都會收到影響。

• asyncio扶檐、tornado凶杖、gevent 這種模型：

  因為回調的寫法不易讀也容易出錯，于是將回調的寫法改成了同步的寫法款筑。這種模型和 koa2 和 go net/http 查不多智蝠， asyncio 提供了類似 go coroutine 的功能和寫法，而 aiohttp 則提供了類似 go 中的 net/http 的 http 處理庫奈梳。

想要徹底理解tornado這種模式以及想要自己去實現(xiàn)高并發(fā)的web服務器我們需要理解協(xié)程杈湾，協(xié)程理解比線程和進程難不少，最復雜的調度機制攘须，通過asyncio去理解會相對容易

點擊查看更多內容

作者：bobby
鏈接：https://www.imooc.com/article/details/id/24759
來源：慕課網(wǎng)
本文原創(chuàng)發(fā)布于慕課網(wǎng) 漆撞，轉載請注明出處，謝謝合作