为什么生产上不使用Web框架自带的服务
Python有内置的WSGI服务器，用来做Python Web开发的框架，例如Flask，Django等，也会对WSGI做实现。因此写完代码，想要调试的时候，就可以使用Python内置的，或者Web框架提供的WSGI服务器。
既然这样，为什么生产环境的部署，和我们调试时的方式不太一样呢？
因为不管是Python内置的，还是Web框架的服务，它们都不是专注于实现服务器的，只是提供了一个可用的功能，却并不适合生产上复杂的环境。
举个简单的例子：生产上用户访问众多，那就来看看Flask自带的服务器性能表现如何。
进行压测，我这里只用了10用户并发循环访问10次（大家也可以自己试试），这个服务就挂了。说明Flask框架提供的WSGI服务器并不能承受很大的压力，如果生产上这样部署，一定会出问题的。
生产环境的Web部署
所以本文主要讲讲生产环境上的部署，这里使用的是Nginx+Gunicorn+Flask+Supervisor的方式。
nginx 不用多说，一个高性能的web服务器。
webservice常见的有FastCGI，WSGI等。我们这里使用gunicorn为WSGI容器。使用Python编写服务，采用Flask框架。同时采用supervisor管理服务器进程。
安装 gunicorn
pip install gunicorn
pip 是一个重要的工具，python 用来管理包。每次使用 pip 安装的库，都写入一个 requirement 文件里面，既能知道自己安装了什么库，也方便别人部署时，安装相应的库。
pip freeze > requirements.txt
以后每次 pip 安装了新的库的时候，都需freeze 一次。
在我的manage.py文件里面，有如下代码：
if __name__ == '__main__':
app.run(host = '0.0.0.0' ,port = 8001, debug=True)
这个含义是用 flask 自带的服务器启动 app。当我们使用gunicorn 启动 flask时，manage.py 就等同于一个库文件，被 gunicorn 调用。
所以gunicorn后面的参数如下:
gunicorn -w4 -b0.0.0.0:8001 manage:app
gunicron就是替代Flask自带的一个web server。
其中 gunicorn 的部署中，-w 表示开启多少个 worker，-b 表示 gunicorn开发的访问地址。
想要结束 gunicorn 只需执行 pkill gunicorn，有时候还要用 ps 找到 pid 进程号才能 kill。可是这对于一个开发来说，太过于繁琐，因此出现了另外一个神器---supervisor
，一个专门用来管理进程的工具，还可以管理系统的工具进程。
安装supervisor
pip install supervisor
进行简单的配置，就可以使用 supervsior 启动 gunicorn啦。运行命令 supervisord -c supervisor.conf
安装配置 nginx
sudo apt-get install nginx
参考http://www.cnblogs.com/Ray-liang/p/4837850.html进行部署
至于为啥要用ngnix：
有了gunicorn，为何还需要nginx
小结
- 写Flask Web程序，调试时可以运行在自带的web server上
- 在生产环境的服务器上，使用gunicorn
- 外面套一层ngnix服务器，好处上文有说
网友评论