Python 有哪些好的 Web 框架

1、Django

Python中最全能的Web开发框架，各种功能完备，可维护性和开发速度都一级棒，不少人反应Django框架慢，它主要慢在DjangoORM与数据库的交互上，所以是否使用Django框架，需要取决于项目对数据库交互的要求以及各种优化，而对于Django的同步特性导致吞吐量小的问题，可以通过Celery等解决，这并不是一个致命问题。

2、Tornado

异步，性能强悍，然而它相比Django框架来说，相对原始，很多东西需要自己去处理，随着项目的逐渐扩大，框架所能提供的功能也会越来越小，更多的东西需要团队自己去实现，而大项目往往需要性能的保证，这时它就是最佳的选择。

3、Flask

微框架，可以说是Python代码写得最好的项目之一，它的灵活性也是把双刃剑，能使用好Flask框架，即可以做成Pinterest，用不好就是灾难，它是一个微框架，但也可以做成规模化的Flask，加上它可以自由选择自己的数据库交互组件，而且加上celery+redis等异步特性之后，Flask的性能相对Tornado也不相上下，也许Flask的灵活性可能是某些团队更需要的。

4、Twisted

前面提到的3个Web框架都是围绕应用层HTTP展开的，而Twisted则不同，它是一个用Python语言编写的事件驱动的网络框架，对于追求服务器性能的应用，它是个非常不错的选择。

它支持很多协议，包括传输层的UDP、TCP、TLS，以及应用层的HTTP、FTP等，对于这些协议，Twisted提供了客户端和服务器方面的开发工具。

它是一个高性能的编程框架，在不同的操作系统上，Twisted利用不同的底层技术实现了高性能通信，在开发方法上，Twisted引导程序员使用异步编程模型，它提供了丰富的Defer、Threading等特性来支持异步编程。

利用Python自带的包可以建立简单的web服务器。在DOS里cd到准备做服务器根目录的路径下，输入命令：\x0d\python -m Web服务器模块 [端口号，默认8000]\x0d\例如：\x0d\python -m SimpleHTTPServer 8080\x0d\然后就可以在浏览器中输入\x0d\h ttp://loca lhost:端口号/路径\x0d\来访问服务器资源。 \x0d\例如：\x0d\h ttp://local host:808 0/indexh tm（当然indexhtm文件得自己创建）\x0d\其他机器也可以通过服务器的IP地址来访问。\x0d\\x0d\这里的“Web服务器模块”有如下三种：\x0d\\x0d\BaseHTTPServer: 提供基本的Web服务和处理器类，分别是HTTPServer和BaseHTTPRequestHandler。\x0d\SimpleHTTPServer: 包含执行GET和HEAD请求的SimpleHTTPRequestHandler类。\x0d\CGIHTTPServer: 包含处理POST请求和执行CGIHTTPRequestHandler类。

Python Web 程序的部署方案

综合而言, 高性能的Python web站点部署方式首推 nginx + uwsgi

apache + mod_wsgi 是简单稳定但性能一般的方式

API服务器 可以直接使用tornado或者gevent

mod_python

非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说，使用 Apache 部署是一个不错的选择。较早的时候，使用 mode_python 部署python的web应用十分流行,在Django 096 的时候官方文档甚至推荐这种方式。

它将Python解释器嵌入到Apache server,以提供一个访问Apache server内部的接口。mod_python 在现在看来性能是不佳的，每一个http请求 mod_python 都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。

mod_wsgi

如果非要用Apache来部署python应用，mod_wsgi是一个更好的选择。WSGI 全称是 Web Server Gateway Interface ,由 PEP-333 定义。 基本上所有的python web框架都实现了wsgi接口，用mod_wsgi 能部署任何实现了wsgi的框架。实际上，不需要任何框架也可以用mod_wsgi 部署python程序。使用mod_wsgi的daemon模式，python程序会常驻内存，不会有很大的初始化和销毁进程方面的开销，所以性能是好于mod_python的。综合来说，使用Apache部署python web程序，推荐使用mod_wsgi的daemon模式。

Fastcgi

先说观点：不建议用fastcgi的方式部署Python web。

前几年由于lighttpd风头正劲和豆瓣的成功案例，fastcgi是一种很流行的部署方式。fastcgi与具体语言无关，也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强，CGI程序运行在独立的进程中，并对每个Web请求建立一个进程。面对大量请求，进程的大量建立和消亡使操作系统性能大大下降。

与为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理，而不是web服务器。 当进来一个请求时，web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地）或者一个TCP connection（FastCGI进程在远端的server farm）传递给FastCGI进程。

