一、先理解进程状态Linux 上每个运行中的程序都是进程。排查服务问题时先看进程是否存在、资源是否异常、打开文件和网络连接是否正常。常用工具包括ps、top、pgrep、lsof、ss和journalctl。命令用途ps aux查看进程列表top 或 htop观察 CPU 和内存pgrep -af name按名称找进程lsof -p PID查看打开文件ss -lntp查看监听端口遇到“服务不可用”不要立刻重启。先确认端口是否监听、进程是否频繁退出、日志是否有启动错误这些信息会在重启后被掩盖。二、用systemd托管服务现代 Linux 发行版普遍使用 systemd 管理服务。把应用交给 systemd可以获得开机自启、失败重启、日志收集、资源限制和统一管理命令。下面是一个简单的后端服务单元[Unit] DescriptionOrder API Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple WorkingDirectory/opt/order-api ExecStart/opt/order-api/order-api Restarton-failure RestartSec3 Userapp Groupapp EnvironmentAPP_ENVprod [Install] WantedBymulti-user.target保存到/etc/systemd/system/order-api.service后执行systemctl daemon-reload再启动并设置自启。三、日志与资源限制systemd 会接管标准输出和标准错误应用直接输出结构化日志即可通过journalctl查看。不要让服务把日志无限写到本地文件而无人轮转。systemctl start order-api systemctl status order-api journalctl-uorder-api-fjournalctl-uorder-api--since1 hour ago资源限制也应写进 service 文件避免单个进程耗尽机器资源。常用配置包括LimitNOFILE、MemoryMax、CPUQuota。高并发网络服务尤其要调整文件描述符上限。[Service] LimitNOFILE65535 MemoryMax1G CPUQuota200%四、优雅停止与排障服务发布和重启时应处理 SIGTERM完成正在进行的请求后退出。否则 systemd 超时后会强制杀进程可能造成请求中断或数据不一致。systemctl restart order-api systemctl show order-api-pMainPIDkill-TERM$(systemctl show-pMainPID--valueorder-api)排障顺序建议是看systemctl status获取退出码看journalctl找错误栈看ss确认端口看top判断资源瓶颈。systemd 不是简单的启动脚本替代品它是 Linux 服务运行的控制平面。把启动、日志、重启策略和资源边界都写清楚服务才更容易维护。还要注意权限和目录约定。应用进程不应使用 root 运行配置文件、数据目录和日志目录要明确属主。需要读取环境变量时可以使用EnvironmentFile但文件权限应限制在运维用户和服务用户范围内。定时任务也可以用 systemd timer 替代 crontab获得统一日志和失败状态。稳定的 Linux 服务管理靠的是进程边界、权限边界和可观察状态都足够清楚。发布脚本也应与 systemd 配合。部署新二进制前先停止或切走流量替换文件后再启动服务并检查状态和日志。若服务启动依赖数据库或消息队列After只能表达本机单元顺序不能保证远端依赖可用应用仍要实现重试和健康检查。对于经常变更的服务可以把版本目录和 current 软链接结合使用保留上一版本方便快速回退。所有这些约定都应写进运维文档并在新服务接入时复用同一模板。 本文是《服务部署与运维》系列持续更新关注不迷路。 下一篇《Nginx高并发调优worker与连接数配置》讲常驻服务前面的入口层如何匹配系统资源上限。 你在实际项目里遇到过服务进程退出后没有拉起或开机启动失败的问题吗评论区聊聊。觉得有用点个赞收藏方便回头查阅 相关可运行源码/资料已整理成资源包可在我主页的资源里自取。☁️ 本文示例需要一台云服务器新用户可通过此链接领取优惠自用https://cloud.tencent.com/act/cps/redirect?redirect2446cps_key49a769c067bd9c9f53fcb1bdf9feaf23fromconsolecps_promotion_id102832