公司的开发项目是基于Django框架进行的,为保证后续线上抗压及冗余能力,需对底层架构进行分布式负载均衡的运行方式,考虑了uwsgi和django的完美双簧,但是总感觉多一层代理可能回多一层故障源,经过大量线下测试,目前还是采用了nginx负载及代理的方式进行了项目实战,目前测试没有任何问题,若后续有问题则立即切回nginx+uwsgi+django的集群模式。
好!闲话不多说,先上一个架构图
这个图可以说是很直观了,我没有采用lvs、keepalive等,就是直接模块式累加,目前所有django都使用的式同一台数据库(mysql)这跟我们的业务类型有关,数据库只存储的一些关联关系及结构,主要还是考django处理数据,所有数据库这块只配了一台,当然 多台数据库集群也是ok的 弄个一主多从的 mysql集群就可以了 这里就不赘诉了,等后续有空了 我在写一个数据库一主多从的博客吧,同事nginx也是单台,因为主要面向技术部不会有几千几万的访问量所以一台够用了,如果考虑到后续的安全及稳定性在部署一个前端集群配合就行啦这就要用到lvs或者keepalive了。
1、报下每个ip的作用:
10.100.0.89 16核 16G nginx服务 同时为了节省有序的资源 也部署了一套django (从)
10.100.0.88 8核 8G django服务(从)
10.100.0.87 8核 8G django服务 (从)
10.100.0.98 16核 16G django服务 (主) 这台时研发使用的主django服务器,所有的代码都会从这台 通过rsync+inotify的方式实时发送给其他三台从django服务器
2、使用的版本
nginx 1.8
django3.0
python3.7.2
rsync centos7 系统自带的
inotify 3.14 这个 可能要编译安装下载地址https://pan.baidu.com/s/1ImFqAB786xW2g1yqANVnkA 提取码: ndgm
好了这样吧,这些工具的安装我就不在赘述了,网上一大把,如果有问题可以联系我V:limumufa
3、关闭系统服务
将firewall 和selinux 关闭
4、下面咱们贴下配置吧,首先时 nginx的负载均衡配置及代理,直接替换你的 nginx。conf就行拉
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
upstream 10.100.0.89 {
least_conn;
server 10.100.0.87:8000 weight = 2;
server 10.100.0.88:8000 weight = 2;
server 10.100.0.89:8000 weight = 3;
server 10.100.0.98:8000 backup;
}
server {
listen 80;
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers Authorization,Origin,X-Requested-With,Content-Type,Accept;
#add_header Access-Control-Allow-Methods POST,GET,PATCH,PUT,DELETE,OPTIONS,VIEW;
add_header Access-Control-Allow-Methods POST,GET,PATCH,PUT,DELETE;
add_header Access-Control-Allow-Credentials true;
client_max_body_size 100m;**
location / {
proxy_pass http://10.100.0.89;
}
}
}
这里要注意,upstream后面的名字就是你后续要访问的名字了域名或者ip都行,要跟location那里url一样就行。
简单了解下 upstream的模块
序号 均衡策略 说明 参数 说明 特点
1 轮询 默认方式
2 weight 权重方式 weight weight参数用于指定轮询几率,weight的默认值为1 "权重越高分配到需要处理的请求越多。
此策略可以与least_conn和ip_hash结合使用。
此策略比较适合服务器的硬件配置差别比较大的情况。"
backup 标记该服务器为备用服务器。当主服务器停止时,请求会被发送到它这里。
ail_timeout 与max_fails结合使用
max_fails 设置在fail_timeout参数设置的时间内最大失败次数,如果在这个时间内,所有针对该服务器的请求都失败了,那么认为该服务器会被认为是停机了
fail_time 服务器会被认为停机的时间长度,默认为10s。
down 标记某台应用服务器暂时不参与负载均衡
3 ip_hash 依据ip分配方式 指定负载均衡器按照基于客户端IP的分配方式,这个方法确保了相同的客户端的请求一直发送到相同的服务器,以保证session会话。这样每个访客都固定访问一个后端服务器,session共享 "在nginx版本必须大于1.3.1。
此策略适合开发中常用于解决session共享的问题
ip_hash不能与backup同时使用。
当有服务器需要剔除,必须手动down掉。"
4 least_conn 最少连接方式 "避免单台负载套高,根据服务器的负载动态的分配用户请求,轮询将请求尽可能平均的转发给各个django后端,使她们的负载大致相同
"
5 fair(第三方) 响应时间方式
6 url_hash(第三方) 依据URL分配方式
7 sticky(第三方) 压力均衡
好了,这样nginx启动起来就好了,就是这么简单。
5、下面看下 rsync的配置
首先98作为源端服务器,安装rsync+inotify,其中rsync无需启动
88、87、89三台作为从django服务器需要实时获取98django的更新,那么需要安装rsync并启动,由于三台从服务器 配置都一样我这里就以89为例了。
5.1、89服务器rsync配置
在/etc下面有个rsyncd.conf如果没有就创建,我这里使用的是root账户,其他账户也可以 权限设置对即可
如图记得创建图中最后一行一个密码文件
echo "root:limumufa"> /etc/rsync.password
并设置所属用户的600访问权限
chmod 600 /etc/rsync.password
完成通过rsync或者scp将配置文件分派到其他几台服务器上
启动:rsync --daemon 查看端口:netstat -anpt | grep 873(默认端口)
6、最后看下inotify的配置文件
登录到98那台服务器 编译安装inotify
6.1、添加推送到其他服务器的密码文件(其他从服务器的密码,我这里都设置了同样的密码limumufa)
echo "limumufa"> /etc/rsync.password 注意这里只需要配置密码就行拉,千万不要加用户名,否则inotify会一直包模块名的错误,无法同步的 ,完成后同样600的权限
6.2、inotify配置脚本
OK !! 放到后台启动 nohup sh inotify.sh &
所有服务器都启动起来,测试吧,速度嗖嗖嗖的。