python-Web框架-简介

Python Web框架简介

Python 有哪些好的 Web 框架？

对初学者来说，循序渐进是最重要的，我推荐学习 Flask（Welcome | Flask (A Python Microframework)）Flask 很轻，花很少的成本就能够开发一个简单的网站。非常适合初学者学习。

Flask 框架学会以后，可以考虑学习插件的使用。例如使用 WTForm + Flask-WTForm 来验证表单数据，用 SQLAlchemy + Flask-SQLAlchemy 来对你的数据库进行控制。BTW：果壳网基于 Flask 开发的。

简单介绍下其他框架：

  1. Django。如楼上所说，是一个全能型框架。目前 Django 的使用面还是很广的，有学习的价值，但是不建议初学者学习，因为要学习的东西太多了，一下子难以吸收会失去兴趣。当然，Django 的目的是为了让开发者能够 快速 地开发一个网站，它提供了很多模块，其中我最喜欢的就是 admin 模块，http://your.site.com/admin 就进入了网站的后台（内置的哦~）方便地对数据进行操作，等等。。。。因此，如果对 Django 熟悉的话，papapa 一下子就写好一个网站的原型了。

  2. Tornado。传说中性能高高的框架。Tornado 是一个很好的框架，支持异步处理的功能，这是它的特点，其他框架不支持。另外一点是，Tornado 的设计似乎更注重 RESTful URL。但 Tornado 提供了网站基本需要使用的模块外，剩下的则需要开发者自己进行扩展。例如数据库操作，虽然内置了一个 database 的模块（后来独立出去了，现在叫做 torndb，bdarnell/torndb · GitHub）但是不支持 ORM，快速开发起来还是挺吃力的。如果需要 ORM 支持的话，还需要自己写一层将 SQLAlchemy 和 Tornado 联系起来，而且这里还有一个坑。
    BTW：知乎就是基础 Tornado 开发的。

  3. Bottle。Bottle 和 Flask 都属于轻量级的 Web 框架。但是 Bottle 似乎落寞了。我觉得跟他的 API 设计有关系。个人认为 Bottle 使用起来不那么顺手，因此也用得少。这里不做太多介绍。

  4. web.py。也是很轻的一个框架，使用不多，也不做介绍。

  5. web2py。我看楼上都没有对这个框架做介绍。这个框架是 Google 在 web.py 基础上二次开发而来的，兼容 GAE 。性能据说很高，曾经用他来做自己的主页，感觉也还不错。缺点同样是对扩展支持不太好，需要自己进行扩展。

  6. Quixote。著名的 豆瓣 就是基于 Quixote 开发的。跟上面几个框架不同，Quixote 的路由会有些特别。另外 Quixote 的性能据说也好。

Tornado Web Server

Tornado is an open source version of the scalable, non-blocking web server and tools that power FriendFeed. The FriendFeed application is written using a web framework that looks a bit like web.py or Google's webapp, but with additional tools and optimizations to take advantage of the underlying non-blocking infrastructure.

中文官网镜像 Tornado Web服务器

另一个好处是因为是facebook开源的，加上自身优秀的代码质量和傲娇的效率表现，目前非常火，诞生了一大批的优秀产品，如你在它上面提出这个问题的 知乎， quora， INK361， 42区.遇见等等。

两个Python web框架：Django & Tornado比较

在各种语言平台中，python涌现的web框架恐怕是最多的；猜想原因应该是在py中构造框架十分简单，使得轮子不断被发明。

这里记述一下我了解过的两个py web框架，供大家参考，希望能起他山之石的作用。

Django

Django 应该是最出名的py框架，Google App Engine甚至Erlang都有框架受它影响。

Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。

Django提供的方便，也意味着Django内置的ORM跟框架内的其他模块耦合程度高。

应用程序必须使用Django内置的ORM，否则就不能享受到框架内提供的种种基于其ORM的便利；理论上可以切换掉其ORM模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做全新的装修。

Django的卖点是超高的开发效率，其性能扩展有限；采用Django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。

这方面的经验可以参考：http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

Ruby的Rails也有类似的问题；以Twitter为例，推特到了今日的规模，不要说Rails，甚至是连Ruby都需要抛弃重来。

就我的感觉Django适用的是中小型的网站，或者是作为大型网站快速实现产品雏形的工具。

快速推出产品是王道：
Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second. - http://gettingreal.37signals.com/ch04_Scale_Later.php

===== Django 模板 =====

Django的模板系统设计十分有意思，也应该其框架内影响最大、争议最大的部分。

Django模板的设计哲学是彻底的将代码、样式分离；asp.net提倡将代码/模板分离，但技术上还是可以混合；而Django则是从根本上杜绝在模板中进行编码、处理数据的可能。

比方说，asp.net模板中可以写：

<%
 int i;
 for(i==0;i<10;i++){
 ....
 }
%>

Django是彻底不支持嵌入类似上面的代码，仅能使用其模板内置的函数；这实际上，是为其模板构造了一种“新语言”；由于此“新语言”十分简单，所以也能够将其模板移植到不同平台。

大多数情况下，Django的模板功能是足够的，但对于特殊（有时“特殊”也不是十分特殊）的情况，还是需要在模板中嵌入代码，那么就需要根据其模板系统的规则做模板扩展。有时候，模板中直接写一行代码能够解决的问题，用模板扩展实现后，会变成十几行代码。

是否容忍在模板中编程，正是Django模板争议最大之处。

Tornado

Tornado( http://www.tornadoweb.org )是Facebook开源出来的框架，其哲学跟Django近乎两个极端。

Tornado走的是少而精的方向，它也有提供模板功能；虽然不鼓励，但作者是可以允许在模板进行少量编码（直接嵌入单行py代码）的。

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

参考

posted @ 2016-12-13 14:19  银河统计  阅读(338)  评论(0)  编辑  收藏  举报