今天我們來(lái)討論一下、django谦炒、flask和tornado的部署對(duì)比：

1. 概述

在python的web開(kāi)發(fā)框架中贯莺，目前使用量最高的幾個(gè)是django、flask和tornado宁改， 經(jīng)常會(huì)有人拿這幾個(gè)對(duì)比缕探，相信大家的初步印象應(yīng)該是 django大而全、flask小而精还蹲、tornado性能高爹耗。

tornado性能比django和flask高很多是因?yàn)閠ornado在底層io處理機(jī)制上和django以及flask有著根本的區(qū)別：

1. tornado耙考、gevent、asyncio潭兽、aiohttp：底層使用的是事件循環(huán)+協(xié)程

2. django和flask： 傳統(tǒng)的模型倦始，阻塞io模型

雖然django和flask比tornado和asyncio性能低，但是他們作為老牌的框架：生態(tài)豐富山卦，代碼容易理解鞋邑，簡(jiǎn)單啊账蓉！但是我相信通過(guò)asyncio和tornado進(jìn)行并發(fā)編程必定會(huì)成為未來(lái)的另一個(gè)主流方向炫狱。這里我個(gè)人更看好基于asyncio的框架。nodejs和go語(yǔ)言都得益于協(xié)程輕松實(shí)現(xiàn)了高并發(fā)剔猿。

但是今天我們要介紹的并不是協(xié)程视译，而是從這些框架的部署來(lái)進(jìn)行對(duì)比：

2. django和flask

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

web框架归敬、 wsgi酷含、? uwsgi、? uWSGI汪茧、? ? nginx

這些概念是什么意思:

WSGI：全稱是Web Server Gateway Interface椅亚，WSGI不是服務(wù)器，python模塊舱污，框架呀舔，API或者任何軟件，只是一種規(guī)范扩灯，描述web server如何與web application通信的規(guī)范媚赖。要實(shí)現(xiàn)WSGI協(xié)議，必須同時(shí)實(shí)現(xiàn)web server和web application珠插，當(dāng)前運(yùn)行在WSGI協(xié)議之上的web框架有Bottle, Flask, Django惧磺。

uwsgi：與WSGI一樣是一種通信協(xié)議，是uWSGI服務(wù)器的獨(dú)占協(xié)議捻撑，用于定義傳輸信息的類型(type of information)

uWSGI：是一個(gè)web服務(wù)器磨隘，實(shí)現(xiàn)了WSGI協(xié)議、uwsgi協(xié)議顾患、http協(xié)議等番捂。

WSGI協(xié)議主要包括server和application兩部分：

WSGI server負(fù)責(zé)從客戶端接收請(qǐng)求，將request轉(zhuǎn)發(fā)給application江解，將application返回的response返回給客戶端设预；

WSGI application接收由server轉(zhuǎn)發(fā)的request，處理請(qǐng)求膘流，并將處理結(jié)果返回給server絮缅。application中可以包括多個(gè)棧式的中間件(middlewares)鲁沥，這些中間件需要同時(shí)實(shí)現(xiàn)server與application呼股，因此可以在WSGI服務(wù)器與WSGI應(yīng)用之間起調(diào)節(jié)作用：對(duì)服務(wù)器來(lái)說(shuō)耕魄，中間件扮演應(yīng)用程序，對(duì)應(yīng)用程序來(lái)說(shuō)彭谁，中間件扮演服務(wù)器吸奴。

WSGI協(xié)議其實(shí)是定義了一種server與application解耦的規(guī)范，即可以有多個(gè)實(shí)現(xiàn)WSGI server的服務(wù)器缠局，也可以有多個(gè)實(shí)現(xiàn)WSGI application的框架则奥，那么就可以選擇任意的server和application組合實(shí)現(xiàn)自己的web應(yīng)用。例如uWSGI和Gunicorn都是實(shí)現(xiàn)了WSGI server協(xié)議的服務(wù)器狭园，Django读处，F(xiàn)lask是實(shí)現(xiàn)了WSGI application協(xié)議的web框架，可以根據(jù)項(xiàng)目實(shí)際情況搭配使用唱矛。

