golang 服务平滑重启小结

2023-03-07 14:13:48 浏览数 (1)

背景

  • golang 程序平滑重启框架
  • supervisor 场景的 defunct 问题
  • 使用 master/worker 模式

背景

在业务快速增长中，前期只是验证模式是否可行，期间会忽略程序发布过程中因短暂停服引发的服务不可用。当模式实验成熟之后会逐渐放量，放量后进行停机发布造成的影响就会大很多。我们整个服务都是基于云，请求流量从 四层->七层->机器。

要想实现平滑重启大致有三种方案： 第一种是在流量调度的入口处理，一般的做法是ApiGateway CD，即在发布的过程中，当新服务部署完成后，就将新进来的流量路由到新服务，并下线掉没有流量的老服务，仍有流量没有处理完成的老服务，需要等处理完成后再停服。这样的好处就是程序不需要关心如何做平滑重启。

第二种就是程序自己完成平滑重启，保证在重启的时候 listen socket FD（文件描述符） 依然可以接受请求进来，只不过切换新老进程，但是这个方案需要程序自己去完成，有些技术栈可能实现起来不是很简单，有些语言无法控制到操作系统级别，实现起来会很麻烦。

第三种方案就是完全 docker，所有的东西都交给 k8s 统一管理。我们正在小规模接入中。

golang 程序平滑重启框架

与 java、net 等基于虚拟机的语言不同，golang 天然支持系统级别的调用，平滑重启处理起来很容易。从原理上讲，基于 linux fork 子进程的方式，启动新的代码，再切换 listen socket FD，原理固然不难，但是完全自己实现还是会有很多细节问题的。好在有比较成熟的开源库帮我们实现了。

graceful https://github.com/tylerb/graceful endless https://github.com/fvbock/endless

上面两个是 github 排名靠前的 web host 框架，都是支持平滑重启的，只不过接受的进程信号有点区别 endless 接受 signal HUP，graceful 接受 signal USR2 。graceful 比较纯粹的 web host，endless 支持一些 routing 的能力。

我们看下 endless 处理信号。（如果对 srv.fork() 内部感兴趣可以品读品读。）

代码语言：javascript复制
  1. func (srv *endlessServer) handleSignals(){
  2. var sig os.Signal
  4. signal.Notify(
  5. srv.sigChan,
  6. hookableSignals...,
  7. )
  9. pid := syscall.Getpid()
  10. for{
  11. sig =<-srv.sigChan
  12. srv.signalHooks(PRE_SIGNAL, sig)
  13. switch sig {
  14. case syscall.SIGHUP:
  15. log.Println(pid,"Received SIGHUP. forking.")
  16. err := srv.fork()
  17. if err !=nil{
  18. log.Println("Fork err:", err)
  19. }
  20. case syscall.SIGUSR1:
  21. log.Println(pid,"Received SIGUSR1.")
  22. case syscall.SIGUSR2:
  23. log.Println(pid,"Received SIGUSR2.")
  24. srv.hammerTime(0* time.Second)
  25. case syscall.SIGINT:
  26. log.Println(pid,"Received SIGINT.")
  27. srv.shutdown()
  28. case syscall.SIGTERM:
  29. log.Println(pid,"Received SIGTERM.")
  30. srv.shutdown()
  31. case syscall.SIGTSTP:
  32. log.Println(pid,"Received SIGTSTP.")
  33. default:
  34. log.Printf("Received %v: nothing i care about...n", sig)
  35. }
  36. srv.signalHooks(POST_SIGNAL, sig)
  37. }
  38. }

supervisor 场景的defunct问题

使用 supervisor 管理的进程，中间需要加一层代理，原因就是 supervisor 可以管理自己启动的进程，意思就是 supervisor 可以拿到自己启动的进程id（PID），可以检测进程是否还存活，crash后做自动拉起，退出时能接收到进程退出信号。

但是如果我们用了平滑重启框架，原来被 supervisor 启动的进程发布重启 fork子进程之后正常退出，当再次发布重启 fork 的子进程就会变成没有主进程，那么，此子进程就无法完成正常退出。这样， defunct(僵尸进程) 问题就出现了。这个子进程无法完成退出的原因是没有接受子进程退出信号的主进程。同时，退出进程本身在defunct进程中的少量数据结构也无法销毁【内存泄露】。

使用 master/worker 模式

supervisor 本身提供了 pidproxy 程序，我们在配置 supervisor command 时使用 pidproxy 来做一层代理。由于进程的id会随着不停的发布 fork 子进程而变化，所以需要将程序的每次启动 PID 保存在一个文件中，一般大型分布式软件【mysql、zookeeper 等】都需要这样的一个文件，目的就是为了拿到目标进程id。

这其实是一种 master/worker 模式，master 进程交给 supervisor 管理，supervisor 启动 master 进程，也就是 pidproxy 程序，再由 pidproxy 来启动我们的目标程序，随便我们目标程序 fork 多少次子进程都不会影响 pidproxy master 进程。

