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

本文首发于公众号: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 = :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 的共享,使用户保持登录状态而无感,是一个需要解决的问题,这个在之后有机会的话再开笔记详细讲述。

如果想获取更多相关文章,可扫码关注阅读:

热门相关:她的品味   被强迫的爱人   她们的果汁   朋友夫妻互换体验   饥渴的巨乳女性