centosflask+uWSGI+nginx部署
1. 概念
Flask自带webserver--Werkzeug，可以搭建服务，运行网站。但在开发时，一般会用专业的--uWSGI。
另外，常配合使的还有nginx。
1.1. uWSGI
uWSGI是一个全站式的托管服务，它实现了应用服务器（支持多种编程语言）、代理、进程管理器、监视器。取名为uWSGI是因为它最早实现的是Python语言的WSGI。
WSGI：一种实现python解析的通用接口标准/协议，是一种通用的接口标准或者接口协议，实现了pythonweb程序与服务器之间交互的通用性。
利用它，web.py或bottle或者django等等的pythonweb开发框架，就可以轻松地部署在不同的webserver上了；
uwsgi:同WSGI一样是一种通信协议
uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型，它与WSGI相比是两样东西。
uWSGI:一种pythonwebserver或称为Server/Gateway
uWSGI类似tornadoweb或者flup，是一种pythonwebserver，uWSGI是实现了uwsgi和WSGI两种协议的Web服务器，负责响应python的web请求。
因为apache、nginx等，它们自己都没有解析动态语言如php的功能，而是分派给其他模块来做，比如apache就可以说内置了php模块，让人感觉好像apache就支持php一样。
uWSGI实现了wsgi协议、uwsgi协议、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。
uWSGI是C语言写的，性能比较高。uWSGI包括四个部分：
1.2. Nginx
Nginx是高效的Web服务器和反向代理服务器，可以用作负载均衡（当有n个用户访问服务器时，可以实现分流，分担服务器的压力），可以进行安全过滤，防DDOS攻击等。与Apache相比，Nginx支持高并发，可以支持百万级的TCP连接，十万级别的并发连接，部署简单，内存消耗少，成本低，但Nginx的模块没有Apache丰富。
Nginx支持uWSGI的uwsgi协议，因此我们可以将Nginx与uWSGI结合起来，Nginx通过uwsgi_pass将动态内容交给uWSGI处理。
1.3. 为什么要用nginx
既然uWSGI可以起到Web服务器的作用，那么为什么有了uWSGI还需要Nginx呢？
最普遍的说法是Nginx对于处理静态文件更有优势，性能更好。其实如果是小网站，没有静态文件需要处理，只用uWSGI也是可以的，但加上Nginx这一层，优势可以很具体：
对于运维来说比较方便，如果服务器被某个IP攻击，在Nginx配置文件黑名单中添加这个IP即可，如果只用uWSGI，那么就需要在代码中修改了。
另一方面，Nginx是身经百战的Web服务器了，在表现上uWSGI显得更专业，比如说uWSGI在早期版本里是不支持https的，可以说Nginx更安全。
Nginx的特点是能够做负载均衡和HTTP缓存，如果不止一台服务器，Nginx基本就是必选项了，通过Nginx，将资源可以分配给不同的服务器节点，只有一台服务器，也能很好地提高性能，因为Nginx可以通过headers的ExpiresorE-Tag，gzip压缩等方式很好地处理静态资源，毕竟是C语言写的，调用的是native的函数，针对I/O做了优化，对于动态资源来说，Nginx还可以实现缓存的功能，配合CDN优化（这是uWSGI做不到的）。Nginx支持epoll/kqueue等高效网络库，能够很好地处理高并发短连接请求，性能比uWSGI不知道高到哪里去了。
如果服务器主机上运行了PHP，Python等语言写的多个应用，都需要监听80端口，这时候Nginx就是必选项了。因为我们需要一个转发的服务。
所以说，Nginx基本也是必选项。所以说虽然uWSGI本身就是一个web服务，这里再次引入Nginx就是为了把Nginx作为一个反向代理，这样，一些图片、js等静态资源就可以用Nginx提供服务，而其他的转发给uWSGI，这也是我们这套部署架构的最终目的。
2. 部署
2.1. 系统环境
centos6.5
python3.6.5
nginxn 1.10.3
uwsgi 2.0.18
2.2. uWSGI
uWSGI是一个由python实现的web容器，可以兼容性比较好地发布Django，Flask等pythonweb框架的应用。因为本质上来说uwsgi是python的一个模块，所以可以用pipinstalluwsgi直接来安装它。
安装完成之后可以在一个合适的目录建立一个uwsgi服务器的配置文件。比如我选择在项目的根目录建立了一个uwsgiconfig.ini的文件。顺便一提，除了ini格式的配置，uwsgi还支持json,xml等多种多样的配置格式。这里以ini格式为例。
2.2.1. 配置
直接使用uwsgi运行，配置文件如下：
[uwsgi]
http= 0.0.0.0:9000
chdir = /home/web_server/flask/website
wsgi-file= run.py
callable= app
processes=4
threads=2
pidfile = /home/web_server/flask/uwsgi.pid
daemonize = /home/web_server/flask/server.log
各参数说明：
由uwsgi指定了端口后无需再指定flask的运行端口，实际是给出callable变量后，由uwsgi执行run()
socket：套接字通讯端口，相当于为外界留出一个uWSGI服务器的接口，负责与Nginx通信，但注意socket是无法直接通过http请求成功访问。
pythonpath：项目目录。
callable：程序内启用的application变量名，一般而言都是app=Flask(__name__)的所以这里是app。
processes：处理器个数。
threads：线程数。
processes和threads指出了启动uwsgi服务器之后，服务器会打开几个并行的进程，每个进程会开几条线程来等待处理请求，显然这个数字应该合理，太小会使得处理性能不好而太大则会给服务器本身带来太大负担。
stats：获取uwsgi统计信息的服务地址
daemonize：使uWSGI进程在后台运行，并将日志打到指定的日志文件或者udp服务器.
2.2.2. 启动/停止
uWSGI 通过 xxx.ini 启动后会在相同目录下生成一个 xxx.pid 的文件，里面只有一行内容是 uWSGI 的主进程的进程号。
uWSGI 启动：
uwsgi --ini xxx.ini
uwsgi 重启：
uwsgi --reload xxx.pid
uwsgi 停止：
uwsgi --stop xxx.pid
pid文件需手动指定生成
2.2.3. 问题
关闭问题
手动指定pid文件后，实际起了4个进程，但pid中只有一个pid，使用—stop关闭也仅关闭pid文件中所记录的一个进程，其余3个只能kill
批量杀死进程：
pkill uwsgi
pkill -f uwsgi -9 # 一般用不到
2.3. nginx
2.3.1. 安装
yum install nginx
查看版本
nginx version: nginx/1.10.3
2.3.2. 配置
配置文件的路径不尽相同，centos上用yum安装时，一般配置文件在/etc/nginx/nginx.conf
修改nginx.conf配置文件，但这里不直接修改，而使用另一种方式（推荐）
默认安装的Nginx配置文件/etc/nginx/nginx.conf内尾部有如下配置
include /etc/nginx/conf.d/*.conf;
即从外部目录/etc/nginx/conf.d/文件夹下还引入了其他配置文件。
这样，不修改默认配置文件，在/etc/nginx/conf.d/目录下新增加一个webapp.conf，从而增加配置文件体系健壮性。
webapp.conf内容如下：
server {
listen 9002; //web访问端口
server_name localhost; //服务器名
charset utf-8;
access_log /var/www/webapp/access.log; //服务器接收的请求日志，logs目录若不存在需要创建，否则nginx报错
error_log /var/www/webapp/error.log; //错误日志
client_max_body_size 100M;
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:9000; //需要和uwsgi的配置文件里socket项的地址相同,否则无法让uwsgi接收到请求。
#uwsgi_param UWSGI_PYHOME /var/www/webapp/venv;
uwsgi_param UWSGI_CHDIR /home/web_server/flask/web_test; //项目根目录
#uwsgi_param UWSGI_SCRIPT run:app; //启动项目的主程序(在本地上运行
//这个主程序可以在flask内置的
//服务器上访问你的项目),其实可以在uwsgi中指定
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
问题：
unknown directive "listen " in
配置文件中有tab空格，用正常空格替换即可。
2.3.3. 启动/停止
启动：nginx -c /usr/local/nginx/conf/nginx.conf
停止:
关闭nginx系统方式：
（1）命令
当nginx启动后，可以使用“-s”参数向nginx管理进程（即master进程）发送信号来控制nginx：nginx -s signal
其中，signal可以是以下值：
[1] stop：快速关闭
[2] quit：安全关闭
[3] reload：重载配置文件
[4] reopen：重新打开一个log文件，主要用于日志切割
quit信号，通知nginx等待worker进程处理完当前的请求后退出，此命令只能由启动nginx的linux账户来执行。
reload信号，通知nginx重新载入配置文件nginx.conf。 除了使用reload外，nginx只会在启动时载入一次配置文件，之后对配置文件的修改不会实时对已经运行的nginx进程生效。
当运行这个命令时，master进程会尝试读取配置文件，如果配置文件没有问题（配置文件有问题怎么验证呢？请看下文）：
master进程会启动新的worker进程来运行新的配置文件并处理请求，同时会通知老的worker进程不再处理新的请求并在处理完当前任务后退出。
如果配置文件存在问题不能执行，master进程会回退老配置文件继续工作，不会导致nginx进程整个异常退出。
linux的kill命令也可以达到相同的作用，假设nginx的master进程号（pid）是123456，那么 kill -s QUIT 123456 和 kill -s HUP 123456 这两条命令和前面quit、reload的作用相同。
关闭nginx命令1：
nginx -s quit
【3】重载配置
重新加载配置文件
（1）命令
nginx -s reload
2.4. uWSGI重新配置
uwsgi独立运行与使用nginx时的配置不一样
配置文件：uwsgi_nginx.ini
[uwsgi]
socket = :9000
chdir = /home/web_server/flask/website
wsgi-file= run.py
callable= app
processes=4
threads=2
pidfile = /home/web_server/flask/uwsgi.pid
daemonize = /home/web_server/flask/server.log
3. 测试结果
3.1. uWSGI
不使用nginx，直接运行uWSGI
uwsgi uwsgi_independent.ini
3.1.1. 结果展示
访问http://ip:9000/成功。
3.2. uWSGI+ nginx
先启动uwsgi，如果不写绝对路径需要在ini文件当前路径执行
[root@soft flask]# uwsgi uwsgi_nginx.ini
启动nginx
nginx -c /etc/nginx/nginx.conf
3.2.1. 结果展示
访问http://ip:9002/成功。
注意：在配置nginx时指定。
4. 附录
4.1. 常用命令
ps -ef |grep uwsgi
uwsgi uwsgi.ini
uwsgi --stop uwsgi.pid
kill -9