像Django罚舱，F(xiàn)lask框架都有自己實(shí)現(xiàn)的簡(jiǎn)單的WSGI server，一般用于服務(wù)器調(diào)試绎谦，生產(chǎn)環(huán)境下建議用其他WSGI server管闷。比如django啟動(dòng) manage.py runserver 就是啟動(dòng)的這個(gè)，這種只適用于本地開(kāi)發(fā)的時(shí)候使用窃肠，線上運(yùn)行還是需要配置nginx+uwsgi+django才行包个。

wsgi 除了解析 http 協(xié)議以及 http 端口偵聽(tīng)外，還負(fù)責(zé)了流量轉(zhuǎn)發(fā)以及 wsgi application 進(jìn)程管理的功能冤留。一般 wsgi 框架內(nèi)置的 wsgi server 都是一個(gè)單進(jìn)程碧囊，一次只能處理一個(gè)請(qǐng)求。而目的通用的 wsgi server(gunicorn, uwsgi)都至少支持 pre fork 模型纤怒，這種模型會(huì)起一個(gè) master 來(lái)偵聽(tīng)請(qǐng)求呕臂，并啟動(dòng)多個(gè) slave(每個(gè) slave 是一個(gè) wsgi application)， master 負(fù)責(zé)把請(qǐng)求轉(zhuǎn)發(fā)到空閑的 slave 上肪跋。除了這種傳統(tǒng)的基于進(jìn)程的 pre fork 同步模型歧蒋，不同的 wsgi server 也會(huì)支持一些其它模型，有基于線程的同步模型州既，也有基于 asyncio 的異步模型谜洽。

3. nginx又有什么用呢？

Ningx是一個(gè)反向代理服務(wù)器

什么是反向代理吴叶？

正向代理阐虚，例如FQ用的代理服務(wù)器就是正向代理，瀏覽器主動(dòng)請(qǐng)求代理服務(wù)器蚌卤，代理服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求到對(duì)應(yīng)的目標(biāo)服務(wù)器

反向代理实束，部署在Web服務(wù)器上奥秆，代理所有外部網(wǎng)絡(luò)對(duì)內(nèi)部網(wǎng)絡(luò)的訪問(wèn)。瀏覽器訪問(wèn)服務(wù)器咸灿，必須經(jīng)過(guò)這個(gè)代理构订，是被動(dòng)的。

正向代理的主動(dòng)方是客戶端避矢，反向代理的主動(dòng)方是Web服務(wù)器悼瘾。

主要是因?yàn)?wsgi server 支持的并發(fā)量比較低，一般會(huì)用一個(gè)專門的 http server 來(lái)做一層緩沖审胸，避免并發(fā)量過(guò)大時(shí)直接服務(wù)掛掉亥宿。

反向代理的作用：

安全，客戶端對(duì)Web服務(wù)器的訪問(wèn)需要先經(jīng)過(guò)反向代理服務(wù)器砂沛。這樣可以防止外部程序?qū)eb服務(wù)器的直接攻擊烫扼。

負(fù)載均衡，反向代理服務(wù)器可以根據(jù)Web服務(wù)器的負(fù)載情況碍庵，動(dòng)態(tài)地把HTTP請(qǐng)求交給不同的Web服務(wù)器來(lái)處理映企，前提是要有多個(gè)Web服務(wù)器。

提升Web服務(wù)器的IO性能怎抛。一個(gè)HTTP請(qǐng)求的數(shù)據(jù)卑吭，從客戶端傳輸給服務(wù)器，是需要時(shí)間的马绝，例如N秒豆赏，如果直接傳給Web服務(wù)器，Web服務(wù)器就需要讓一個(gè)進(jìn)程阻塞N秒富稻，來(lái)接收IO掷邦，這樣會(huì)降低Web服務(wù)器的性能。如果使用反向代理服務(wù)器椭赋，先讓反向代理服務(wù)器接收完整個(gè)HTTP請(qǐng)求抚岗，再把請(qǐng)求發(fā)給Web服務(wù)器，就能提升Web服務(wù)器的性能哪怔。還有一些靜態(tài)文件的請(qǐng)求宣蔚，可以直接交給反向代理來(lái)處理，不需要經(jīng)過(guò)Web服務(wù)器认境。

Nginx是一個(gè)高性能的HTTP和反向代理服務(wù)器胚委。

4. Nginx+uWSGI+應(yīng)用程序的架構(gòu)

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

