Django框架和Tornado框架的区别

在众多语言开发中，python涌现的web框架恐怕是最多的

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走的是少而精的方向，它也有提供模板功能；虽然不鼓励，但作者是可以允许在模板进行少量编码的。

如果跟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客户端进行调用。

 

Tornado 是 FriendFeed 使用的可扩展的非阻塞式 web 服务器及其相关工具的开 源版本。这个 Web 框架看起来有些像 web.py 或者 Google 的 webapp，不过为了 能有效利用非阻塞式服务器环境，这个 Web 框架还包含了一些相关的有用工具和 优化。  Tornado 和现在的主流 Web 服务器框架（包括大多数 Python 的框架）有着明显 的区别：它是非阻塞式服务器，而且速度相当快。得利于其 非阻塞的方式和对 epoll 的运用，Tornado 每秒可以处理数以千计的连接，这意味着对于实时 Web 服务来说，Tornado 是一个理想的 Web 框架。我们开发这个 Web 服务器的主要 目的就是为了处理 FriendFeed 的实时功能 ——在 FriendFeed 的应用里每一个活 动用户都会保持着一个服务器连接。（关于如何扩容 服务器，以处理数以千计的 客户端的连接的问题，请参阅 C10K problem。）  案例： FriendFeed, 知乎