[[404467]]

本文轉載自微信公眾號「微服務實踐」，作者hxl。轉載本文請聯系微服務實踐公眾號。   

在服務端程序更新或重啟時，如果我們直接 kill -9 殺掉舊進程并啟動新進程，會有以下幾個問題：

1. 舊的請求未處理完，如果服務端進程直接退出，會造成客戶端鏈接中斷(收到 RST)
2. 新請求打過來，服務還沒重啟完畢，造成 connection refused
3. 即使是要退出程序，直接 kill -9 仍然會讓正在處理的請求中斷

很直接的感受就是：在重啟過程中，會有一段時間不能給用戶提供正常服務;同時粗魯關閉服務，也可能會對業務依賴的數據庫等狀態服務造成污染。

所以我們服務重啟或者是重新發布過程中，要做到新舊服務無縫切換，同時可以保障變更服務 零宕機時間!

作為一個微服務框架，那 go-zero 是怎么幫開發者做到優雅退出的呢?下面我們一起看看。

優雅退出

在實現優雅重啟之前首先需要解決的一個問題是 如何優雅退出：

對 http 服務來說，一般的思路就是關閉對 fd 的 listen , 確保不會有新的請求進來的情況下處理完已經進入的請求, 然后退出。

go 原生中 http 中提供了 server.ShutDown()，先來看看它是怎么實現的：

1. 設置 inShutdown 標志
2. 關閉 listeners 保證不會有新請求進來
3. 等待所有活躍鏈接變成空閑狀態
4. 退出函數，結束

分別來解釋一下這幾個步驟的含義：

inShutdown

func (srv *Server) ListenAndServe() error { 
    if srv.shuttingDown() { 
        return ErrServerClosed 
    } 
    .... 
    // 實際監聽端口；生成一個 listener 
    ln, err := net.Listen("tcp", addr) 
    if err != nil { 
        return err 
    } 
    // 進行實際邏輯處理，并將該 listener 注入 
    return srv.Serve(tcpKeepAliveListener{ln.(*net.TCPListener)}) 
} 
 
func (s *Server) shuttingDown() bool { 
  return atomic.LoadInt32(&s.inShutdown) != 0 
} 

ListenAndServe 是http啟動服務器的必經函數，里面的第一句就是判斷 Server 是否被關閉了。

inShutdown 就是一個原子變量，非0表示被關閉。

listeners

func (srv *Server) Serve(l net.Listener) error { 
    ... 
    // 將注入的 listener 加入內部的 map 中 
    // 方便后續控制從該 listener 鏈接到的請求 
    if !srv.trackListener(&l, true) { 
        return ErrServerClosed 
    } 
    defer srv.trackListener(&l, false) 
   ... 
} 

Serve 中注冊到內部 listeners map 中 listener，在 ShutDown 中就可以直接從 listeners 中獲取到，然后執行 listener.Close()，TCP四次揮手后，新的請求就不會進入了。

closeIdleConns

簡單來說就是：將目前 Server 中記錄的活躍鏈接變成變成空閑狀態，返回。

關閉

func (srv *Server) Serve(l net.Listener) error { 
  ... 
  for { 
    rw, err := l.Accept() 
    // 此時 accept 會發生錯誤，因為前面已經將 listener close了 
    if err != nil { 
      select { 
      // 又是一個標志：doneChan 
      case <-srv.getDoneChan(): 
        return ErrServerClosed 
      default: 
      } 
    } 
  } 
} 

其中 getDoneChan 中已經在前面關閉 listener 時，對 doneChan 這個channel中push。

總結一下：Shutdown 可以優雅的終止服務，期間不會中斷已經活躍的鏈接。

但服務啟動后的某一時刻，程序如何知道服務被中斷了呢?服務被中斷時如何通知程序，然后調用Shutdown作處理呢?接下來看一下系統信號通知函數的作用

服務中斷

這個時候就要依賴 OS 本身提供的 signal。對應 go 原生來說，signal 的 Notify 提供系統信號通知的能力。

https://github.com/tal-tech/go-zero/blob/master/core/proc/signals.go

func init() { 
  go func() { 
    var profiler Stopper 
     
    signals := make(chan os.Signal, 1) 
    signal.Notify(signals, syscall.SIGUSR1, syscall.SIGUSR2, syscall.SIGTERM) 
 
    for { 
      v := <-signals 
      switch v { 
      case syscall.SIGUSR1: 
        dumpGoroutines() 
      case syscall.SIGUSR2: 
        if profiler == nil { 
          profiler = StartProfile() 
        } else { 
          profiler.Stop() 
          profiler = nil 
        } 
      case syscall.SIGTERM: 
        // 正在執行優雅關閉的地方 
        gracefulStop(signals) 
      default: 
        logx.Error("Got unregistered signal:", v) 
      } 
    } 
  }() 
} 

• SIGUSR1 -> 將 goroutine 狀況，dump下來，這個在做錯誤分析時還挺有用的
• SIGUSR2 -> 開啟/關閉所有指標監控，自行控制 profiling 時長
• SIGTERM -> 真正開啟 gracefulStop，優雅關閉

而 gracefulStop 的流程如下：

1. 取消監聽信號，畢竟要退出了，不需要重復監聽了
2. wrap up，關閉目前服務請求，以及資源
3. time.Sleep() ，等待資源處理完成，以后關閉完成
4. shutdown ，通知退出
5. 如果主goroutine還沒有退出，則主動發送 SIGKILL 退出進程

這樣，服務不再接受新的請求，服務活躍的請求等待處理完成，同時也等待資源關閉(數據庫連接等)，如有超時，強制退出。

整體流程

我們目前 go 程序都是在 docker 容器中運行，所以在服務發布過程中，k8s 會向容器發送一個 SIGTERM 信號，然后容器中程序接收到信號，開始執行 ShutDown：

到這里，整個優雅關閉的流程就梳理完畢了。

但是還有平滑重啟，這個就依賴 k8s 了，基本流程如下：

• old pod 未退出之前，先啟動 new pod
• old pod 繼續處理完已經接受的請求，并且不再接受新請求
• new pod接受并處理新請求的方式
• old pod 退出

這樣整個服務重啟就算是成功了，如果 new pod 沒有啟動成功，old pod 也可以提供服務，不會對目前線上的服務造成影響。

項目地址

https://github.com/tal-tech/go-zero

歡迎使用 go-zero 并 star 支持我們!