django、flask和tornado區別

今天咱們來討論一下、django、flask和tornado的部署對比：node

1. 概述

在python的web開發框架中，目前使用量最高的幾個是django、flask和tornado，常常會有人拿這幾個對比，相信你們的初步印象應該是 django大而全、flask小而精、tornado性能高。python

tornado性能比django和flask高不少是由於tornado在底層io處理機制上和django以及flask有着根本的區別：nginx

1\. tornado、gevent、asyncio、aiohttp：底層使用的是事件循環+協程
2\. django和flask： 傳統的模型，阻塞io模型

雖然django和flask比tornado和asyncio性能低，可是他們做爲老牌的框架：生態豐富，代碼容易理解，簡單啊！可是我相信經過asyncio和tornado進行併發編程一定會成爲將來的另外一個主流方向。這裏我我的更看好基於asyncio的框架。nodejs和go語言都得益於協程輕鬆實現了高併發。程序員

可是今天咱們要介紹的並非協程，而是從這些框架的部署來進行對比：web

2. django和flask

在django和flask部署中，咱們常常會遇到如下幾個概念:django

web框架、 wsgi、  uwsgi、   uWSGI、    nginx

這些概念是什麼意思:編程

WSGI：全稱是Web Server Gateway Interface，WSGI不是服務器，python模塊，框架，API或者任何軟件，只是一種規範，描述web server如何與web application通訊的規範。要實現WSGI協議，必須同時實現web server和web application，當前運行在WSGI協議之上的web框架有Bottle, Flask, Django。
uwsgi：與WSGI同樣是一種通訊協議，是uWSGI服務器的獨佔協議，用於定義傳輸信息的類型(type of information)
uWSGI：是一個web服務器，實現了WSGI協議、uwsgi協議、http協議等。
WSGI協議主要包括server和application兩部分：
WSGI server負責從客戶端接收請求，將request轉發給application，將application返回的response返回給客戶端；
WSGI application接收由server轉發的request，處理請求，並將處理結果返回給server。application中能夠包括多個棧式的中間件(middlewares)，這些中間件須要同時實現server與application，所以能夠在WSGI服務器與WSGI應用之間起調節做用：對服務器來講，中間件扮演應用程序，對應用程序來講，中間件扮演服務器。
WSGI協議實際上是定義了一種server與application解耦的規範，便可以有多個實現WSGI server的服務器，也能夠有多個實現WSGI application的框架，那麼就能夠選擇任意的server和application組合實現本身的web應用。例如uWSGI和Gunicorn都是實現了WSGI server協議的服務器，Django，Flask是實現了WSGI application協議的web框架，能夠根據項目實際狀況搭配使用。

image.png

像Django，Flask框架都有本身實現的簡單的WSGI server，通常用於服務器調試，生產環境下建議用其餘WSGI server。好比django啓動 manage.py runserver 就是啓動的這個，這種只適用於本地開發的時候使用，線上運行仍是須要配置nginx+uwsgi+django才行。flask

wsgi 除了解析 http 協議以及 http 端口偵聽外，還負責了流量轉發以及 wsgi application 進程管理的功能。通常 wsgi 框架內置的 wsgi server 都是一個單進程，一次只能處理一個請求。而目的通用的 wsgi server(gunicorn, uwsgi)都至少支持 pre fork 模型，這種模型會起一個 master 來偵聽請求，並啓動多個 slave(每一個 slave 是一個 wsgi application)， master 負責把請求轉發到空閒的 slave 上。除了這種傳統的基於進程的 pre fork 同步模型，不一樣的 wsgi server 也會支持一些其它模型，有基於線程的同步模型，也有基於 asyncio 的異步模型。瀏覽器

3. nginx又有什麼用呢？

Ningx是一個反向代理服務器安全

什麼是反向代理？

正向代理，例如FQ用的代理服務器就是正向代理，瀏覽器主動請求代理服務器，代理服務器轉發請求到對應的目標服務器
反向代理，部署在Web服務器上，代理全部外部網絡對內部網絡的訪問。瀏覽器訪問服務器，必須通過這個代理，是被動的。
正向代理的主動方是客戶端，反向代理的主動方是Web服務器。