主流的web服务器，Apache,lighttpd,nginx 都支持fastcgi，在几年前，lighttpd的mod_fcgi模块性能强劲，lighttpd+fastcgi十分流行。无论是python,ruby还是php，都有大量的站点使用这种方式部署。由于nginx的崛起，现在很少有人使用lighttpd了。

fastcgi 并不是专门为python设计，并不是所有的python框架天然的支持fastcgi，通常需要flup这样的容器来配适。flup由python编写，和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看，部署python web程序，fastcgi 都已经是过去式。

uwsgi

前几年nginx还未内置uwsgi模块的时候，部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块，uwsgi已经是最可靠，最方便的高性能python web程序的部署方式了。

在1U的四核XEON服务器上，一个简单的wsgi handler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。 同时，uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定，在一个渣HP 1U 服务器上，基本不用管它。

上面提到的部署方式都是相对于web网站的方式，在移动互联网的时代，我们需要的是高性能的API服务，上面这些都是过时的东西。

tornado

tornado 号称高性能，如果拿他写网站，其实一般般，只不过跟uwsgi加一些简单框架差不多而已。它真正的作用，是用来写API服务器和长连接的服务器。

由于tornado能够直接处理http请求，很多人直接拿他来裸奔直接提供服务。这种方式是不可取的，单线程的tornado只能利用cpu的一个核心，并且一旦阻塞直接就废了。通常情况下，由supervisor启动多个tornado进程，通过nginx进行反向代理负载均衡。nginx 114 以后的版本反向代理支持长连接，配合tornado的comet效果很好。

tornado还有一些比较奇葩的用法，比如用来做wsgi容器之类的。

gevent

gevent是一个神器，能做的事情很多。在web方面，处理http请求，用起来其实跟tornado差不多，但是要简陋很多，cookie之类的都没有。用gevent写的一些API服务，部署方式还是类似tornado，用supervisor管理多个守护进程，通过nginx做负载均衡。 同样的它的奇葩用法也和tornado一样，可以当wsgi容器用。

首先你需要知道一个Web应用基本的请求处理流程。以最简单最原始的动态网页为例，你点击链接（GET），提交表单（POST），就是与服务器端建立了连接之后发送了一个HTTP请求（RFC2616 51节，之后都以HTTP 11为例），里面至少有方法（动词，就是GET啦POST什么的，详见RFC2616第9节），地址（URL），HTTP版本，还可能带上Cookie（会话的一般实现机制），缓存相关的信息（RFC2616 13节），User-Agent串等等一堆信息。对于POST请求我们还有表单内容作为请求实体（RFC2616 72节），里面是你填写的表单内容。

于是我们有了一些关于请求的数据，不过现在一般来讲这些数据还在前端服务器（反向代理，比如nginx，暂且忽略掉负载均衡，反正是透明的，也不考虑裸WSGI容器直接扛请求的情况）的手上，还没有传进后端语言（这里是Python）。我们就针对每一种语言都有特定的机制，用来将HTTP的请求信息映射到相应的编程语言范畴，叫做Web服务器界面（Web server interface），通用如CGI/FCGI/SCGI，特定于某一语言如WSGI/PSGI/Rack/，特定于某一操作系统如ISAPI（这货还活着？），一些已经不再使用的就不提了。总之在Python世界里这就是WSGI（PEP 3333, Web Server Gateway Interface），它就定义了Python语言与Web服务器之间的界面。在WSGI里，

请求的处理过程被映射为对应用callable的调用（application(environ, start_response)，知乎不支持inline代码块？）；

请求信息被映射到environ字典中的相应键值，比如请求方法被映射到environ['REQUEST_METHOD']，请求的“相对路径”被映射到environ['PATH_INFO']（过度简化；暂且不提WSGI应用挂载点，框架层一般也不用关心这个，挂载WSGI应用一般是WSGI容器如gunicorn、uWSGI之类组件的工作）；

发送响应头的动作被映射到调用start_response(status, response_headers)（不考虑可选的第三个参数异常信息）；

返回响应数据被映射到application返回iterable的动作。

于是响应便从Python返回到Web服务器，再被发送回浏览器，浏览器将响应内容渲染，一个请求就完成啦。

有了这样的感性认识，那么我们作为Python Web开发框架的作者，要做的事情就是在WSGI规范的基础之上，提供尽可能便捷的开发手段和尽可能低的框架开销，也即我们的代码将要工作在WSGI与业务逻辑的中间层。架构上，Web开发框架或多或少都遵循MVC的设计模式（Django管它叫MTV，其实差不多）。同时，由于框架位于中间件的位置，加上其鼓励模块化与代码复用的性质，自然需要为常见的HTTP操作提供抽象。这里就可以展开一些话题：

