事情起因很简单，代码的改动量很大。而且刚接手服务器，对原有的代码进行了一定程度的重构。虽然在服务器上做了较多的测试工作，但是直接将代码送入生产环境还是不放心，万一配置出问题服务直接崩溃怎么解？万一遇到没有测出来的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/appcommand=uwsgi --ini confs/uwsgi.iniautostart=true

最后是uwsgi的配置：

[uwsgi]socket = 127.0.0.1:31000chdir = /data/www_new/app/wsgi-file = project/wsgi.pyprocesses = 1threads = 4chmod-socket = 664chown-socket = www:www-data

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

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

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

Step3：测试和灰度发布

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

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