最开始我的Go-Web服务运行于 127.0.0.1:90,提供用户直接访问,
现在我使用Nginx来代理,关键配置如下
upstream myapp1 { server 127.0.0.1:90; } server { listen 80; location / { proxy_pass http://myapp1; } }
现在用户通过 127.0.0.1:80 访问我的程序
此时我要升级我的程序了,我在127.0.0.1:91上运行了我的新程序
现在 90 和 91 端口分别运行了老程序和新程序
修改Nginx的配置文件
upstream myapp1 { #server 127.0.0.1:90; server 127.0.0.1:91; }
然后执行 nginx -s reload 重新加载配置文件(注意:不要重启nginx)
现在是什么情况呢?
现在新进来的连接会被分配到新程序,连接着老程序的用户不会被断开而是等待处理结束后主动断开,
因为老程序并没有结束,只是新进来的连接被Nginx分配到新程序了
根据情况适当等一段时间就可以手动把老程序结束了
细心的你可能发现 以前的老程序是90 端口,现在更新后新程序使用了91端口,
其实这个并不重要,因为用户始终访问的是Nginx,就是127.0.0.1:80
最后在说一下灰度发布,灰度发布通常来说应用于集群中
当前集群中有三台服务器
upstream myapp1 { server 127.0.0.1:90; server 127.0.0.1:91; server 127.0.0.1:92; }
当新程序发布时只需要在 upstream中加入新的程序地址,原有的不删除
upstream myapp1 { server 127.0.0.1:90; server 127.0.0.1:91; server 127.0.0.1:92; server 127.0.0.1:93; }
现在我们往集群中添加了一台运行新程序的服务器
这样就有一小部分用户会被分配到新程序,然后观察用户反馈,如果反馈良好,
就逐渐加入新程序替换掉老程序,最终全部换成了新程序
当然如果用户反馈不好,就把新程序撤下来,不会对业务产生大的影响