快捷導(dǎo)航

Golang HTTP 服務(wù)平滑重啟及升級的思路

更新時間：2020年04月03日 09:31:28 作者：溫旭峰

Golang HTTP服務(wù)在上線時，需要重新編譯可執(zhí)行文件，關(guān)閉正在運行的進(jìn)程，然后再啟動新的運行進(jìn)程。這篇文章主要介紹了Golang HTTP 服務(wù)平滑重啟及升級,需要的朋友可以參考下

Golang HTTP服務(wù)在上線時，需要重新編譯可執(zhí)行文件，關(guān)閉正在運行的進(jìn)程，然后再啟動新的運行進(jìn)程。對于訪問頻率比較高的面向終端用戶的產(chǎn)品，關(guān)閉、重啟的過程中會出現(xiàn)無法訪問（nginx表現(xiàn)為502）的情況，影響終端用戶的使用體驗。

實現(xiàn)的一般思路

一般情況下，要實現(xiàn)平滑重啟或升級，需要執(zhí)行以下幾個步驟：
發(fā)布新的bin文件覆蓋老的bin文件
發(fā)送一個信號量(USR2)，告訴正在運行的進(jìn)程，進(jìn)行重啟
正在運行的進(jìn)程接受到信號后，以子進(jìn)程的方式啟動新的bin文件
新進(jìn)程接收并處理新的請求
老進(jìn)程不再接收新請求，等待所有正在處理的請求處理完成后自動退出
新進(jìn)程在老進(jìn)程退出后，繼續(xù)提供服務(wù)

選型與實踐

重復(fù)造平滑重啟及升級的輪子比較簡單，但測試覆蓋無法控制，比較耗時耗力。所以秉著不重復(fù)造輪子的思路，使用github中的三方庫進(jìn)行選擇：

facebookgo/grace
fvbock/endless
jpillora/overseer

endless與grace的實現(xiàn)方式原理都比較類似，所以在選型初期我們以facebookgo/grace庫為例集成到項目中進(jìn)行測試：

func (h *Server) ListenAndServe(listenAddress string) error {
 // ....
 return gracehttp.Serve(&http.Server{
 Addr: listenAddress,
 Handler: h.httpServerMux,
 })
}

使用ab工具壓測 api-publish服務(wù)進(jìn)行測試，服務(wù)啟動后，執(zhí)行以下命令：

ab -c 10 -n 2000 http://127.0.0.1:38272/api/list

然后給進(jìn)程發(fā)送USR2信號 kill -USR2 api-server-pid，可看到以下結(jié)果：

結(jié)果中 Failed requests表示在整個壓測請求中沒有錯誤的請求，這可以說明服務(wù)重啟時沒有中斷請求的接收和處理。如果使用sleep的方式測試，可以明顯的看到新進(jìn)程替代老進(jìn)程的過程。

supervisor的問題

實際項目中，線上服務(wù)是被supervisor啟動的。如上所說的我們?nèi)绻ㄟ^grace或者endless的子進(jìn)程啟動后退出父進(jìn)程這種方式的話，存在的問題就是子進(jìn)程會被1號進(jìn)程接管，導(dǎo)致supervisor認(rèn)為服務(wù)掛掉重啟服務(wù)，為了避免這種問題我們需要使用master-worker的方式。

overseer這個備選庫實現(xiàn)了master-worker的方式。簡單集成方式：

return overseer.RunErr(overseer.Config{
 Address: address,
 Program: func(state overseer.State) {
 // ...
 http.Serve(state.Listener, nil)
 },
})

另外：在更新supervisor時，配置不需要更新，但重啟服務(wù)的命令不能使用supervisor restart，需要使用supervisor signal sigusr2 api的命令。

還是使用上面的測試方式：

可以明顯的看到，supervisor發(fā)送了USR2信號后，主進(jìn)程的pid沒有變化，重新啟動了一個新的子進(jìn)程來處理線上請求。

其他的問題

在使用overseer集成到項目中測試時，子進(jìn)程的運行函數(shù)中僅僅加入了http服務(wù)的啟動，這樣導(dǎo)致一個問題。

main函數(shù)中任務(wù)會被執(zhí)行兩次，如果是cron的初始化，那么cron就會初始化兩次，導(dǎo)致有兩個cron在執(zhí)行，這樣的方式是不符合預(yù)期的。

導(dǎo)致這樣的原因是：overseer在啟動子進(jìn)程時是使用和主進(jìn)程一樣的啟動命令。所以main函數(shù)會執(zhí)行兩次。

func (mp *master) fork() error {
 mp.debugf("starting %s", mp.binPath)
 cmd := exec.Command(mp.binPath)
 //mark this new process as the "active" slave process.
 //this process is assumed to be holding the socket files.
 mp.slaveCmd = cmd
 mp.slaveID++
 //provide the slave process with some state
 e := os.Environ()
 e = append(e, envBinID+"="+hex.EncodeToString(mp.binHash))
 e = append(e, envBinPath+"="+mp.binPath)
 e = append(e, envSlaveID+"="+strconv.Itoa(mp.slaveID))
 e = append(e, envIsSlave+"=1")
 e = append(e, envNumFDs+"="+strconv.Itoa(len(mp.slaveExtraFiles)))
 cmd.Env = e
 //inherit master args/stdfiles
 cmd.Args = os.Args
 cmd.Stdin = os.Stdin
 cmd.Stdout = os.Stdout
 cmd.Stderr = os.Stderr
 //include socket files
 cmd.ExtraFiles = mp.slaveExtraFiles
 if err := cmd.Start(); err != nil {
 return fmt.Errorf("Failed to start slave process: %s", err)
 }
 // ...
}

我們通過調(diào)整main函數(shù)的內(nèi)容來解決這個問題：

將之前所有的初始化內(nèi)容集成在initialization函數(shù)中
將http初始化的內(nèi)容集成在httpServer函數(shù)中，返回一個http.Server

func main() {
 // 配置初始化
 if err := config.Init(appConf); err != nil {
 fmt.Println(err)
 return
 }
 cfg := config.GetConfig()

 // 初始化graceful http服務(wù)
 gracefulHTTPServer := microsvr.GracefulHTTPServer{
 Address: cfg.HTTPListenAddress,
 Conf:  cfg,
 Initialization: initialization,
 HttpServer: httpServer,
 }

 // 啟動
 if err := gracefulHTTPServer.Run(); err != nil {
 fmt.Println(err)
 return
 }
}

// 初始化日志、數(shù)據(jù)庫鏈接、定時任務(wù)等
func initialization(cfg *config.Conf) {
 if err := microsvr.Init(cfg); err != nil {
 fmt.Println(err)
 return
 }

 if err := server.AddConnect(cfg.Databases.String()); err != nil {
 fmt.Println(err)
 return
 }
 logger.Info("數(shù)據(jù)庫鏈接成功：" + cfg.Databases.Address)
 // cron
 cron.Cron.Init()
}

// 初始化http服務(wù)，但不啟動
func httpServer() *http.Server {
 server := microsvr.NewHTTPServer()
 server.SetAllowOrginBack()
 Routers(server)
 return server
}

實踐對比結(jié)果：