Django & Tornado 区别与界限

Django 与 Tornado 各自的优缺点

Django

优点：

• 大和全（重量级框架）
  
• 自带orm，template，view 
  
• 需要的功能也可以去找第三方的app
  
• 注重高效开发
• 全自动化的管理后台（只需要使用起ORM，做简单的定义，就能自动生成数据库结构，全功能的管理后台）
• session功能

缺点：

• template不怎么好用（来自自身的缺点）
  
• 数据库用nosql不方便（来自自身的缺点）
• 如果功能不多，容易臃肿

Tornado

优点：

• 少而精（轻量级框架）
• 注重性能优越，速度快
• 解决高并发（请求处理是基于回调的非阻塞调用）
• 异步非阻塞
• websockets 长连接
• 内嵌了HTTP服务器
• 单线程的异步网络程序，默认启动时根据CPU数量运行多个实例；利用CPU多核的优势
• 自定义模块

缺点：

• 模板和数据库部分有很多第三方的模块可供选择，这样不利于封装为一个功能模块
  

总结：

要性能， Tornado 首选；要开发速度，Django 和 Flask 都行，区别是 Flask 把许多功能交给第三方库去完成了，因此 Flask 更为灵活。

综上所述：

Django适合初学者或者小团队的快速开发，适合做管理类、博客类网站、或者功能十分复杂需求十分多的网站

Tornado适合高度定制，适合访问量大，异步情况多的网站

Django 概述

Django 应该是最出名的python框架，Google App Engine甚至Erlang都有框架受它影响。
Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。
Django提供的方便，也意味着Django内置的ORM跟框架内的其他模块耦合程度高。
应用程序必须使用Django内置的ORM，否则就不能享受到框架内提供的种种基于其ORM的便利；理论上可以切换掉其ORM模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做全新的装修。
Django的卖点是超高的开发效率，其性能扩展有限；采用Django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。
Ruby的Rails也有类似的问题；以Twitter为例，推特到了今日的规模，不要说Rails，甚至是连Ruby都需要抛弃重来。
就我的感觉Django适用的是中小型的网站，或者是作为大型网站快速实现产品雏形的工具。

Tornado 概述

Tornado是Facebook开源出来的框架，其哲学跟Django近乎两个极端。Tornado是异步框架Tornado基本上只算有MVC中C这一层
Tornado走的是少而精的方向，它也有提供模板功能；虽然不鼓励，但作者是可以允许在模板进行少量编码的。
如果跟asp.net相比，Tornado有点类似仅实现了AsyncHttpHandler；除此之外，全部需要自己去实现。
好吧，其实它有模板，有国际化支持，甚至还有内置的OAuth/OpenID模块，方便做第三方登录，它其实也直接实现了Http服务器。
但它没有ORM（仅有一个mysql的超简单封装），甚至没有Session支持，更不要说Django那样自动化的后台。
假设是一个大型网站，在高性能的要求下，框架的各个部分往往都需要定制，可以复用的模块非常少；一个以Django开发的网站，各部分经过不断的定制，Django框架剩下的，很有可能也就是tornado一开始所能提供的这部分。
殊途同归。

===== HTTP服务器 =====

Tornado为了高效实现Comet/后端异步调用HTTP接口，是直接内嵌了HTTP服务器。
前端无需加apache / lighttpd / nginx等也可以供浏览器访问；但它并没有完整实现HTTP 1.1的协议，所以官方文档是推荐用户在生产环境下在前端使用nginx，后端反向代理到多个Tornado实例。
Tornado本身是单线程的异步网络程序，它默认启动时，会根据CPU数量运行多个实例；充分利用CPU多核的优势。

===== 单线程异步 =====

网站基本都会有数据库操作，而Tornado是单线程的，这意味着如果数据库查询返回过慢，整个服务器响应会被堵塞。
数据库查询，实质上也是远程的网络调用；理想情况下，是将这些操作也封装成为异步的；但Tornado对此并“没有”提供任何支持。
这是Tornado的“设计”，而不是缺陷。
一个系统，要满足高流量；是必须解决数据库查询速度问题的！
数据库若存在查询性能问题，整个系统无论如何优化，数据库都会是瓶颈，拖慢整个系统！
异步并**不能**从本质上提到系统的性能；它仅仅是避免多余的网络响应等待，以及切换线程的CPU耗费。
如果数据库查询响应太慢，需要解决的是数据库的性能问题；而不是调用数据库的前端Web应用。
对于实时返回的数据查询，理想情况下需要确保所有数据都在内存中，数据库硬盘IO应该为0；这样的查询才能足够快；而如果数据库查询足够快，那么前端web应用也就无将数据查询封装为异步的必要。
就算是使用协程，异步程序对于同步程序始终还是会提高复杂性；需要衡量的是处理这些额外复杂性是否值得。
如果后端有查询实在是太慢，无法绕过，Tornaod的建议是将这些查询在后端封装独立封装成为HTTP接口，然后使用Tornado内置的异步HTTP客户端进行调用。