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

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

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

選型與實(shí)踐

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

• facebookgo/grace
• fvbock/endless
• jpillora/overseer

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

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

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

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

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

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

supervisor的問題

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

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

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

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

還是使用上面的測(cè)試方式：

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

其他的問題

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

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

導(dǎo)致這樣的原因是：overseer在啟動(dòng)子進(jìn)程時(shí)是使用和主進(jìn)程一樣的啟動(dòng)命令。所以main函數(shù)會(huì)執(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)容來解決這個(gè)問題：

• 將之前所有的初始化內(nèi)容集成在initialization函數(shù)中
• 將http初始化的內(nèi)容集成在httpServer函數(shù)中，返回一個(gè)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,
 }

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

// 初始化日志、數(shù)據(jù)庫鏈接、定時(shí)任務(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ù)，但不啟動(dòng)
func httpServer() *http.Server {
 server := microsvr.NewHTTPServer()
 server.SetAllowOrginBack()
 Routers(server)
 return server
}

實(shí)踐對(duì)比結(jié)果：

• grace與endless：舊的api都不會(huì)斷掉，會(huì)執(zhí)行原來的邏輯，但pid會(huì)變化；不支持supervisor管理
• overseer：舊api不會(huì)斷掉，會(huì)執(zhí)行原來的邏輯，主進(jìn)程pid也不會(huì)變化，支持supervisor、systemd等管理

grace與endless的原理比較相像，都是類似上述的一般思路的實(shí)現(xiàn)原理。overseer的不同，主要有兩點(diǎn)：

• 添加了fetcher：用來支持自動(dòng)升級(jí)bin文件，fetcher運(yùn)行在一個(gè)goroutine中，通過預(yù)先設(shè)置好的間隔時(shí)間來檢查bin文件；支持File、Github、S3的方式
• 添加了主進(jìn)程管理平滑重啟：子進(jìn)程處理鏈接，能夠保持主進(jìn)程pid不變

我們使用了overseer作為最終的選型結(jié)果。

總結(jié)

到此這篇關(guān)于Golang HTTP 服務(wù)平滑重啟及升級(jí)的思路的文章就介紹到這了,更多相關(guān)golang http 平滑重啟內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！