请求路径到view/controller的映射，请求参数的解析（routing，也叫路由）。

正则匹配的方案，比如Django内置了一个简单的正则表达式解析组件，能解析一般常见语法的正则表达式，把capturing groups解析成位置参数，named capturing groups解析成关键字参数。

也有DSL的方案，比如Werkzeug的路由组件。

请求实体的处理。表单解析，配合Web服务器进行上传文件处理。

正常的urlencoded表单，JSON表单，text/plain数据，multi-part表单

multi-part附件，附件操作API

大文件上传（这个一般会被前端服务器保存在磁盘上的临时文件里，比方说nginx就是这么实现的）。

会话。HTTP是无状态（stateless）的，这个特点非常重要。如果没有会话，你连续做几个请求，却没有手段证明你们是同一个人/同一台机器（你完全可能是代理服务器）。

存储会话数据的会话后端（内存数据结构？文件？RDBMS？Redis？Memcache？）

安全机制（HMAC什么的，可以参考beaker的secure cookie实现）

请求处理流程中的会话中间件（从Cookie中提取会话，从query string中提取会话，从自定义头中提取会话，等等）

View/Controller界面。发挥你的创造力，用上你的工程经验。

Function-based or Class-based views 参考：Django, Bottle, webpy, Tornado等一票框架的做法

框架的可选机制与服务如何暴露，

装饰器？（比如@login_required 这种额外要求）

回调？（能想到的只有Tornado和Twisted这种异步框架做事情的方式，还有整个JS生态系统都是回调（不考虑Promise什么的）的思路）

传入应用（业务逻辑）层的数据结构如何设计？（HttpRequest等价物，名字可能记不清了）

响应数据结构如何设计？（HttpResponse等价物，同上）

数据库操作封装。Web应用基本都是数据为中心，这个组件非常有必要，也是撰写可复用代码必须的一环，毕竟光是框架抽象了，数据库操作还是裸SQL什么的，到时候生产环境一换（比如MySQL变pgsql）还不是傻眼。

关系型数据库。一站式解决方案参考：Django ORM、SQLAlchemy；轻量级解决方案参考各数据库Python绑定。

非关系数据库。各数据库Python绑定（pymongo, riak, redis-py之类），这个没什么可替代方案了，因为本来各种NoSQL库都是适应某一特殊需求设计的，没什么互相替换的必要，那意味着重新进行技术选型。

未完待续

接下来的内容：

主要响应AJAX/API请求的框架设计思路

Python下实时Web框架思路

框架设计哲学

框架性能分析方法

本人才疏学浅，大项目没做过，小项目也没怎么起飞过，请各位阅读我的观点时务必留心。读到最后非常感谢。

由于字数的限制，其实本篇文章的全标题为 《如何在 virtualenv 环境下 Django + Nginx + Gunicorn+ Supervisor 搭建 Python Web》

在这篇文章里，我们将搭建一个简单的 Web 应用，在虚拟环境中基于 Flask 框架，用 Gunicorn 做 wsgi 容器，用 Supervisor 管理进程，然后使用 OneAPM Python 探针来监测应用性能，形成一个「闭环」 ！希望能对大家有所帮助，首先简单来介绍一下环境：

系统环境：ubuntu 1404 Python 276

安装组件库

第一步安装所需要的存储库，因为打算用到虚拟环境，用到 pip 安装和管理 Python 组件，所以先更新本地包，然后安装组件：

sudo apt-get updatesudo apt-get install python-pip python-dev nginx

创建虚拟环境 virtualenv

在一个系统中创建不同的 Python 隔离环境，相互之间还不会影响，为了使系统保持干净，遂决定用 virtualenv 跑应用程序，创建一个容易识别的目录，开始安装，再创建项目目录 super，然后激活环境：

sudo pip install virtualenv

mkdir ~/supervisor && cd ~/supervisor

virtualenv supersource super/bin/activate

安装 Flask 框架

好了，现在在虚拟环境里面，开始安装 Flask 框架，flask 依赖两个库 werkzeug 和 jinjia2, 采用 pip 方式安装即可, pip 是一个重要的工具，Python 用它来管理包：

pip install flask

先用 Flask 写一个简单的 Web 服务 mywebpy ，因为后面要做一些测试，所以设置了几个请求：

from flask import Flask

app = Flask(__name__)

@approute('/')def index(): return 'hello world supervisor gunicorn '@approute('/1')def index1(): return 'hello world supervisor gunicorn ffffff'@approute('/qw/1')def indexqw(): return 'hello world supervisor gunicorn fdfdfbdfbfb 'if __name__ == '__main__':

