### 从日常运维到生产部署Python世界里那个叫Gunicorn的“管家”先聊聊Gunicorn是什么。简单说它是一个WSGI HTTP服务器专门用来跑Python写的Web应用。WSGI这东西说白了就是Python Web世界里一个约定好的规矩——一个接口标准规定了你的应用和服务器之间怎么握手、怎么传递请求和响应。Gunicorn就是遵从这个规矩的一个守门人你的Flask、Django、Pyramid写的应用就像是一个个勤奋的工人而Gunicorn负责站在门口接活、分派任务给工人再把结果原封不动送回给客户浏览器。很多人会问为什么我的Flask应用开发时直接跑起来就能用生产环境非要套个Gunicorn这就像你平时一个人在家做饭随便开个灶就能搞定。但突然有一天你要开个大型晚宴来一百个客人这时候你一个人同时炒菜、端菜、洗碗肯定不行。你需要一个厨师长Gunicorn来指挥厨房几个厨师负责炒菜几个临时工负责传菜还有一个专门管排队。Flask自带的服务器是单线程、同步的一台机器只要来几个并发请求就会像一个人同时接三个电话忙不过来。Gunicorn能启动多个工作进程workers每个进程独立处理请求相当于多开了几条流水线。不止是“跑起来”Gunicorn能干哪些事最核心的两个本事并发处理和生产级别的稳固。你可以通过设定worker数量来控制你的服务器同时能接多少活。比如在八核的机器上你通常会设置2-4个worker经验公式是2*CPU核数1每个worker又是一个独立进程这比Flask自带的单线程强太多了。而且Gunicorn有自动重启机制某个worker因为特殊原因挂了主进程会立刻新开一个补上。你的应用如果写了个死循环或者内存泄露最多挂掉一个worker整个服务不会崩溃。还有一个常用功能是通过Unix socket来绑定监听这样可以用Nginx在前面做反向代理。比如生产环境里你会在Nginx里写proxy_pass http://unix:/tmp/gunicorn.socket让Nginx处理静态文件和负载均衡把动态请求丢给Gunicorn。这种组合就像餐厅门口的迎宾Nginx负责拦客、带位、发号后厨Gunicorn只管专心炒菜。另外Gunicorn支持不同的worker类型除了默认的同步worker还有异步worker用gevent或eventlet。当你的应用主要做I/O操作比如数据库查询、请求外部API时异步worker可以用很少的线程数管理很多并发连接。配合gevent使用你的应用处理几百个慢请求也不会阻塞。上手怎么用最简单的几个例子安装很简单pip install gunicorn。但要注意它只在Linux和macOS上良好运行Windows下只能靠WSL。启动你的Flask应用假设应用对象叫app在myapp.py里gunicorn myapp:app -b 0.0.0.0:8000 -w 4-b指定绑定的地址和端口-w是工作进程数量。更常用的做法在项目根目录创建一个gunicorn.conf.py配置文件把所有参数写进去。比如# content of gunicorn.conf.pybind0.0.0.0:8000workers4timeout60worker_classgeventloglevelinfoaccesslog./logs/access.logerrorlog./logs/error.log然后直接执行gunicorn myapp:app -c gunicorn.conf.py。这样调试和部署都方便。一个新手容易踩的坑gunicorn启动时默认只会在主进程里加载一次你的应用代码。如果你改了代码需要手动重启gunicorn。但配合--reload参数可以在开发环境自动监听文件变化并重载。生产环境别开这个影响性能。那些你可能不知道的最佳实践第一不要按CPU核心数无脑设太多workers。如果你的应用每个请求都要读写数据库过多的worker反而会竞争数据库连接池导致整体吞吐量下降。我会先设成2×CPU核数12\times \text{CPU核数}12×CPU核数1然后通过压测工具比如wrk、ab逐步往上调找到最优值。另外每个worker默认会分配一个Python进程内存开销不小。比如你一个worker占150MB内存4个worker就是600MB所以要根据可用内存量力而行。第二关于超时参数默认的timeout30秒。如果某个请求处理时间很长比如上传大文件要适当加长或者改用异步worker。但别随便调到比如300秒这会让你某个worker长时间被占用其他请求等着排队。更好的做法是在应用层做异步优化比如用celery处理延迟任务让worker快速返回。第三搭配supervisor或systemd来管理Gunicorn进程。这样如果意外挂了系统能自动拉起。常见的做法是写一个systemd unit文件里面指定gunicorn的命令行和配置。然后systemctl enable gunicorn让它随机器启动。这也方便你看日志和重启。第四日志管理。Gunicorn默认会输出到stdout生产环境最好让配置里指定日志文件路径。再配合logrotate定期切割防止日志撑爆磁盘。如果用了Nginx可以在Nginx日志里看到客户端IP、请求路径等Gunicorn的access log记录得更详细一些比如worker PID利于排查问题。同类技术对比当你的技术选型遇到其他选择Python世界里能和Gunicorn平起平坐的同类工具有uWSGI、Waitress、ASGI服务器Uvicorn、Daphne等。先谈谈uWSGI。它功能极其强大除了跑Python应用还能做缓存、定时任务、甚至直接当反向代理。但缺点是配置选项太多像瑞士军刀很多功能日常用不到。而且uWSGI的默认行为有时候会有“惊喜”比如多个worker共享一个内存偶尔由于引用计数问题出现古怪的bug。相比之下Gunicorn的设计哲学偏简洁务实对新手友好文档清晰社区活跃。如果你不需要太多高级功能Gunicorn是更好的选择。Waitress是纯Python实现的没有C扩展好处是跨平台Windows下直接跑无压力。性能上它不如Gunicorn因为Gunicorn底层用了C写的prefork模型但对于中小型项目完全够用。而且Waitress的并发模型是用多线程而非多进程每个worker是一个线程这样内存占用比较低。如果你的应用是I/O密集且线程安全可以考虑。ASGI服务器UvicornDaphne是随着FastAPI、Starlette等异步框架兴起出现的。它们支持异步协程能更好地处理WebSocket、长连接等场景。假如你写的是异步Python应用Gunicorn也支持搭配Uvicorn使用——把worker_class设为uvicorn或uvicorn.workers.UvicornWorker这样既可以享受Gunicorn的进程管理又能利用Uvicorn的异步能力。这种组合现在很常见。最后说个冷门对比Apache的mod_wsgi。这玩意儿把Python解释器和Apache进程深度绑定配置更加繁琐调试困难。如果团队里没有专门运维Apache还是别碰这个。GunicornNginx的组合在大部分场景下更灵活也更好维护。归根结底Gunicorn是经过时间考验的老牌工具不会背叛你。它不追求最新最炫的技术但在正确的场景下它就是那个在你服务器后厨默默干活、极少出岔子的好帮手。