浅析常用的PythonWeb的几大框架

在各种语言平台中，python涌现的web框架恐怕是最多的,是一个百花齐放的世界，各种micro-framework、framework不可胜数；猜想原因应该是在python中构造框架十分简单，使得轮子不断被发明。所

以在Python社区总有关于Python框架孰优孰劣的话题。下面就给大家介绍一下python的几大框架：

Django

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

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

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

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

全新的装修。

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

而Django的缺点主要源自Django坚持自己造所有的轮子，整个系统相对封闭，Django最为人诟病的地方有：

· 系统紧耦合，如果你觉得Django内置的某项功能不是很好，想用喜欢的第三方库来代替是很难的，比如下面将要说的ORM、Template。要在Django里用SQLAlchemy或Mako几乎是不可能，即使打了一

些补丁用上了也会让你觉得非常非常别扭。

· Django自带的ORM远不如SQLAlchemy强大，除了在Django这一亩三分地，SQLAlchemy是Python世界里事实上的ORM标准，其它框架都支持SQLAlchemy了，唯独Django仍然坚持自己的那一套。Django的

开发人员对SQLAlchemy的支持也是有 过讨论和尝试的，不过最终还是放弃了，估计是代价太高且跟Django其它的模块很难合到一块。

· Template功能比较弱，不能插入Python代码，要写复杂一点的逻辑需要另外用Python实现Tag或Filter。Django的模板系统设计十分有意思，也应该其框架内影响最大、争议最大的部分。

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

比方说，aspnet模板中可以写：

int i;

for(i==0;i

}

%>

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

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

一行代码能够解决的问题，用模板扩展实现后，会变成十几行代码。

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

Pylons & TurboGears & repozebfg

除了Django另一个大头就是Pylons了，因为TurboGears2x是基于Pylons来做的，而repozebfg也已经并入Pylons project里这个大的项目里，后面不再单独讨论TurboGears和repozebfg了。

Pylons和Django的设计理念完全不同，Pylons本身只有两千行左右的Python代码，不过它还附带有一些几乎就是Pylons御用 的第三方模块。Pylons只提供一个架子和可选方案，你可以根据自己的喜好自

由的选择Template、ORM、form、auth等组件，系统高度可 定制。我们常说Python是一个胶水语言(glue language)，那么我们完全可以说Pylons就是一个用胶水语言设计的胶水框架。

选择Pylons多是选择了它的自由，选择了自由的同时也预示着你选择了噩梦：

· 学习噩梦，Pylons依赖于许多第三方库，它们并不是Pylons造，你学Pylons的同时还得学这些库怎么使用，关键有些时候你都不知道你 要学什么。Pylons的学习曲线相对比Django要高的多，而之

前Pylons的官方文档也一直是人批评的对象，好在后来出了The Definitive Guide to Pylons这本书，这一局面有所改观。因为这个原因，Pylons一度被誉为只适合高手使用的Python框架。

· 调试噩梦，因为牵涉到的模块多，一旦有错误发生就比较难定位问题处在哪里。可能是你写的程序的错、也可能是Pylons出错了、再或是SQLAlchemy出错了、搞不好是formencode有bug，反正很凌

乱了。这个只有用的很熟了才能解决这个问题。

· 升级噩梦，安装Pylons大大小小共要安装近20个Python模块，各有各自的版本号，要升级Pylons的版本，哪个模块出了不兼容的问题都有可能，升级基本上很难很难。至今reddit的Pylons还停留在

古董的096上，SQLAlchemy也还是053的版本，应该跟这条有关系。

Pylons和repozebfg的融合可能会催生下一个能挑战Django地位的框架。

Tornado & webpy

