版本发布中的痛点

我们采用的beego或gin等框架编写的web服务器，在发布新版本时会重启服务，短暂的服务重启对于后台类型的服务影响不大，但是对于api这种高可用的接口就会造成部分502，我们的adv和dass的QPS很高，重启一次就会造成几十到几百次访问失败，体验较差

行业解决方案

1. 类似 docker + k8s 等集群管理系统，体量太大，对于运维的要求比较高
2. 类似于php-fpm或者nginx的 master-slave方式，我们用的框架支持，需要开发
3. 类似于 graceful、endless等热启动框架，由于会启动一个新进程（新进程ID），与我们使用supervisor进程管理系统不兼容
4. 使用nginx或者负载均衡做反向代理动态切换

基于nginx做热切换

思路

1. 发布版本后，启动一个临时进程
2. 把nginx的反向代理指向临时进程，接管业务
3. 重启业务主进程
4. 把nginx的反向代理指向业务主进程
5. 完成一次版本上线

具体操作

1. 配置supervisor的ini文件，增加一个临时进程配置，例如 adv_api增加了一个adv_api_reload，注意环境变量增加了BEEGO_RELOAD=reload，用于启动进程时选择端口号
   
   2.配置nginx文件，增加一个临时进程的配置文件prod.nginx_reload.conf，里面配置的服务器是临时进程的 ip:port
   主进程nginx配置 prod.nginx.conf>临时进程nginx配置 prod.nginx_reload.conf
   
   临时进程nginx配置 prod.nginx_reload.conf
   
   3.增加一个临时进程的端口号，因为无法使用2个进程访问一个端口号，所以在prod.app.conf配置中增加了一行 httpportreload=端口号，启动时通过配置的环境变量BEEGO_RELOAD判断使用哪个端口号
   增加了httpportreload字段，prod.app.conf
   
   main函数中，增加了选择端口号逻辑
   

重启脚本修改，执行nginx切换逻辑