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中的三方庫(kù)進(jìn)行選擇：
- facebookgo/grace
- fvbock/endless
- jpillora/overseer
endless與grace的實(shí)現(xiàn)方式原理都比較類似，所以在選型初期我們以facebookgo/grace庫(kù)為例集成到項(xiàng)目中進(jìn)行測(cè)試：
|
1
2
3
4
5
6
7
|
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è)備選庫(kù)實(shí)現(xiàn)了master-worker的方式。簡(jiǎn)單集成方式：
|
1
2
3
4
5
6
7
|
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í)行兩次。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
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
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
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ù)庫(kù)鏈接、定時(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ù)庫(kù)鏈接成功：" + 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)搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！
原文鏈接：https://mp.weixin.qq.com/s/F-bmQcRwJEFcRhpWYEm-wg
