事情起因很简单，代码的改动量很大。而且刚接手服务器，对原有的代码进行了一定程度的重构。虽然在测试服务器上做了较多的测试工作，但是直接将代码送入生产环境还是不放心，万一配置出问题服务直接崩溃怎么解？万一遇到没有测出来的bug怎么解？so······

nginx负载均衡简介：

负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

负载均衡，英文名称为Load Balance，其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

以上是某科的解释，说的简单些就是一件事，按照一定的规则分配给拥有相同配置的机器去完成

服务器的架构：

因为我们生产环境服务器只有一台，所以是在一台机器内完成的。

图片已经把意思说的很明白的，接下来就是do it

Step1：配置nginx的负载均衡

修改nginx的配置文件（我的目录是/etc/nginx/nginx.conf),在http模块中添加：

# 负载均衡配置

upstream balance {

    # 开启ip_hash保证同一个用户访问到同一台服务器

    ip_hash;

    # 老服务器运行在11000+端口

    server 127.0.0.1:11001 weight=1;

    # 新服务器运行在12000+端口

    server 127.0.0.1:12001 weight=1;

} 

# 作为负载均衡的虚拟服务器

server {

        listen 10001;

        location / {

            proxy_pass        http://balance;

            proxy_set_header  X-Real-IP  $remote_addr;

        }

        access_log /data/logs/nginx.balance.access.log;

        error_log /data/logs/nginx.balance.error.log;

}

配置的字段是什么意思，找某度喽···

当然因为有include，可以把这段代码单独拿出来，减少对nginx配置文件的侵入（我放在/etc/nginx/conf.d/nginx_balance.conf)里面

Step2：新代码部署+启动

我是用supervisor管理进程的，用uwsgi启动代码，下面把相关的配置都放出来了

首先要让老代码运行到11001端口：

server {

        listen 11001;

        location / {

            add_header Access-Control-Allow-Origin *;

            root /data/www/app/;

            include uwsgi_params;

            uwsgi_pass 127.0.0.1:30000;

            uwsgi_read_timeout 360;

        }

        location ~/media/{

           root   /data/static/;

        }

        location = /favicon.ico {

            log_not_found off;

        }

        access_log /data/logs/nginx.qianming.access.log;

        error_log /data/logs/nginx.qianming.error.log;

}

其次是新代码的nginx配置，运行在12001端口：

server {

        listen 12001;

        location / {

            add_header Access-Control-Allow-Origin *;

            root /data/www_new/app/;

            include uwsgi_params;

            uwsgi_pass 127.0.0.1:31000;

            uwsgi_read_timeout 360;

        }

        location ~/media/{

           root   /data/static/;

        }

        location = /favicon.ico {

            log_not_found off;

        }

        access_log /data/logs/nginx.qianming.access.log;

        error_log /data/logs/nginx.qianming.error.log;

}

接下来是supervisor的配置：

; 需要将此配置文件软引用到supervisor的配置文件,默认路径:/etc/supervisor/

; 使用supervisor来管理进程,做到自动启动

[program:qianming_old]

directory=/data/www_new/app

command=uwsgi --ini confs/uwsgi.ini

autostart=true

最后是uwsgi的配置：

[uwsgi]

socket = 127.0.0.1:31000

chdir = /data/www_new/app/

wsgi-file = project/wsgi.py

processes = 1

threads = 4

chmod-socket = 664

chown-socket = www:www-data

当然要让配置生效，这里不展开讲了

nginx -t测试通过以后直接可以nginx -s reload加载nginx新的配置，新的代码在supervisor里卖直接启动就可以了，这样旧代码运行在11001端口，新代码运行在12001端口，而访问原先的10001端口会根据自定的规则决定返回11001端口或者12001端口的数据，而这个规则就是通过权重进行配置的，在nginx_balance.conf文件中通过weight配置的。

至此，代码的热部署已经完成。

Step3：测试和灰度发布

要想测试，直接访问12001端口就可以了，因为里面是最新的代码

灰度发布也就是控制weight的值，渐渐增大访问新代码的比例就可以了，直到新代码达到100%，老代码就可以正式宣告退役了^_^

巴特西

【nginx】nginx：利用负载均衡原理实现代码的热部署和灰度发布

nginx负载均衡简介：

服务器的架构：

Step1：配置nginx的负载均衡

Step2：新代码部署+启动

Step3：测试和灰度发布

最新文章

热门文章

巴特西

【nginx】nginx：利用负载均衡原理实现代码的热部署和灰度发布

nginx负载均衡简介 ：

服务器的架构：

Step1：配置nginx的负载均衡

Step2：新代码部署+启动

Step3：测试和灰度发布

最新文章

热门文章

nginx负载均衡简介：