写点什么

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

作者:Hunter熊
  • 2023-06-21
    北京
  • 本文字数:2083 字

    阅读完需:约 7 分钟

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

发布于: 刚刚阅读数: 3
用户头像

Hunter熊

关注

公众号:Hunter后端 2018-09-17 加入

Python后端工程师,欢迎互相沟通交流

评论

发布
暂无评论
Django笔记四十四之Nginx+uWSGI部署Django以及负载均衡操作_Python_Hunter熊_InfoQ写作社区