Python 应用部署：gunicorn 加 systemd 托管

gunicorn（Python 的 WSGI 应用服务器）负责把应用跑起来，systemd（Linux 的服务管理器）负责让它常驻并在崩溃后自动拉起，两者搭配是 Linux 服务器上部署 Python 应用的常规做法。链路不复杂，容易出问题的是参数和路径。 一、准备虚拟环境 给应用单独建虚拟环境，避免依赖打架： python3 -m venv /opt/myapp/venv /opt/myapp/venv/bin/pip install gunicorn 依赖清单跟着项目走，重装环境时按清单一条命令装齐。后续命令建议一律使用虚拟环境内的绝对路径，写进 systemd 配置后尤其如此。虚拟环境跟着应用目录走，备份或迁移时整体打包，恢复最省事。 二、估算 worker 数量 worker 是 gunicorn 里独立处理请求的进程，数量参考经验公式 2×CPU 核数+1，两核机器先设 5 个。启动命令： gunicorn -w 5 -b 127.0.0.1:8000 app:app 接口多为 IO 等待（查库、调外部接口）时，在启动参数里加 -k gthread 和 --threads 改用线程模式，一个进程里服务更多并发，也更省内存。worker 数没有标准答案，先按公式起步，跑起来后看内存占用和响应时间再调，比空想准。worker 不是越多越好，压测时看每个进程的内存，乘以数量接近机器内存的六成就到顶了，4G 内存的机器一般不超过 8 个。 三、编写 systemd unit 文件 新建 /etc/systemd/system/myapp.service： [Service] User=www WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/venv/bin/gunicorn -w 5 -b 127.0.0.1:8000 app:app Restart=always [Install] WantedBy=multi-user.target 这套组合的好处是分层清晰：应用崩了 gunicorn 拉起，进程没了 systemd 兜底，日常运维只面对 systemctl 和 journalctl 两样工具。User 建议用非 root 的专用账号；WorkingDirectory 必须是项目根目录，应用里的相对路径都基于它解析。改完配置用 systemctl cat myapp 核对生效的完整内容，排查路径问题时比翻文件快。 四、验证与常见问题 执行 systemctl daemon-reload && systemctl enable --now myapp，再用 systemctl status myapp 和 journalctl -u myapp -f 查看状态与实时日志。最常见的启动失败是 ExecStart 里虚拟环境路径写错，报 No such file or directory，用 ls 核对路径即可。升级代码的标准动作是 systemctl restart myapp，配合 Restart=always，发布窗口出问题也能自动恢复。端口只监听 127.0.0.1，对外由 nginx 反向代理，这是更安全的姿势；以后要多实例，复制一份 unit 文件改端口就行，起步阶段不必引入更复杂的部署形态。