Django笔记四十三之使用uWSGI部署Django系统
目前部署 Django 的方式一般来说是使用 Nginx + uWSGI + Django 来实现。
处理流程是，当一个请求发送过来会先经过 Nginx，如果是静态文件请求，Nginx 这一层直接处理，如果是后端动态接口，则会发送至 uWSGI，而 uWSGI 是一个 web 服务器，它实现的操作是将 HTTP 请求转换成 Python 支持的网络协议，比如 WSGI 协议。
以下是本篇笔记目录：
- Nginx 和 uWSGI
- WSGI、uWSGI 和 uwsgi
- uWSGI 示例及启动
- 配置项详解
1、Nginx 和 uWSGI
使用 Nginx 相当于实现了一次反向代理，也可以通过使用 Nginx 实现负载均衡，将请求分配给不同的后端服务，同时静态文件和动态接口分开请求，提高服务响应性能。
如果部署操作直接使用 uWSGI + Django，那么 uWSGI 就相当于一个 web 服务器，用于直接处理 HTTP 请求。如果是配合 Nginx 使用，相当于是一个中间件的作用，起到转发来自 Nginx 请求的作用。
2、WSGI、uWSGI 和 uwsgi
接下来理解一下 uWSGI，WSGI 和 uwsgi 这几个概念。
WSGI
web server gateway interface，web 服务器网关接口，是一种协议规范，是用于 wsgi 服务器（比如 uWSGI） 和 wsgi 应用（比如 Django）之间进行通信的规范。
uWSGI
web 服务器，或者叫 wsgi 服务器，实现 http 协议，用于接收 http 请求并能够解析信息。要将信息发给 Django，必须要用到 WSGI 协议，所以同时也可以实现 WSGI 协议。
uwsgi
是 uWSGI 服务器自有的线路协议，用于与 Nginx 等代理服务器通信。
3、uWSGI 示例及启动
我们可以通过 uWSGI 命令，将参数都写入命令行直接运行，也可以将配置项写入配置文件，用 uWSGI 直接获取配置信息，这里我们介绍都写入配置文件的方法来操作。
1、uWSGI 安装
首先我们需要安装一下 uWSGI：
pip3 install uwsgi -i https://mirrors.aliyun.com/pypi/simple/
2、配置示例及启动
假设我们的 Django 系统目录为 /path/to/hunter/，我们在该目录下创建一个文件 uwsgi.ini。
uwsgi.ini 内容如下：
# uwsgi.ini
[uwsgi]
http = :9898
chdir = /path/to/hunter/
wsgi-file = hunter/wsgi.py
master=true
processes = 4
threads = 2
以上是一个简单的可运行 uwsgi.ini 配置示例。
接着我们运行一下：
uwsgi uwsgi.ini
可以看到在 shell 的前台输出下面的信息：
*** Starting uWSGI 2.0.21 (64bit) on [Mon Mar 20 00:14:08 2023] ***
...
...
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 16291)
spawned uWSGI worker 1 (pid: 16295, cores: 2)
spawned uWSGI worker 2 (pid: 16296, cores: 2)
spawned uWSGI worker 3 (pid: 16299, cores: 2)
spawned uWSGI worker 4 (pid: 16301, cores: 2)
表示 uWSGI 已经正常启动，接着我们在浏览器访问该地址的 9898 端口的 admin 页面，可以看到没有样式的 admin 登录页面，如下：
image.png
4、配置项详解
在这里我们是直接使用 uWSGI + Django 的方式启动，所以首行是 http=:9898，表示可以通过浏览器的方式访问。
如果回头我们使用 Nginx + uWSGI + Django 的方式启动，这里就要改成 socket=:9898。
chdir
chdir 参数指向的是我们项目根目录
wsgi-file
这里我们填写的是相对地址，文件是 Django 系统在创建项目时自动创建的。
master
表示的是启动的 uWSGI 主进程是否开启
processes
表示启动的是进程数，所以在启动后输出的信息里，会有主进程和四个进程的信息
threads
表示的线程数，在上面的进程数后面 cores: 2，输出的就是线程信息。
除了上面这些参数，我们还可以定义一些其他的参数
daemonize
daemonize 的值为一个地址，用于记录 uWSGI 运行的日志，同时将服务在后台运行。
daemonize = /var/log/uwsgi/xxx.log
static-map
static-map 参数作用是映射 Django 的静态文件路径，前面我们运行之后，访问后台 admin 界面，发现没有前端样式对不对，如果想要有样式显示，则需要先定义这个参数，然后将 Django 的 admin 样式文件迁移到指定文件，操作步骤如下：
1.定义 STATIC_ROOT
首先，我们需要在 settings.py 里定义 STATIC_ROOT，这个参数是一个路径，表示我们在下一步需要将静态文件集中到的文件路径，假设我们需要把文件都集中到 /var/static/ 目录下：
# settings.py
STATIC_ROOT = "/var/static/"
2.collectstatic命令
接下来执行静态文件集中的命令：
python3 manage.py collectstatic --no-input
本来前面的命令就可以了，但是执行的时候会有选择项需要我们选择，在后续部署的时候，我们可以加上 --no-input 表示不需要提示输入信息。
3.定义static-map
接下来我们定义 static-map 就可以映射静态文件的地址，这样，我们使用 uWSGI 部署 Django 后也可以访问 admin 的静态文件里。
static-map = /static/=/var/static/
stats
stats 参数后面接的内容是端口，用于获取 uWSGI 几个 worker 的状态信息。
如果想要到浏览器访问的话还需要加一个 stats-http=true，如下：
stats = 127.0.0.1:9897
stats-http = true
timeout
关于 timeout 有两个参数，一个是 http-timeout，一个是 socket-timeout。
前面介绍了开放端口的时候，如果是 uWSGI 单独使用，就使用 http，那么 timeout 就使用 http-timeout
如果是配合 Nginx 使用，那么就使用 socket-timeout。
它的单位是秒.
http-socket=60 # 60秒超时时间
注意：上面的计算运行超时之后，会断开与前端的连接，但是后端还是会继续执行逻辑
harakiri
这个也是超时时间，但是与 timeout 不同的是，这个参数在超时之后断开连接之后，同时后端也停止执行运算，具体的操作是重启该请求所在的进程。
它的单位也是秒。
max-requests
重启进程的最大请求数，比如我们设置：
max-requests=5000
那么在某个 worker 进程处理 5000 个请求之后则会重启。
以上就是使用 uWSGI 启动 Django 系统的示例及介绍，在之后的笔记中会再介绍如何使用 Nginx 进行操作，包括使用 Nginx 进行反向代理和负载均衡的配置。
