我们使用flask写好一个项目之后，肯定要进行部署。咦，可是我们之前写完了，直接运行就可以了，也没有部署啊。那么因为flask或者Django都自带了一个简单的小型服务器，但是只是用来做测试使用的，不建议上线部署。
那我们怎么办呢？答案是使用Nginx和uWSGI。
不过先来介绍几个概念，Nginx，uWSGI，uwsgi，web框架，uwsgi，WSGI
WSGI,uwsgi,web框架：
WSGI全称是web服务网关接口，我们使用web框架写好了一个服务，我们要把它部署在应用服务器上，如uWSGI。但应用服务器并不是支持所有的web框架，一个web框架写出来的服务也并不是适应所有的应用服务器。这个时候一个规定或者说是协议就出现了，如果应用服务器和web框架都遵循某种协议，那么遵循该协议的web框架写出来的服务就能够部署在所有同样遵循该协议的应用服务器上面，同理遵循该协议的应用服务器可以支持所有同样遵循该协议的web框架所编写的服务，这个协议就叫做WSGI。web框架就不用说了，就是我们说的flask或者Django，我们都用它们编写一些服务。
uWSGI就是一个应用服务器，它里面有着web框架写好的服务，当请求到来时，会将请求交给我们的web框架写好的服务，那么如何才能交给呢？比如flask，flask内部还引用了好几个其它的模块，其中一个模块叫做werkzeug，这是一个实现了WSGI的框架，所以才能够接收uWSGI传过来的请求(如果没有uWSGI，那么其内部会有一个简单的socket来循环接收请求，但是不推荐生产使用)，接收到请求后会判断这是哪一个请求，然后去交给我们的视图函数去执行。执行完之后，那么会将结果通过WSGI返回给我们的应用服务器，如uWSGI
Nginx,uwsgi,uWSGI：Nginx是一个web服务器，咦怎么又多了一个服务器。Nginx可以用来做负载均衡，端口转发等等，而且如果我们只是访问一个静态文件，那么nginx直接就帮忙处理了，这些是uWSGI所无法做到的，而且nginx还可以反向代理等等。当一些需要逻辑处理的请求到来时，nginx才会交给uWSGI，换句话说nginx能做了就自己做了，如果不是自己做的再交给其他人去做。那么nginx要想把请求交给uWSGI，那么两者是不是也需要遵循某种协议啊，就跟uWSGI和web框架一样，这个协议就叫做uwsgi。所以说uWSGI是实现了两种协议，因为它处在中间的位置，左边是nginx(实现uwgsi)右边是web框架(实现WSGI)。关于uwsgi协议，其它语言也有使用cgi，都是类似的，但是uwsgi比cgi要快上10倍左右。
总结一下就是：
uWSGI是python编写的，因此可以直接使用pip install uwsgi，但是在windows上面不能用，会有一大堆乱七八糟的麻烦，所以还是在ubuntu上使用吧
首先我写好了一个flask的项目，因此我们需要在一个合适的地方建立一个uwsgi.ini配置文件，当然文件不一定非要是ini格式的。我这里就直接在根目录创建了
已经启动成功了，可以看到是后台启动的
但是我们在配置文件中指定了8000端口，看看访问能不能成功
因为我们在配置文件中指定的是8000端口，因为我们根本就没有使用flask自带的服务器，而是使用的uWSGI，所以使用uWSGI指定的端口，uWSGI帮我们接收请求，然后进行路由映射，再交给框架编写的服务去执行相应的逻辑。所以这时候再使用5000端口是行不通的，也就是说不管你在app.run()中指定的端口是多少，根本无所谓，因为请求根本不是从flask自带的服务器那里过来的。
下面我们就来安装nginx来搭配uWSGI来使用，其实公司部署项目基本上还是部署在linux上，因为nginx是一个基于epoll的服务器，而epoll只有linux上才有
ubuntu上安装nginx也非常简单，直接apt-get install nginx
nginx常用命令：
**启动nginx：service nginx start **
关闭nginx：service nginx stop
重启nginx：service nginx restart
nginx -v：查看版本
nginx -t：测试配置文件是否有语法上的错误
nginx的配置文件位于/etc/nginx/conf.d目录下，我们创建配置文件直接在这个目录下创建即可。但是nginx默认读取的配置文件为/etc/nginx/nginx.conf，因此我们如果要指定配置文件开启的话可以加上-c参数
安装完毕之后，默认启动，直接在浏览上输入localhost:80，当然80也可以不输，因为默认访问80端口，如果出现相应的页面就代表启动成功了
下面我们来编写nginx 的配置文件
编写uwsgi配置文件
nginx配置文件修改之后要记得重新启动，并且要指定我们创建的配置文件
启动uwsgi
因此我们的逻辑差不多是这样子。当浏览器发送请求，会先到nginx，nginx判断是不是静态文件访问，如果是直接返回，如果不是就把请求放到socket里面，然后uWSGI会不断读取请求，然后将请求交给web服务，执行完之后将结果返回给uWSGI，然后交给socket，交给nginx，再交给浏览器。就是一个闭环，怎么来的怎么回去。
当我访问static的时候，表示访问静态文件，直接就返回了。
你以为这样就完事了，当然没有，当我们的服务上线之后，肯定不可以莫名其妙的挂掉， 所以还需要进行监视，有什么动静可以第一时间观测到。这就需要另一个模块了，叫supervisor，用来管理uWSGI进程，可以在uWSGI发生意外的情况下，自动重启。当然也需要安装，如果是python2直接pip install supervisor即可，但是python3的话，需要pip3 install git+https://github.com/Supervisor/supervisor
在项目的根目录下创建一个ss_supervisor.conf,写上一些配置
下面就可以直接通过supervisor来启动了，supervisord -c ss_supervisor.conf, 别忘了启动的时候supervisor后面有个d，-c是指定配置文件，如果只是文件名，那么要进入到相应的目录
如果我们不启动supervisor直接访问，会出现如下页面
然后我们启动supervisor
然后，我不明白，我的ubuntu一直会卡死，但是应该是可以访问成功的。如果想关闭的话，可以使用kill -9 xxx，但是不推荐这样关闭，因为太粗暴了。
我们可以使用supervisorctl -c xxx.conf，这个supervisorctl不需要单独安装，在我们安装supervisor的时候就已经安装了。
不要忘记要在配置文件写入[supervisorctl]这个节点，不然会报错。
然后supervisord -c ss_supervisor.conf 启动服务
supervisorctl -c ss_supervisor.conf进入交互模式
status：查看状态
start program_name：启动程序
restart program_name：重新启动程序
stop program_name：关闭程序
reload：重新加载配置文件
quit：退出控制台
我不明白我的ubuntu为什么每当执行supervisord -c ss_supervisor.conf 这行命令的时候就会卡死，所以就不演示了。如果要是不执行这行代码的话，直接使用supervisorctl -c ss_supervisor.conf结果应该是这个样子
