Django 笔记四十四之 Nginx+uWSGI 部署 Django 以及负载均衡操作

本文首发于公众号：Hunter 后端

原文链接：Django笔记四十四之Nginx+uWSGI部署Django以及Nginx负载均衡操作

这一篇笔记介绍如何使用 Nginx + uWSGI 来部署 Django。

上一篇笔记中有介绍直接使用 uWSGI 作为 web 服务器来部署 Django，这一篇笔记介绍如何使用 Nginx 来部署。

使用 Nginx 来部署相当于在 uWSGI 外面又嵌套了一层，uWSGI 作为内部服务被隐藏起来，这时候 Nginx 起的作用是反向代理。

在这里，Nginx 的安装操作就不赘述了，网上都可以找得到如何操作，这里只讲相关的配置操作。

以下是本篇笔记目录：

1. uWSGI 配置

2. Nginx 配置及其作用

3. Nginx 实现负载均衡

1、uWSGi 配置

我们还是复用上一篇笔记中的 Django 系统代码和 uWSGI 配置

# uwsgi.ini
[uwsgi]socket = :9898chdir = /path/to/hunter/wsgi-file = hunter/wsgi.pymaster=trueprocesses = 4threads = 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 的共享，使用户保持登录状态而无感，是一个需要解决的问题，这个在之后有机会的话再开笔记详细讲述。