appdebug = True

apprun()

启动 Flask 看看！

python mywebpy

在浏览器中访问 http://127001:5000 就可以看到了「几个路径都试一试」

用 Gunicorn 部署 Python Web

现在我们使用 Flask 自带的服务器，完成了 Web 服务的启动。生产环境下，Flask 自带的服务器，无法满足性能要求。所以我们这里采用 Gunicorn 做 wsgi 容器，用来部署 Python，首先还是安装 Gunicorn：

pip install gunicorn

当我们安装好 Gunicorn 之后，需要用 Gunicorn 启动 Flask，Flask 用自带的服务器启动时，Flask 里面的

name 里面的代码启动了 apprun()。而这里我们使用 Gunicorn，mywebpy 就等同于一个库文件，被 Gunicorn

调用，这样启动：

gunicorn -w 4 -b 0000:8000 myweb:app

其中 myweb 就是指 mywebpy，app 就是那个 wsgifunc 的名字，这样运行监听 8000 端口，原先的 5000 端口并没有启用，-w 表示开启多少个 worker，-b 表示 Gunicorn 开发的访问地址。

想要结束 Gunicorn 只需执行 pkill Gunicorn，但有时候还要 ps 找到 pid 进程号才能

kill。可是这对于一个开发来说，太过于繁琐，因此出现了另外一个神器

---supervisor，一个专门用来管理进程的工具，还可以管理系统的工具进程。

安装 Supervisor

pip install supervisor

echo_supervisord_conf > supervisorconf # 生成 supervisor 默认配置文件gedit supervisorconf # 修改 supervisor 配置文件，添加 gunicorn 进程管理在 supervisorconf 底部下添加 mywebpy 的配置 `/home/wang/supervisor/super` 是我的项目目录」

[program:myweb]

command=/home/wang/supervisor/super/bin/gunicorn -w 4 -b 0000:8000 myweb:app

directory=/home/wang/supervisor

startsecs=0 stopwaitsecs=0 autostart=false

autorestart=false

user=wang

stdout_logfile=/home/wang/supervisor/log/gunicornlog

stderr_logfile=/home/wang/supervisor/log/gunicornerr

supervisor 的基本使用命令：

supervisord -c supervisorconf supervisorctl -c supervisorconf status 查看supervisor的状态

supervisorctl -c supervisorconf reload 重新载入 配置文件

supervisorctl -c supervisorconf start [all]|[appname] 启动指定/所有 supervisor 管理的程序进程

supervisorctl -c supervisorconf stop [all]|[appname] 关闭指定/所有 supervisor 管理的程序进程

supervisor 还有一个 web 的管理界面，可以激活。更改下配置：

[inet_http_server] ; inet (TCP) server disabled by defaultport=127001:9001 ; (ip_address:port specifier, :port for alliface)

username=wang ; (default is no username (open server)

password=123 ; (default is no password (open server))

[supervisorctl]

serverurl=unix:///tmp/supervisorsock ; use a unix:// URL for a unix socketserverurl=http://127001:9001 ; use an http:// url to specify an inet socketusername=wang ; should be same as http_username if setpassword=123 ; should be same as http_password if set;prompt=mysupervisor ; cmd line prompt (default "supervisor");history_file=~/sc_history ; use readline history if available

现在可以使用 supervsior 启动 gunicorn 啦。运行命令:

supervisord -c supervisorconf

浏览器访问 http://127001:9001 可以得到 supervisor 的 web 管理界面，访问 http://127001:8000 可以看见 gunicorn 启动的返回的页面。

配置 Nginx

前面我们已经在系统环境下安装了 Nginx, 安装好的 Nginx 二进制文件放在 /usr/sbin/ 文件夹下，接下来使用

Supervisor 来管理 Nginx。这里需要注意一个问题，权限问题。Nginx 是 sudo 的方式安装，启动的适合也是 root

用户，那么我们现在也需要用 root 用户启动 supervisor。在 supervisorconf 下添加配置文件：

[program:nginx]command=/usr/sbin/nginxstartsecs=0stopwaitsecs=0autostart=falseautorestart=falsestdout_logfile=/home/wang/supervisor/log/nginxlogstderr_logfile=/home/wang/supervisor/log/nginxerr

好了，都配置完之后，启动 supervisor：

supervisord -c supervisorconf

访问页面，也可以用 ab 进行压力测试：

ab -c 100 -n 100 http://127001:8000/qw/1

-c 用于指定压力测试的并发数, -n 用于指定压力测试总共的执行次数。