image.png

主要是由於 wsgi server 支持的併發量比較低，通常會用一個專門的 http server 來作一層緩衝，避免併發量過大時直接服務掛掉。

反向代理的做用：
1. 安全，客戶端對Web服務器的訪問須要先通過反向代理服務器。這樣能夠防止外部程序對Web服務器的直接攻擊。
2. 負載均衡，反向代理服務器能夠根據Web服務器的負載狀況，動態地把HTTP請求交給不一樣的Web服務器來處理，前提是要有多個Web服務器。
3. 提高Web服務器的IO性能。一個HTTP請求的數據，從客戶端傳輸給服務器，是須要時間的，例如N秒，若是直接傳給Web服務器，Web服務器就須要讓一個進程阻塞N秒，來接收IO，這樣會下降Web服務器的性能。若是使用反向代理服務器，先讓反向代理服務器接收完整個HTTP請求，再把請求發給Web服務器，就能提高Web服務器的性能。還有一些靜態文件的請求，能夠直接交給反向代理來處理，不須要通過Web服務器。
Nginx是一個高性能的HTTP和反向代理服務器。

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

image.png

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

1\. 直接用傳統的異步編程(進程，線程，協程)，雖然有些 wsgi server 支持 asynio 模型，可是這也須要用戶所寫的代碼作相應的支持。這就致使了若是咱們在 wsgi application 的時候不能隨便使用線程和異步 IO ，若是用了就須要配置 wsgi server 使其支持咱們本身的寫法。所以爲了使得咱們縮寫的 application 能部署在任意的 wsgi server(container)中，咱們就只能寫同步代碼了。
2\. 使用分佈式異步編程，使用相似 celery 的方式，將須要異步處理的東西發送到 worker 去處理。

python 傳統的這種 wsgi 模型，主要是爲了方便框架開發者只須要專一框架層面，而非 http 處理層面。但這樣卻增長了服務部署的複雜度，須要同時部署和配置 http server 和 wsgi server ，若是想支持異步還要部署 worker ，而使用 tornado 或 go 開發的應用由於本身實現了高效 http 處理的應用只須要部署本身就能夠了。

6. asyncio VS tornado

asyncio做爲python的原始協程庫，也是python最具野心和未來會重點打造的模塊，asyncio提供了更多的基礎功能，tornado是web服務器和web框架，二者原理是同樣的，都有很不錯的發展。

twisted 這種模型：

這種模型和上面的傳統模型處於一個時期，這種模型和 nodejs 差很少，都是基於回調的模型，適用於高 IO 低 CPU 的場景。這種模型本身實現了一個基於回調 http server(event loop)，每個請求都被註冊成一個異步函數來處理，而後主循環來不斷的循環這些函數。這樣就和 pre fork 模型有了區別， pre fork 模型中每個 slave 都是一個 wsgi application ，一個 wsgi application 都只能處理一個請求，而回調模型只有一個線程，不只極大的減小了內存的分配還減少了進城以及線程間的切換開銷，從而能夠支持高 IO 併發。可是這種模型也有很明顯的缺點，就是一旦應用程序有大量的 CPU 計算，就會讓這個線程堵住，全部的請求都會收到影響，若是應用在處理一個請求時崩潰，全部的請求也都會收到影響。

asyncio、tornado、gevent 這種模型：

由於回調的寫法不易讀也容易出錯，因而將回調的寫法改爲了同步的寫法。這種模型和 koa2 和 go net/http 查很少， asyncio 提供了相似 go coroutine 的功能和寫法，而 aiohttp 則提供了相似 go 中的 net/http 的 http 處理庫。

想要完全理解tornado這種模式以及想要本身去實現高併發的web服務器咱們須要理解協程，協程理解比線程和進程難很多，最複雜的調度機制，經過asyncio去理解會相對容易

點擊查看更多內容

做者：bobby
連接：https://www.imooc.com/article/details/id/24759
來源：慕課網
本文原創發佈於慕課網，轉載請註明出處，謝謝合做

本文同步分享在博客「程序員八阿哥」（JianShu）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。