pidproxy 依赖 PID 文件，我们需要保证程序每次启动的时候都要将当前进程 id 写入PID 文件，这样 pidproxy 才能工作。 supervisor 默认的 pidproxy 文件是不能直接使用的，我们需要适当的修改。

https://github.com/Supervisor/supervisor/blob/master/supervisor/pidproxy.py

代码语言：javascript复制
  1. #!/usr/bin/env python
  3. """ An executable which proxies for a subprocess; upon a signal, it sends that
  4. signal to the process identified by a pidfile. """
  6. import os
  7. import sys
  8. import signal
  9. import time
  11. classPidProxy:
  12. pid =None
  13. def __init__(self, args):
  14. self.setsignals()
  15. try:
  16. self.pidfile, cmdargs = args[1], args[2:]
  17. self.command = os.path.abspath(cmdargs[0])
  18. self.cmdargs = cmdargs
  19. except(ValueError,IndexError):
  20. self.usage()
  21. sys.exit(1)
  23. def go(self):
  24. self.pid = os.spawnv(os.P_NOWAIT,self.command,self.cmdargs)
  25. while1:
  26. time.sleep(5)
  27. try:
  28. pid = os.waitpid(-1, os.WNOHANG)[0]
  29. exceptOSError:
  30. pid =None
  31. if pid:
  32. break
  34. def usage(self):
  35. print("pidproxy.py <pidfile name> <command> [<cmdarg1> ...]")
  37. def setsignals(self):
  38. signal.signal(signal.SIGTERM,self.passtochild)
  39. signal.signal(signal.SIGHUP,self.passtochild)
  40. signal.signal(signal.SIGINT,self.passtochild)
  41. signal.signal(signal.SIGUSR1,self.passtochild)
  42. signal.signal(signal.SIGUSR2,self.passtochild)
  43. signal.signal(signal.SIGQUIT,self.passtochild)
  44. signal.signal(signal.SIGCHLD,self.reap)
  46. def reap(self, sig, frame):
  47. # do nothing, we reap our child synchronously
  48. pass
  50. def passtochild(self, sig, frame):
  51. try:
  52. with open(self.pidfile,'r')as f:
  53. pid =int(f.read().strip())
  54. except:
  55. print("Can't read child pidfile %s!"%self.pidfile)
  56. return
  57. os.kill(pid, sig)
  58. if sig in[signal.SIGTERM, signal.SIGINT, signal.SIGQUIT]:
  59. sys.exit(0)
  61. def main():
  62. pp =PidProxy(sys.argv)
  63. pp.go()
  65. if __name__ =='__main__':
  66. main()

我们重点看下这个方法：

代码语言：javascript复制
  1. def go(self):
  2. self.pid = os.spawnv(os.P_NOWAIT,self.command,self.cmdargs)
  3. while1:
  4. time.sleep(5)
  5. try:
  6. pid = os.waitpid(-1, os.WNOHANG)[0]
  7. exceptOSError:
  8. pid =None
  9. if pid:
  10. break

go 方法是守护方法，会拿到启动进程的id，然后做 waitpid ，但是当我们 fork 进程的时候主进程会退出，os.waitpid 会收到退出信号，然后就退出了，但是这是个正常的切换逻辑。

可以使用两个办法解决，第一个就是让 go 方法纯粹是个守护进程，去掉退出逻辑，在信号处理方法中处理：

代码语言：javascript复制
  1. def passtochild(self, sig, frame):
  2. pid =self.getPid()
  3. os.kill(pid, sig)
  4. time.sleep(5)
  5. try:
  6. pid = os.waitpid(self.pid, os.WNOHANG)[0]
  7. exceptOSError:
  8. print("wait pid null pid %s",self.pid)
  9. print("pid shutdown.%s", pid)
  10. self.pid =self.getPid()
  12. ifself.pid ==0:
  13. sys.exit(0)
  15. if sig in[signal.SIGTERM, signal.SIGINT, signal.SIGQUIT]:
  16. print("exit:%s", sig)
  17. sys.exit(0)

还有一个方法就是修改原有go方法：

代码语言：javascript复制
  1. def go(self):
  2. self.pid = os.spawnv(os.P_NOWAIT,self.command,self.cmdargs)
  3. while1:
  4. time.sleep(5)
  5. try:
  6. pid = os.waitpid(-1, os.WNOHANG)[0]
  7. exceptOSError:
  8. pid =None
  9. try:
  10. with open(self.pidfile,'r')as f:
  11. pid =int(f.read().strip())
  12. except:
  13. print("Can't read child pidfile %s!"%self.pidfile)
  14. try:
  15. os.kill(pid,0)
  16. exceptOSError:
  17. sys.exit(0)

当然还可以用其他方法或者思路，这里只是抛出问题。如果你想知道真正问题在哪里，可以直接在本地 debug pidproxy 脚本文件，还是比较有意思的，知道真正问题在哪里如何修改，就完全由你来发挥了。

unix linux

0 人点赞