1. 直接用傳統(tǒng)的異步編程(進(jìn)程叉信，線程亩冬，協(xié)程)，雖然有些 wsgi server 支持 asynio 模型硼身，但是這也需要用戶所寫的代碼做相應(yīng)的支持硅急。這就導(dǎo)致了如果我們?cè)?wsgi application 的時(shí)候不能隨便使用線程和異步 IO 覆享，如果用了就需要配置 wsgi server 使其支持我們自己的寫法。因此為了使得我們縮寫的 application 能部署在任意的 wsgi server(container)中营袜，我們就只能寫同步代碼了撒顿。

2. 使用分布式異步編程，使用類似 celery 的方式连茧，將需要異步處理的東西發(fā)送到 worker 去處理核蘸。

python 傳統(tǒng)的這種 wsgi 模型巍糯，主要是為了方便框架開(kāi)發(fā)者只需要專注框架層面啸驯，而非 http 處理層面。但這樣卻增加了服務(wù)部署的復(fù)雜度祟峦，需要同時(shí)部署和配置 http server 和 wsgi server 罚斗，如果想支持異步還要部署 worker ，而使用 tornado 或 go 開(kāi)發(fā)的應(yīng)用因?yàn)樽约簩?shí)現(xiàn)了高效 http 處理的應(yīng)用只需要部署自己就可以了宅楞。

6. asyncio VS tornado

asyncio作為python的原始協(xié)程庫(kù)针姿，也是python最具野心和將來(lái)會(huì)重點(diǎn)打造的模塊，asyncio提供了更多的基礎(chǔ)功能厌衙，tornado是web服務(wù)器和web框架距淫，兩者原理是一樣的，都有很不錯(cuò)的發(fā)展婶希。

twisted 這種模型：

這種模型和上面的傳統(tǒng)模型處于一個(gè)時(shí)期榕暇，這種模型和 nodejs 差不多，都是基于回調(diào)的模型喻杈，適用于高 IO 低 CPU 的場(chǎng)景彤枢。這種模型自己實(shí)現(xiàn)了一個(gè)基于回調(diào) http server(event loop)，每一個(gè)請(qǐng)求都被注冊(cè)成一個(gè)異步函數(shù)來(lái)處理筒饰，然后主循環(huán)來(lái)不斷的循環(huán)這些函數(shù)缴啡。這樣就和 pre fork 模型有了區(qū)別， pre fork 模型中每一個(gè) slave 都是一個(gè) wsgi application 瓷们，一個(gè) wsgi application 都只能處理一個(gè)請(qǐng)求业栅，而回調(diào)模型只有一個(gè)線程，不僅極大的減少了內(nèi)存的分配還減小了進(jìn)城以及線程間的切換開(kāi)銷谬晕，從而可以支持高 IO 并發(fā)碘裕。但是這種模型也有很明顯的缺點(diǎn)，就是一旦應(yīng)用程序有大量的 CPU 計(jì)算固蚤，就會(huì)讓這個(gè)線程堵住娘汞，所有的請(qǐng)求都會(huì)收到影響，如果應(yīng)用在處理一個(gè)請(qǐng)求時(shí)崩潰夕玩，所有的請(qǐng)求也都會(huì)收到影響你弦。

asyncio惊豺、tornado、gevent 這種模型：

因?yàn)榛卣{(diào)的寫法不易讀也容易出錯(cuò)禽作，于是將回調(diào)的寫法改成了同步的寫法尸昧。這種模型和 koa2 和 go net/http 查不多， asyncio 提供了類似 go coroutine 的功能和寫法旷偿，而 aiohttp 則提供了類似 go 中的 net/http 的 http 處理庫(kù)烹俗。

想要徹底理解tornado這種模式以及想要自己去實(shí)現(xiàn)高并發(fā)的web服務(wù)器我們需要理解協(xié)程，協(xié)程理解比線程和進(jìn)程難不少萍程，最復(fù)雜的調(diào)度機(jī)制幢妄，通過(guò)asyncio去理解會(huì)相對(duì)容易

點(diǎn)擊查看更多內(nèi)容

鏈接：http://www.imooc.com/article/24759

本原創(chuàng)發(fā)布于慕課網(wǎng) ，轉(zhuǎn)載請(qǐng)注明出處茫负，謝謝合作