关于后端:Django笔记四十四之NginxuWSGI部署Django以及负载均衡操作

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

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

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

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

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

在这里，Nginx 的安装操作就不赘述了，网上都能够找失去如何操作，这里只讲相干的配置操作。

以下是本篇笔记目录：

uWSGI 配置
Nginx 配置及其作用
Nginx 实现负载平衡

咱们还是复用上一篇笔记中的 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 来解决。

在我这里，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 上篇笔记中的对应的动态文件配置。

在下面的操作中，一个申请从客户端到 Nginx，再到 uWSGI 和 Django，这个过程就是反向代理。

而如果申请量过大，一个 uWSGI 和 Django 和对应的数据库可能扛不住拜访压力，所以须要增设多个后端来分担申请，这个就是负载平衡。

首先介绍一下负载平衡的几种策略：

轮询
加权
ip hash

这里假如咱们起了三个后端实例，ip 和端口别离是 192.168.1.31:9898、192.168.1.33:9898、192.168.1.144:9898

所谓的轮询，就是依照申请的工夫程序一一调配到指定的这三个后端服务上，这里 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;
        }

加权就是能够人为管制到几个服务器申请的数量的占比，比方对于这三个后端，想要申请到它们的申请的数量比为 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 个。

这是依据客户端地址来进行调配的一个操作，假如某个申请的 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 的共享，使用户放弃登录状态而无感，是一个须要解决的问题，这个在之后有机会的话再开笔记具体讲述。

如果想获取更多相干文章，可扫码关注浏览：

关于后端:Django笔记四十四之NginxuWSGI部署Django以及负载均衡操作

1、uWSGi 配置

2、Nginx 配置及其作用

3、Nginx 实现负载平衡

1. 轮询

2. 加权

3. ip hash