今天我們來(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

這些概念是什么意思:

1. 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。

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

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

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

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

6. 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ù)器。

7. 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í)際情況搭配使用。

image.png

像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)服器，必須經(jīng)過(guò)這個(gè)代理，是被動(dòng)的。

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

  
  
  image.png

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

反向代理的作用：

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

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

3. 提升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)

image.png

5. django如何編寫(xiě)異步代碼呢？

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

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)的寫(xiě)法不易讀也容易出錯(cuò)，于是將回調(diào)的寫(xiě)法改成了同步的寫(xiě)法。這種模型和 koa2 和 go net/http 查不多， asyncio 提供了類似 go coroutine 的功能和寫(xiě)法，而 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ì)容易