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的方式。簡單整合方式：

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

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

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

可以明顯的看到，supervisor傳送了USR2訊號後，主程序的pid沒有變化，重新啟動了一個新的子程序來處理線上請求。

其他的問題

在使用overseer整合到專案中測試時，子程序的執行函式中僅僅加入了http服務的啟動，這樣導致一個問題。

main函式中任務會被執行兩次，如果是cron的初始化，那麼cron就會初始化兩次，導致有兩個cron在執行，這樣的方式是不符合預期的。

導致這樣的原因是：overseer在啟動子程序時是使用和主程序一樣的啟動命令。所以main函式會執行兩次。

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)
 }
 // ...
}

我們通過調整main函式的內容來解決這個問題：

• 將之前所有的初始化內容整合在initialization函式中
• 將http初始化的內容整合在httpServer函式中，返回一個http.Server

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

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

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

// 初始化日誌、資料庫連結、定時任務等
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("資料庫連結成功：" + cfg.Databases.Address)
 // cron
 cron.Cron.Init()
}

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

實踐對比結果：

• grace與endless：舊的api都不會斷掉，會執行原來的邏輯，但pid會變化；不支援supervisor管理
• overseer：舊api不會斷掉，會執行原來的邏輯，主程序pid也不會變化，支援supervisor、systemd等管理

grace與endless的原理比較相像，都是類似上述的一般思路的實現原理。overseer的不同，主要有兩點：

• 添加了fetcher：用來支援自動升級bin檔案，fetcher執行在一個goroutine中，通過預先設定好的間隔時間來檢查bin檔案；支援File、Github、S3的方式
• 添加了主程序管理平滑重啟：子程序處理連結，能夠保持主程序pid不變

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

總結

到此這篇關於Golang HTTP 服務平滑重啟及升級的思路的文章就介紹到這了,更多相關golang http 平滑重啟內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！