> В чем разница между Uvicorn и Gunicorn (Python)

Короткий ответ

Uvicorn - это ASGI-сервер, реализованный на uvloop и httptools, предназначенный для асинхронных фреймворков (FastAPI, Starlette). Gunicorn - зрелый WSGI-сервер с поддержкой синхронных worker'ов, изначально для Django/Flask. Ключевое различие - протокол: WSGI против ASGI. Gunicorn не поддерживает WebSocket и HTTP/2, Uvicorn - поддерживает. На практике их часто комбинируют: Gunicorn как process manager, Uvicorn как worker.

Подробное объяснение

Uvicorn - это реализация ASGI (Asynchronous Server Gateway Interface). Он использует uvloop (drop-in замену asyncio event loop) и httptools для парсинга HTTP. Работает в однопроцессном режиме, но поддерживает --workers для запуска нескольких процессов. Основные фичи: WebSocket, HTTP/2 (с дополнительными зависимостями), server-sent events, graceful shutdown.

Gunicorn - это WSGI-сервер, который существует с 2010 года. Он управляет worker-процессами: fork, мониторинг, перезапуск при падении. Поддерживает разные типы worker'ов: sync, gevent, eventlet, tornado. Для асинхронных приложений нужно явно указывать -k uvicorn.workers.UvicornWorker, иначе Gunicorn будет работать как синхронный сервер, что убивает всю пользу от async.

Архитектурное различие: Gunicorn - это process manager с HTTP-сервером, Uvicorn - это HTTP-сервер с asyncio. Gunicorn сам по себе не умеет в async, он делегирует это worker'у. Uvicorn из коробки асинхронный, но не умеет управлять несколькими процессами так же удобно, как Gunicorn (хотя --workers есть).

На практике

Для продакшена типичная связка: Gunicorn как front-line process manager, UvicornWorker как worker. Это даёт:

• надёжный рестарт при падении worker'а
• graceful reload при деплое
• управление количеством worker'ов через конфиг Gunicorn
• полную поддержку ASGI от Uvicorn

Если приложение маленькое или трафик низкий - достаточно одного Uvicorn с --workers 2. Если нужен максимальный контроль над процессами, сигналами, деплоем - берите Gunicorn + UvicornWorker.

Важный нюанс: Gunicorn с UvicornWorker не даёт преимущества в производительности по сравнению с чистым Uvicorn - накладные расходы на проксирование минимальны. Но даёт стабильность управления процессами.

Пример кода

BASH
# Простой запуск Uvicorn
uvicorn app.main:app --host 0.0.0.0 --port 8000 --workers 4

# Gunicorn с UvicornWorker
gunicorn app.main:app -w 4 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000

# Gunicorn для синхронного Flask
gunicorn app:app -w 4 --bind 0.0.0.0:8000

Как отвечать на собеседовании

Начните с протоколов: WSGI vs ASGI. Затем переходите к архитектуре: Gunicorn - process manager, Uvicorn - async HTTP-сервер. Подчеркните, что они не конкуренты, а дополняют друг друга. Упомяните, что выбор зависит от фреймворка: Django/Flask - Gunicorn, FastAPI/Starlette - Uvicorn или связка. Для senior-уровня добавьте рассуждение о trade-off: чистый Uvicorn проще, но Gunicorn даёт более зрелый механизм управления процессами, сигналами, деплоем. Если спросят про производительность - скажите, что разница минимальна, узкое место обычно в приложении, а не в сервере.

Что проверяет интервьюер

• Понимание разницы между WSGI и ASGI
• Знание экосистемы Python-серверов
• Умение выбирать инструмент под задачу
• Понимание архитектуры process management
• Осознание trade-off между простотой и контролем

Типичные ошибки

• Утверждение, что Uvicorn быстрее Gunicorn - это не всегда так, зависит от worker'а и нагрузки
• Запуск FastAPI на Gunicorn без UvicornWorker - приложение будет работать, но синхронно, и все преимущества async теряются
• Использование Uvicorn для Django - Django не поддерживает ASGI нативно (только через ASGI-адаптер, и это не даёт выигрыша)
• Забывают, что Gunicorn не поддерживает WebSocket без специального worker'а
• Путают --workers в Uvicorn с полноценным process management - Uvicorn не умеет graceful reload так же хорошо, как Gunicorn