Golang HTTP 服务平滑重启及升级的思路服务平滑重启及升级的思路
Golang HTTP服务在上线时,需要重新编译可执行文件,关闭正在运行的进程,然后再启动新的运行进程。对于访问频率比
较高的面向终端用户的产品,关闭、重启的过程中会出现无法访问(nginx表现为502)的情况,影响终端用户的使用体验。
实现的一般思路实现的一般思路
一般情况下,要实现平滑重启或升级,需要执行以下几个步骤:
发布新的bin文件覆盖老的bin文件
发送一个信号量(USR2),告诉正在运行的进程,进行重启
正在运行的进程接受到信号后,以子进程的方式启动新的bin文件
新进程接收并处理新的请求
老进程不再接收新请求,等待所有正在处理的请求处理完成后自动退出
新进程在老进程退出后,继续提供服务
选型与实践选型与实践
重复造平滑重启及升级的轮子比较简单,但测试覆盖无法控制,比较耗时耗力。所以秉着不重复造轮子的思路,使用github中
的三方库进行选择:
facebookgo/grace
fvbock/endless
jpillora/overseer
endless与grace的实现方式原理都比较类似,所以在选型初期我们以facebookgo/grace库为例集成到项目中进行测试:
func (h *Server) ListenAndServe(listenAddress string) error {
// ....
return gracehttp.Serve(&http.Server{
Addr: listenAddress,
Handler: h.httpServerMux,
})
}
使用ab工具压测 api-publish服务进行测试,服务启动后,执行以下命令:
ab -c 10 -n 2000 http://127.0.0.1:38272/api/list
然后给进程发送USR2信号 kill -USR2 api-server-pid,可看到以下结果:
结果中 Failed requests表示在整个压测请求中没有错误的请求,这可以说明服务重启时没有中断请求的接收和处理。如果使用
sleep的方式测试,可以明显的看到新进程替代老进程的过程。
supervisor的问题的问题
实际项目中,线上服务是被supervisor启动的。如上所说的我们如果通过grace或者endless的子进程启动后退出父进程这种方
式的话,存在的问题就是子进程会被1号进程接管,导致supervisor认为服务挂掉重启服务,为了避免这种问题我们需要使用
master-worker的方式。
overseer这个备选库实现了master-worker的方式。简单集成方式: