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

本文首发于公众号：Hunter后端
原文链接：Django笔记四十四之Nginx+uWSGI部署Django以及Nginx负载均衡操作

这一篇笔记介绍如何使用 Nginx + uWSGI 来部署 Django。
上一篇笔记中有介绍直接使用 uWSGI 作为 web 服务器来部署 Django，这一篇笔记介绍如何使用 Nginx 来部署。
使用 Nginx 来部署相当于在 uWSGI 外面又嵌套了一层，uWSGI 作为内部服务被隐藏起来，这时候 Nginx 起的作用是反向代理。
在这里，Nginx 的安装操作就不赘述了，网上都可以找得到如何操作，这里只讲相关的配置操作。
以下是本篇笔记目录：

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

1、uWSGi 配置

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

1. # uwsgi.ini
3. [uwsgi]
4. socket = :9898
5. chdir = /path/to/hunter/
6. wsgi-file = hunter/wsgi.py
7. master=true
8. processes = 4
9. threads = 2

复制代码

注意，这里配置项的第一行已经从 http 改成了 socket
如果使用 http，表示我们将 uWSGI 直接作为一个 web 服务器，比如可以在浏览器访问相关接口。
如果使用 socket，表示会有比如 Nginx 一样的服务来作为 web 服务器，这个时候 uWSGI 起到类似中间件的作用，负责将来自 web 服务器的请求解析后转发给 Django 来处理。
2、Nginx 配置及其作用

在我这里，Nginx 的相关配置在 /etc/nginx/nginx.conf
Nginx 的配置如下：

1. http {
2.    
3.     server {
4.         listen 8900;
6.         location / {
7.             include uwsgi_params;
8.             uwsgi_pass 127.0.0.1:9898;
9.             uwsgi_read_timeout 2;
10.         }
11.     }
12. }

复制代码

这里，listen 表示 Nginx 对外开放的是 8900 端口
location 表示的是定义的路由，这里是 /，表示 8900 端口后可以直接接上 Django 系统的 api 接口。我们也可以改成其他的，比如 /backend，那么访问 Django 的每一个接口前缀都要加上 /backend
其下，uwsgi_pass 表示指向的是本机的 9898 端口服务，这里和我们 uWSGI 里的配置是一致的
uwsgi_read_timeout 表示的是超时时间，这里定义的是两秒。
接下来我们启动 uWSGI 服务和 Nginx 服务：

1. uwsgi uwsgi.ini
3. 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 的配置如下：

1. http {
2.     upstream web {
3.         server 192.168.1.31:9898;
4.         server 192.168.1.33:9898;
5.         server 192.168.1.144:9898;
6.     }
7.    
8.     server {
9.         listen 8900;
11.         location / {
12.             proxy_pass http://web;
13.         }
14.     }
15. }

复制代码

上面的这种方式配置之后，重启 Nginx 和 uWSGI 之后，就会通过轮询的方式来发送请求到三个 Django 服务了。
注意：上面的配置方式，proxy_pass 表示是基于 http 协议进行请求的，也就是说 Nginx 到 uWSGI 走的是 http 协议，我们需要将 uwsgi.ini 的配置改成 http=:9898。
如果要走之前的 uwsgi 协议请求方式，需要将 Nginx 的这里改成这样：

1.     server {
2.         listen 8900;
4.         location / {
5.             include uwsgi_params;
6.             uwsgi_pass web;
7.         }

复制代码

2. 加权

加权就是可以人为控制到几个服务器请求的数量的占比，比如对于这三个后端，想要请求到它们的请求的数量比为 1:2:3，可以这样设置：

1.     upstream web {
2.         server 192.168.1.31:9898 weight=1;
3.         server 192.168.1.33:9898 weight=2;
4.         server 192.168.1.144:9898 weight=3;
5.     }

复制代码

这样，来六个请求的话，这三个后端分配到的请求数量分别是 1，2，3个。
3. ip hash

这是根据客户端地址来进行分配的一个操作，假设某个请求的 ip 是 192.168.1.59，这时候 Nginx 会根据 ip 计算一个值之后映射到三个后端服务的某一个，在之后的每次请求都会指向这个后端服务。
其配置如下：

1.     upstream web {
2.         ip_pash;
3.         server 192.168.1.31:9898;
4.         server 192.168.1.33:9898;
5.         server 192.168.1.144:9898;
6.     }

复制代码

如果使用 ip hash 策略，来自某个客户端的请求都会定向指向某个后端服务，因此可以不用担心解决后端服务共享 session 的问题。
注意：因为需要处理 session 共享的问题，所以在上面的测试中，我这边都是直接访问的不用登录，也就是不用担心 session 问题的接口。
在实际的负载均衡的后端服务中，session 的共享，使用户保持登录状态而无感，是一个需要解决的问题，这个在之后有机会的话再开笔记详细讲述。
如果想获取更多相关文章，可扫码关注阅读：


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！