Введение в WSGI-серверы: Часть первая

Данная статья является переводом статьи Кевина Голдберга «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 состоит из двух основных сущностей:

1. Веб-сервер (Nginx, Apache и т. д.);
2. Веб-приложение, написанное на языке Python.

Принцип работы:

Веб-сервер исполняет код и отправляет связанную с http-запросом информацию и callback-функцию в веб-приложение. Затем запрос на стороне приложения обрабатывается и высылается ответ на веб-сервер.

Периодически между веб-сервером и веб-приложением существуют одна или несколько промежуточных прослоек. Такие прослойки позволяют осуществить, например, балансировку между несколькими веб-приложениеми или предпроцессинг(предобработку) отдаваемого контента.

Вот примеры фреймворков, поддерживающих WSGI:

• Django,
• CherryPy,
• Flask,
• TurboGears,
• web2py.

Почему именно 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-серверов.

Автор: Степан Филатов

Источник