Django & Tornado 区别与界限

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/CatStarXcode/article/details/79492141

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




展开阅读全文

没有更多推荐了,返回首页