Tornado( http://wwwtornadoweborg )是Facebook开源出来的框架，其哲学跟Django近乎两个极端。Tornado即是一个Web server(对此本文不作详述)，同时又是一个类webpy的micro-framework。

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

如果跟aspnet相比，Tornado有点类似仅实现了AsyncHttpHandler；除此之外，全部需要自己去实现。

好吧，其实它有模板，有国际化支持，甚至还有内置的OAuth/OpenID模块，方便做第三方登录，它其实也直接实现了Http服务器。

但它没有ORM（仅有一个mysql的超简单封装），甚至没有Session支持，更不要说Django那样自动化的后台。

假设是一个大型网站，在高性能的要求下，框架的各个部分往往都需要定制，可以复用的模块非常少；一个以Django开发的网站，各部分经过不断的定制，Django框架剩下的，很有可能也就是tornado一

开始所能提供的这部分。

殊途同归。

HTTP服务器

Tornado为了高效实现Comet/后端异步调用HTTP接口，是直接内嵌了HTTP服务器。

前端无需加apache / lighttpd / nginx等也可以供浏览器访问；但它并没有完整实现HTTP 11的协议，所以官方文档是推荐用户在生产环境下在前端使用nginx，后端反向代理到多个Tornado实例。

Tornado本身是单线程的异步网络程序，它默认启动时，会根据CPU数量运行多个实例；充分利用CPU多核的优势。

单线程异步

网站基本都会有数据库操作，而Tornado是单线程的，这意味着如果数据库查询返回过慢，整个服务器响应会被堵塞。

数据库查询，实质上也是远程的网络调用；理想情况下，是将这些操作也封装成为异步的；但Tornado对此并没有提供任何支持。

一个系统，要满足高流量；是必须解决数据库查询速度问题的！

数据库若存在查询性能问题，整个系统无论如何优化，数据库都会是瓶颈，拖慢整个系统！

异步并不能从本质上提到系统的性能；它仅仅是避免多余的网络响应等待，以及切换线程的CPU耗费。

如果数据库查询响应太慢，需要解决的是数据库的性能问题；而不是调用数据库的前端Web应用。

对于实时返回的数据查询，理想情况下需要确保所有数据都在内存中，数据库硬盘IO应该为0；这样的查询才能足够快；而如果数据库查询足够快，那么前端web应用也就无将数据查询封装为异步的必要

。

就算是使用协程，异步程序对于同步程序始终还是会提高复杂性；需要衡量的是处理这些额外复杂性是否值得。

如果后端有查询实在是太慢，无法绕过，Tornaod的建议是将这些查询在后端封装独立封装成为HTTP接口，然后使用Tornado内置的异步HTTP客户端进行调用。

近日只是为了想尽办法为 Flask 实现 Swagger UI 文档功能，基本上要让 Flask 配合 Flasgger, 所以写了篇 Flask 应用集成 Swagger UI 。然而不断的 Google 过程中偶然间发现了 FastAPI 这么一款集成了 Swagger UI 的更新的 Python Web 框架。起初想要在标题中表达的意思大概是 Flask + Swagger = FastAPI, 后来发现 FastAPI 的闪亮点不仅如此，顺便找了些 Flask 与 FastAPI 对比的文章来，在文后附有链接。

本文不对 Flask 与 FastAPI 的各个方面对进行对比，本人兴趣依然还在 FastAPI 的 Swagger UI 功能，以及与 Flask 的 Blueprint 类似的特性。如果要拿 Flask 与 FastAPI 比较的话，应该用 Flask 2x, 因为它开始支持类似 @appget 的装饰器，并引入了 async 路由函数。

Flask 是在 2010 年发布的，它构建于 WSGI(Python Web Server Gateway Interface) 之上的，产品环境中运行需与 uWSGI, Gunicorn 搭配，或用 mod_wsgi 模块与 Apache 集成。因发布较早，所以目前应该有较多的使用者。Flask 20 需要 Python 36+ 的支持，如果支持 async , 需 Python 37+

FastAPI 发布于 2018 年，构建于 ASGI(Asynchronous Server Gateway Interface) 之上，在 IO 密集型的应用中有更优越的性能。生成环境中配合 ASGI 服务器，如 Uvicorn 或 Hypercorn FastAPI 最为亮丽的特性是集成了 Swagger UI -- 外加一个福利 ReDoc 。FastAPI 需 Python 36+ 版本。

毕竟是在开始学一个新的框架，还是从它的基本用法开始，途中会穿插与 Flask 的对比。

安装:

当前安装的 fastapi 版本为 0701, uvicorn 版本为 0160。开始第一个例子，摘自官方

创建一个 mainpy 文件，内容为

注：以上两个函数前面可以加上 async 关键字

启动服务，用命令

注： uvicorn --help 列出详细帮助，如启动多少个 worker, 绑定网络接口和端口号, 配置 SSL 证书等。

访问服务

另一个服务就是 http://localhost:8000/items/100q=somequery

与 Flask 的对比

回顾一个 Flask 启动服务的方式有

如果程序文件名为 apppy 或 wsgipy 的话，可以省略 FLASK_APP 环境变量，直接执行 flask run 就行。另一种方式就是在代码中加上 main 入口

然后像普通 Python 代码一样执行

对于 FastAPI, 如果总是要用 uvicorn 来启动服务的话，在 IDE 中调用就变得不那么便利。由于 uvicorn 本身就是 Python 实现，当然也就可以把命令过程写到 Python 代码中

注：uvicornrun() 可接受更多的参数，相当于 uvicorn --help 可接受的。

同样把 mainpy 当作普通 Python 程序来启动即可

前面讲过，FastAPI 进入我的视野最首要的一个原因就是它集成了 Swagger UI, 在启动了 FastAPI 服务后，只要访问 http://localhost:8000/docs, 熟悉的 Swagger UI 即刻映入眼帘

同时注意到函数映射为 API 的名称，由于参数是带有类型提示的，所以在 SwaggerUI 中也能看到相应的类型。其他定制 Swagger UI 的工作需要时可细细研究。

FastAPI 除了 SwaggerUI 外，还同时给了我们另一个选择，那就是 redoc, 访问 http://localhost:8000/redoc, 看到下面的界面

我也是头一回从 FastAPI 这里了解到还有一个 Redoc 的 Web API 文档工具，它和 SwaggerUI 类似，都是支持 Open API。

使用 FastAPI 时，在 API 文档中产生请求/响应的 Model 类型也很简单，下面的例子同时包含自定义的输入输出类型

下面是 mainpy 的全新内容

再查看 http://localhost:8000/docs 文档，看到 PUT /items/{item_id} 的界面如下

我们能看到请求与响应中的 Example Value 和 Schema 定义

梳理完 FastAPI 的自动 API 文档功能，进入下一个话题

FastAPI 类似于 Flask 的 Blueprints 功能没有一个特定的名称，只笼统的给出解决方案 Bigger Applications - Multiple Files 我们来看一下它是怎么实现的。这里简化官方的例子，排除了 dependencies 的应用，要用到的目录结构为

每个目录中都可以放一个 __init__py 文件，标识为包，接着是每个文件的内容

app/internal/adminpy

app/routers/itemspy

app/routers/userspy

在每个单独定义路由的文件里用到的是 APIRouter , 它相当是一个迷你的 FastAPI , 也类似于 Flask 的 Blueprint 上面分别演示了两种 APIRouter 的声明方式，声明时带不带 prefix 和 tags。同时在为函数定义路由时也可指定 tags，在后面我们将会注意到 tags 只是为 API 文档分类用的。

app/mainpy

这里实际上使用了三种定义路径前缀与 tags(API 分类) 的方式

现在运行

查看 SwaggerUI http://localhost:8000/docs

到目前为止我重点关注 FastAPI 的就是以上那两个特性：自动 API 文档与大程序多文件(Blueprint) 功能。其他的特性可查阅 FastAPI 的 Features 。比如：

原文 https://yanbinblog/fastapi-new-python-web-framework-vs-flask/

Python中的架构就是框架，这些框架可以让web应用的开发更轻松。

这些框架把不同的模块集成在一起，让你更快的开发程序而不用注意一些细节。

Python中几种框架的介绍：

Django: Python Web应用开发框架

Django 应该是最出名的Python框架，GAE甚至Erlang都有框架受它影响。Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。

Flask：一个用Python编写的轻量级Web应用框架

Flask是一个使用Python编写的轻量级Web应用框架。基于Werkzeug WSGI工具箱和Jinja2 模板引擎。Flask也被称为“microframework”，因为它使用简单的核心，用extension增加其他功能。Flask没有默认使用的数据库、窗体验证工具。

Web2py：全栈式Web框架

Web2py是一个为Python语言提供的全功能Web应用框架，旨在敏捷快速的开发Web应用，具有快速、安全以及可移植的数据库驱动的应用，兼容Google App Engine。

Tornado：异步非阻塞IO的Python Web框架

Tornado的全称是Torado Web Server，从名字上看就可知道它可以用作Web服务器，但同时它也是一个Python Web的开发框架。最初是在FriendFeed公司的网站上使用，FaceBook收购了之后便开源了出来。

更多Python知识，请关注：Python自学网！！

Python的应用方向

1 常规软件开发

Python支持函数式编程和OOP面向对象编程，能够承担任何种类软件的开发工作，因此常规的软件开发、脚本编写、网络编程等都属于标配能力。

2 科学计算

随着NumPy, SciPy, Matplotlib, Enthought librarys等众多程序库的开发，Python越来越适合于做科学计算、绘制高质量的2D和3D图像。和科学计算领域最流行的商业软件Matlab相比，Python是一门通用的程序设计语言，比Matlab所采用的脚本语言的应用范围更广泛，有更多的程序库的支持。虽然Matlab中的许多高级功能和toolbox目前还是无法替代的，不过在日常的科研开发之中仍然有很多的工作是可以用Python代劳的。

3 自动化运维

这几乎是Python应用的自留地，作为运维工程师首选的编程语言，Python在自动化运维方面已经深入人心，比如Saltstack和Ansible都是大名鼎鼎的自动化平台。

4 云计算

开源云计算解决方案OpenStack就是基于Python开发的，搞云计算的同学都懂的。

5 WEB开发

基于Python的Web开发框架不要太多，比如耳熟能详的Django，还有Tornado，Flask。其中的Python+Django架构，应用范围非常广，开发速度非常快，学习门槛也很低，能够帮助你快速的搭建起可用的WEB服务。

6 网络爬虫

也称网络蜘蛛，是大数据行业获取数据的核心工具。没有网络爬虫自动地、不分昼夜地、高智能地在互联网上爬取免费的数据，那些大数据相关的公司恐怕要少四分之三。能够编写网络爬虫的编程语言有不少，但Python绝对是其中的主流之一，其Scripy爬虫框架应用非常广泛。

7 数据分析

在大量数据的基础上，结合科学计算、机器学习等技术，对数据进行清洗、去重、规格化和针对性的分析是大数据行业的基石。Python是数据分析的主流语言之一。

8 人工智能

Python在人工智能大范畴领域内的机器学习、神经网络、深度学习等方面都是主流的编程语言，得到广泛的支持和应用。

当然，除了以上的主流和前沿领域，Python还在其他传统或特殊行业起着重要的作用。

需要学习的python框架有：1、Django，它是一个高级的python web框架，以快速开发和使用简洁的设计闻名；2、CherryPy，它是历史最久的框架之一，运行非常稳定且快速；3、Web2Py，它是一个开源、免费的web框架。

常用的五大python框架：

（推荐教程：Python入门教程）

1、Django

Django是一个高级的Python Web框架，以快速开发和实用简洁的设计闻名。它由经验丰富的开发人员构建，解决了Web开发的麻烦，因此用户可以专注于编写应用程序，而不需要担心返工。并且它是开源和免费的。

特点：

安全系数高，能帮助开发者规避常见错误。

速度特别快，因为它的设计目的是使应用程序非常快地从概念阶段过渡到最终阶段。

扩展性好。

从21世纪初Django成为开源框架到现在，它一直是最佳的归档方式。

2、CherryPy

CherryPy是历史最久的框架之一，运行非常稳定且快速。该框架允许开发人员构建web应用程序，和以Python为对象的应用程序开发过程类似，因而可在更短的时间内开发更小的源代码。

从一开始，CherryPy就被证明是高效快速的，并被许多站点用于生产，无论是最简单的站点，还是有高要求的站点。

特点：

可以在27+、35+、Jython、Android和PyPy上运行。

内置覆盖、分析和测试支持。

容易快速运行多个HTTP服务器(例如，在多个端口上)。

是为部署人员和开发人员提供的最强大的配置系统之一。

灵活的插件系统。

3、Web2Py

Web2Py是一个开源、免费的web框架，用于敏捷开发，其中包括数据库驱动的web应用程序。它是用Python编写的，并可用于python编程。它是个全堆栈框架，由开发人员构建功能齐全的web应用程序所需的所有必要组件组成。

特点：

能够简化复杂大型应用的开发

支持MVC体系结构

符合Ni配置和安装要求

提供本地化和国际化支持

4、Bottle

Bottle是一个用于Python的简单、轻量级、快速的Web服务器网关接口（WSGI）微web框架。它是作为单个文件模块分发的，除了Python标准库之外没有其他依赖项。它被设计成轻量级，允许快速有效地开发web应用程序。

特点：

内置HTTP服务器。

允许用户访问表单数据、cookie、上传文件、header和其他http相关元数据。

一个可以同时运行Python 25x和35x的文件。

5、Flask

Flask是一个微框架，最适合简单的小项目。该框架基于Jinja 2和Werkzeug开发。这个框架的主要目的是开发一个强大的web应用程序库。

特点：

包含开发调试器和服务器

有丰富的文档

支持安全cookie

基于unicode

单元测试集成支持

1、Django框架

优点：是一个高层次Python Web开发框架，特点是开发快速、代码较少、可扩展性强。Django采用MTV(Model、Template、View)模型组织资源，框架功能丰富，模板扩展选择最多。对于专业人员来说，Django是当之无愧的Python排名第一的Web开发框架。

缺点：包括一些轻量级应用不需要的功能模块，不如Flask轻便。过度封装很多类和方法，直接使用比较简单，但改动起来比较困难。相比于 C,C++性能，Django性能偏低。模板实现了代码和样式完全分离，不允许模板里出现Python代码，灵活度不够。另外学习曲线也相对陡峭。

2、Flask框架

优点：Flask是一个Python Web开发的微框架，严格来说，它仅提供Web服务器支持，不提供全栈开发支持。然而，Flask非常轻量、非常简单，基于它搭建Web系统都以分钟来计时，特别适合小微原型系统的开发。花少时间、产生可用系统，是非常划算的选择。

缺点：对于大型网站开发，需要设计路由映射的规则，否则导致代码混乱。对新手来说，容易使用低质量的代码创建 “不良的web应用程序”。

3、Pyramid框架

优点：是一个扩展性很强且灵活的Python Web开发框架。上手十分容易，比较适合中等规模且边开发边设计的场景。Pyramid不提供绝对严格的框架定义，根据需求可以扩展开发，对高阶程序员十分友好。

缺点：国内知名度不高，高级用法需要通过阅读源代码获取灵感。默认使用Chameleon模板，灵活度没有成为一个要素。

4、webpy框架

优点：正如其名，webpy是一个采用Python作为开发语言的Web框架，简单且强大。俄罗斯排名第一的Yandex搜索引擎基于这个框架开发，Guido van Rossum认为这是最好的Python Web框架，还需要说别的吗有事实作证、有大牛认可，用起来吧!

缺点：Webpy并未像其他框架一样保持与Python 3兼容性的最新状态。这不仅意味着缺乏对异步语法的支持，还意味着缺少对已弃用的函数的错误。此外，目前尚不清楚维护者是否有计划在Python 2到达其支持生命周期结束后保持Webpy的最新状态。

5、Tornado框架

优点：Tornado是一个基于异步网络功能库的Web开发框架，因此，它能支持几万个开放连接，Web服务高效稳定。可见，Tornado适合高并发场景下的Web系统，开发过程需要采用Tornado提供的框架，灵活性较差，确定场景后再考虑使用不迟。

缺点：Tornado 50改进了与Python的本机异步功能的集成。因此不再支持Python 33并且Python 35用户必须使用Python 352或更高版本。Tornado 60将需要Python 35及更高版本，并将完全放弃Python 2支持。