用 systemd 守护 Go 后端：从 nohup 到生产级服务管理

点餐小程序的 Go 后端最开始跑在华为云 Flexus L 上，我的启动方式很原始：nohup ./server > app.log 2>&1 &，断开 SSH 就不管了。看着能跑，实际上隐患一大堆：进程挂了没人拉起来，重启服务器后服务不会自启，日志越写越大没人轮转，改个配置要先 ps 找进程号再 kill。后来我把它改成 systemd 服务，花了不到半小时，换来的却是能安心睡觉的稳定性。

第一步是写一个 service 文件，放在 /etc/systemd/system/order.service。核心就几行：ExecStart 指向编译好的二进制文件和配置文件路径，WorkingDirectory 定到程序目录，Restart=always 让进程退出后自动拉起，RestartSec=5 给五秒缓冲，避免瞬间反复重启把 CPU 打满。User 专门建一个无登录权限的运行用户，不用 root 跑服务，这是最基本的安全底线。

第二步是处理启动顺序和依赖。后端依赖本地的数据库和 Redis，机器重启时如果服务先于数据库启动，连接失败就直接退出。解决办法是在 service 文件里写 After=network.target mysql.service redis.service，再加 Wants 做弱依赖声明。这样开机时 systemd 会等网络和数据库就绪再启动后端，避免了"重启后服务起不来，手动再起一次"的尴尬。

第三步是日志。nohup 时代的日志全堆在一个文件里，几个月就能吃掉几百兆磁盘。systemd 自带 journald，服务的所有标准输出都进日志系统，用 journalctl -u order.service -f 就能实时看，用 --since today 按时间过滤。更重要的是配 logrotate 或者 journald 的 SystemMaxUse 上限，给日志总量封顶，2Mbps 小带宽服务器的 40GB 磁盘经不起日志无限膨胀。

第四步是优雅停机。Go 程序收到 SIGTERM 后应该先停掉监听端口，等手头的请求处理完，再关闭数据库连接，最后退出。systemd 默认发 SIGTERM 后只等 90 秒，超时才 SIGKILL，所以程序里一定要实现信号处理：监听 os.Signal，收到后做清理再退出。点餐场景最怕的就是重启时正在下单的请求被直接掐断，优雅停机就是专门治这个的。

最后是日常运维的几个命令，记住四个就够：systemctl start/stop/restart order 控制服务，systemctl enable order 开机自启，systemctl status order 看运行状态和最近日志，journalctl -u order -n 100 查最近一百行。改配置的流程也固定下来：改配置文件 → systemctl daemon-reload（只在改了 service 文件本身时需要）→ systemctl restart order → systemctl status 确认活着。整个流程写进部署文档，半夜出问题照着走也不会慌。

从 nohup 到 systemd，本质上是把"人盯着进程"变成"系统管着进程"。小服务器最缺的就是人手，越是没人盯，越要把自启、自恢复、日志上限、优雅停机这些机制先搭好。服务管理看起来是运维琐事，但它是后端稳定性的最后一道防线。