Gunicorn是Python Web应用的生产级WSGI服务器，需配合Nginx反向代理、Docker容器化及健康监控构成完整部署方案。
用Gunicorn作为Python应用的WSGI服务器
Gunicorn是为Python Web应用（如Flask、Django）设计的生产级WSGI HTTP服务器，它通过预加载、多进程和异步worker模型提升并发处理能力。不建议直接用开发服务器（如Flask的run()或Django的runserver）对外提供服务——它们未针对高负载、安全性和稳定性做优化。
启动时推荐显式指定关键参数：
-
--bind：绑定地址，例如
0.0.0.0:8000或 Unix socket（/tmp/gunicorn.sock），后者配合Nginx更高效； -
--workers：通常设为
2 × CPU核心数 + 1，避免过多进程争抢资源； -
--worker-class：CPU密集型选
sync，I/O密集型可尝试gevent或eventlet（需额外安装）； -
--timeout 和 --keep-alive：防止长连接阻塞，建议设为
30秒超时、5秒保活； - --access-logfile 和 --error-logfile：明确日志路径，便于监控与排查。
用Nginx反向代理并承担静态文件与负载分发
Nginx不直接运行Python代码，而是作为反向代理层，负责接收客户端请求、转发给Gunicorn，并处理SSL终止、静态资源服务、限流、缓存和连接复用等任务。这种分离让各组件专注所长，也提升了整体健壮性。
典型Nginx配置要点：
立即学习“Python免费学习笔记（深入）”；
- 用
upstream块定义Gunicorn后端（支持多个worker或实例，便于横向扩展）； - 在
server块中启用proxy_pass指向 upstream，同时设置proxy_set_header传递真实IP、协议等关键头信息（如X-Forwarded-For,X-Forwarded-Proto）； - 对
/static/或/media/路径使用alias或root直接由Nginx服务，避免请求穿透到Python层； - 启用
client_max_body_size（如10M）以支持文件上传； - 配置
ssl_certificate和ssl_certificate_key实现HTTPS，推荐使用Let’s Encrypt自动续签。
容器化部署：Docker + 多阶段构建 + 标准化入口
Docker让Python应用具备环境一致性与可移植性。推荐采用多阶段构建（multi-stage build）减小镜像体积：第一阶段用完整Python环境安装依赖并编译（如C扩展），第二阶段仅复制编译产物和源码到精简的基础镜像（如 python:3.11-slim）。
关键实践包括：
- Dockerfile中使用非root用户（
USER appuser）运行Gunicorn，降低安全风险； - 将Gunicorn启动命令写入
ENTRYPOINT或CMD，确保容器启动即服务就绪； - 通过环境变量（如
GUNICORN_CMD_ARGS）或配置文件（gunicorn.conf.py）管理Gunicorn参数，便于不同环境切换； - 挂载日志目录为volume，或将日志输出到
stdout/stderr，方便Docker日志驱动统一收集（如json-file、fluentd）； - 在docker-compose.yml中定义Nginx与Python应用为独立service，用自定义网络互通，Nginx暴露80/443端口，Python service仅对内网开放。
健康检查、监控与滚动更新准备
容器编排（如Kubernetes）或CI/CD流水线依赖可靠的健康检查机制。Gunicorn本身无内置HTTP健康端点，需在应用中添加简单路由（如 /healthz），返回200并检查数据库连接、缓存可用性等关键依赖。
监控方面建议：
- 用
gunicorn --stats或集成Prometheus exporter（如gunicorn-exporter）暴露worker数、请求数、响应延迟等指标； - Nginx启用
stub_status模块或使用nginx-prometheus-exporter； - 应用层记录结构化日志（如JSON格式），字段包含request_id、status、duration、user_agent等，便于ELK或Loki分析；
- 容器启动后等待Gunicorn ready（可通过curl探测
/healthz），再触发Nginx重载或服务注册； - 滚动更新时，先启新实例、健康检查通过后再停旧实例，避免请求中断。
