本文首发于公众号：Hunter后端
这一篇笔记介绍如何使用 Nginx + uWSGI 来部署 Django。
上一篇笔记中有介绍直接使用 uWSGI 作为 web 服务器来部署 Django，这一篇笔记介绍如何使用 Nginx 来部署。
使用 Nginx 来部署相当于在 uWSGI 外面又嵌套了一层，uWSGI 作为内部服务被隐藏起来，这时候 Nginx 起的作用是反向代理。
在这里，Nginx 的安装操作就不赘述了，网上都可以找得到如何操作，这里只讲相关的配置操作。
以下是本篇笔记目录：
- uWSGI 配置
- Nginx 配置及其作用
- Nginx 实现负载均衡
1、uWSGi 配置
我们还是复用上一篇笔记中的 Django 系统代码和 uWSGI 配置
# uwsgi.ini
[uwsgi]
socket = :9898
chdir = /path/to/hunter/
wsgi-file = hunter/wsgi.py
master=true
processes = 4
threads = 2注意，这里配置项的第一行已经从 http 改成了 socket
如果使用 http，表示我们将 uWSGI 直接作为一个 web 服务器，比如可以在浏览器访问相关接口。
如果使用 socket，表示会有比如 Nginx 一样的服务来作为 web 服务器，这个时候 uWSGI 起到类似中间件的作用，负责将来自 web 服务器的请求解析后转发给 Django 来处理。
2、Nginx 配置及其作用
在我这里，Nginx 的相关配置在/etc/nginx/nginx.conf
Nginx 的配置如下：
http {
server {
listen 8900;
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:9898;
uwsgi_read_timeout 2;
}
}
}这里，listen 表示 Nginx 对外开放的是 8900 端口
location 表示的是定义的路由，这里是/，表示 8900 端口后可以直接接上 Django 系统的 api 接口。我们也可以改成其他的，比如/backend，那么访问 Django 的每一个接口前缀都要加上/backend
其下，uwsgi_pass 表示指向的是本机的 9898 端口服务，这里和我们 uWSGI 里的配置是一致的
uwsgi_read_timeout 表示的是超时时间，这里定义的是两秒。
接下来我们启动 uWSGI 服务和 Nginx 服务：
uwsgi uwsgi.ini
sudo /etc/init.d/nginx restart这时候访问 Nginx 所在的 地址的 8900 端口，http://192.168.1.33:8900/admin，就可以访问我们的 Django 系统了。
如果想要 admin 页面有前端样式展示，记得添加 uwsgi.ini 上篇笔记中的对应的静态文件配置。
3、Nginx 实现负载均衡
在上面的操作中，一个请求从客户端到 Nginx，再到 uWSGI 和 Django，这个过程就是反向代理。
而如果请求量过大，一个 uWSGI 和 Django 和对应的数据库可能扛不住访问压力，所以需要增设多个后端来分担请求，这个就是负载均衡。
首先介绍一下负载均衡的几种策略：
- 轮询
- 加权
- ip hash
这里假设我们起了三个后端实例，ip 和端口分别是 192.168.1.31:9898、192.168.1.33:9898、192.168.1.144:9898
1. 轮询
所谓的轮询，就是按照请求的时间顺序逐个分配到指定的这三个后端服务上，这里 Nginx 的配置如下：
http {
upstream web {
server 192.168.1.31:9898;
server 192.168.1.33:9898;
server 192.168.1.144:9898;
}
server {
listen 8900;
location / {
proxy_pass http://web;
}
}
}上面的这种方式配置之后，重启 Nginx 和 uWSGI 之后，就会通过轮询的方式来发送请求到三个 Django 服务了。
注意：上面的配置方式，proxy_pass 表示是基于 http 协议进行请求的，也就是说 Nginx 到 uWSGI 走的是 http 协议，我们需要将 uwsgi.ini 的配置改成http=:9898。
如果要走之前的 uwsgi 协议请求方式，需要将 Nginx 的这里改成这样：
server {
listen 8900;
location / {
include uwsgi_params;
uwsgi_pass web;
}2. 加权
加权就是可以人为控制到几个服务器请求的数量的占比，比如对于这三个后端，想要请求到它们的请求的数量比为 1:2:3，可以这样设置：
upstream web {
server 192.168.1.31:9898 weight=1;
server 192.168.1.33:9898 weight=2;
server 192.168.1.144:9898 weight=3;
}这样，来六个请求的话，这三个后端分配到的请求数量分别是 1，2，3个。
3. ip hash
这是根据客户端地址来进行分配的一个操作，假设某个请求的 ip 是 192.168.1.59，这时候 Nginx 会根据 ip 计算一个值之后映射到三个后端服务的某一个，在之后的每次请求都会指向这个后端服务。
其配置如下：
upstream web {
ip_pash;
server 192.168.1.31:9898;
server 192.168.1.33:9898;
server 192.168.1.144:9898;
}如果使用 ip hash 策略，来自某个客户端的请求都会定向指向某个后端服务，因此可以不用担心解决后端服务共享 session 的问题。
注意：因为需要处理 session 共享的问题，所以在上面的测试中，我这边都是直接访问的不用登录，也就是不用担心 session 问题的接口。
在实际的负载均衡的后端服务中，session 的共享，使用户保持登录状态而无感，是一个需要解决的问题，这个在之后有机会的话再开笔记详细讲述。