https://habr.com/post/426957/Данная статья является переводом статьи Кевина Голдберга «An Introduction to Python WSGI Servers: Part 1» blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 с небольшими дополнениями от переводчика
Краткая история серверов WSGI Python
WSGI-серверы появились потому, что веб-серверы в то время не умели взаимодействовать с приложениями, написанными на языке Python.
WSGI (
произносится как «whiz-gee» с твердым «g») был разработан Филиппом Дж. Эби (вместе с Ян Бикинг и др.) В начале 2000-х годов. Модуль Apache, известный как
mod_python, разработанный Григорием Трубецким в конце 90-х годов, на тот момент обрабатывал большую часть Python-приложений. Однако
mod_python не был официальной спецификацией. Он был просто создан, чтобы разработчики могли запускать код Python на сервере. К сожалению, такой подход был небезопасным и разработчики начали искать новое решение.
WSGI(Web-Server Gateway Interface) является потомком
CGI(Common Gateway Interface). Когда веб начал развиваться,
CGI разрастался из-за поддержки огромного количества языков и из-за отсутствия других решений. Однако, такое решение было медленным и ограниченным.
WSGI был разработан как интерфейс для маршрутизации запросов от веб-серверов(Apache, Nginx и т.д.) на веб-приложения.
Сервер и веб-приложение
В простейшем случае
WSGI состоит из двух основных сущностей:
- Веб-сервер (Nginx, Apache и т. д.);
- Веб-приложение, написанное на языке Python.
Принцип работы:
Веб-сервер исполняет код и отправляет связанную с http-запросом информацию и callback-функцию в веб-приложение. Затем запрос на стороне приложения обрабатывается и высылается ответ на веб-сервер.
Периодически между веб-сервером и веб-приложением существуют одна или несколько промежуточных прослоек. Такие прослойки позволяют осуществить, например балансировку между несколькими веб-приложениеми или предпроцессинг(предобработку) отдаваемого контента.
Вот примеры фреймворков, поддерживающих WSGI:
Почему именно WSGI?
Возможно Вы спросите
«Хорошо, но почему именно WSGI?». На это есть несколько причин:
- WSGI-сервера были разработаны чтобы обрабатывать множество запросов одновременно. А фреймворки не пердназначены для обработки тысяч запросов и не дают решения того, как наилучшим образом маршрутизировать их(запросы) с веб-сервера.
- WSGI ускоряет разработку веб-приложений написанных на языке Python. Если в разработке веб-приложения Вы используете фреймворк(Django или что-то ещё) вы не нужно как ваша конкретная инфраструктура использует стандарт WSGI.
- WSGI дает вам гибкость в изменении компонентов веб-стека без изменения приложения, которое работает с WSGI.
WSGI-серверы выпускаются в различных вариациях. Одни нацелены на fullstack-решение, в то время как другие хорошо подходят для конкретных фреймворков. Например,
Gunicorn работает с
Django прямо из коробки. Вот более пристальный взгляд на шесть WSGI-серверов на рынке сегодня:
Bjoern,
uWSGI,
mod_wsgi,
Meinheld,
CherryPy и
Gunicorn.
Bjoern
Bjoern — это асинхронный WSGI-сервер, написанный на C. Написанный с нуля, чтобы быть небольшим и быстрым, он был разработан с использованием
http_parser от Райана Даля (создателя Node.js) и цикла событий
Libev от Марка Леманна.
С размером загрузки всего 18 КБ он состоит из менее 800 строк кода. Он занимает менее 1 МБ оперативной памяти и не использует
корутины или потоки.
Bjoern полностью совместим с
WSGI и считается одним из самых высокопроизводительных
WSGI-серверов.
Bjoern поддерживает постоянные соединения и может привязываться к Unix-сокетам или TCP-адресам.
Bjoern считается более быстрым, чем Gunicorn, и менее раздутым, чем
uWSGI и
Meinheld. Один из недостатков данного сервера — отсутствие нормальной документации с понятными примерами.
uWSGI
uWSGI был разработан компанией
Unbit(Италия) с целью стать fullstack-решением, способным создавать услуги хостинга. Он назван в честь стандарта
WSGI и создавался как плагин для одного из проектов компании.
Широкий и постоянно развивающийся проект,
uWSGI позволяет делать гораздо больше, чем веб-приложения для хостинга. Многие находят
uWSGI мощным инструментом, в то время как другие считают его несколько раздутым. Начиная с версии 2.0 uWSGI поддерживает также запуск веб-приложений на языках Lua, Perl, Ruby и других.
mod_wsgi
mod_wsgi — модуль HTTP-сервера Apache, разработанный Грэмом Дамплтоном (ранее, один из разработчиков
mod_python), предоставляет интерфейс
WSGI для веб-приложений. Совместим с версиями языка Python2 и Python3. Создан в качестве альтернативы другим решениям для интеграции веб-приложений, таких как
CGI,
FastCGI и
mod_python. Может быть установлен как модуль Apache или через
mod_wsgi express. Второй способ упрощает установку для разработчиков Python, которые не так хорошо знакомы с Apache. Другие преимущества:
• Вы не нуждаетесь в root-правах при полной установке.
• Создается локальная среда, что снижает риск негативного воздействия на существующие настройки.
Развитие
mod_wsgi как проекта может показаться медленным из-за того, что модуль разрабатывается одним разработчиком. Другим недостатком является то, что документация в настоящее время плохо организована и может быть устаревшей.
В настоящее время основное внимание уделяется упрощению реализации Apache с использованием
mod_wsgi в средах с использованием
Docker.
Meinheld
Созданный Ютака Мацубара,
Meinheld является сервером, совместимым с
WSGI, который использует мощь
picoev и
greenlet для выполнения асинхронных операций ввода-вывода. Он может использоваться с автономным HTTP-сервером или через
Gunicorn.
Meinheld имеет зависимость от стороннего компонента, называемого greenlet.
Репозиторий с исходным кодом расположен на
GitHub.
Meinheld поддерживает веб-сокеты и включает в себя несколько
monkeypatches над другими модулями для расширения функциональности.
CherryPy
CherryPy — более известен как минималистичный Python-фреймворк для написания веб-приложений,
CherryPy также поставляется с WSGI thread-pooled веб-сервером и поддержкой протокола HTTP / 1.1. Команда разработчиков
CherryPy описывает свой веб-сервер как production-ready, высокоскоростной, thread-pooled HTTP-сервер. Он имеет:
• Быструю, простую настройку;
• Возможность масштабирования;
• Небольшое и простое в использовании решение для ваших приложений Python;
• Поддержка SSL.
CherryPy отличает себя от более известных
WSGI-серверов из-за простоты использования и удобства для разработчиков. Вы можете написать небольшое веб-приложение в течении нескольких минут, запустив его в несколько процессов и создав только один файл с именем server.py. Объединив
CherryPy с Nginx в качестве прокси-сервера, вы получите надежный способ обслуживания своих веб-приложений.
CherryPy был создан Реми Делоном. Он хотел создать структуру, которая была бы максимально близка к
главным принципам разработки на языке Python.
Gunicorn
Gunicorn — это
WSGI-сервер, созданный для использования в UNIX-системах. Название — сокращенная и комбинированная версия слов «Green Unicorn». На самом сайте проекта есть зеленый единорог.
Gunicorn был перенесен из проекта «Unicorn» из языка Ruby. Он относительно быстрый, ресурсоёмкий, легко запускается и работает с широким спектром веб-фреймворков.
Команда разработчиков рекомендует использовать
Gunicorn в связке с Nginx, где Nginx используется в качестве прокси-сервера.
Заключение
В данной статье были разобраны шесть наиболее популярных WSGI-серверов на данный момент:
Bjoern,
uWSGI,
mod_wsgi,
Meinheld,
CherryPy и
Gunicorn. Какой сервер использовать Вам, зависит от условий и требований к Вашему приложению. В следующей части будет проведён анализ производительности этих шести WSGI-серверов.