В чем смысл uWSGI?
Я смотрю на спецификация WSGI и я пытаюсь выяснить, как сервера, как на uwsgi вписывается в картину. Я понимаю, что смысл спецификации WSGI заключается в том, чтобы отделить веб-серверы, такие как nginx, от веб-приложений, таких как то, что вы пишете с помощью колбы. Я не понимаю, для чего нужен uWSGI. Почему nginx не может напрямую вызвать мое приложение Flask? Не может фласк говорить WSGI непосредственно к нему? Почему uWSGI нужно вставать между их?
в спецификации WSGI есть две стороны: сервер и веб-приложение. С какой стороны на uwsgi на?
3 ответов
ладно, кажется, я понял.
почему nginx не может напрямую вызвать мое приложение колбы?
, потому что nginx не поддерживает спецификацию WSGI. Технически nginx может реализовать WSGI spec, если они хотели, они просто не имеют.
в этом случае нам нужен веб-сервер, который реализует спецификацию, что и является uWSGI сервер для.
отметим, что uWSGI является полноценным HTTP-сервером, который может и хорошо работает сама по себе. Я использовал его в этом качестве несколько раз, и он прекрасно работает. Если вам нужна супер высокая пропускная способность для статического контента, то у вас есть возможность вставлять nginx перед uWSGI сервер. Когда вы это сделаете, они будут общаться по протоколу низкого уровня, известного как uwsgi.
"что?! Еще одна вещь под названием uwsgi?!" вы спрашиваете. Да, это сбивает с толку. При ссылке uWSGI вы говорите о сервере http. Когда вы поговорим о uwsgi (все строчные буквы) вы говорите о бинарный протокол что uWSGI сервер использует для общения с другими серверами, как nginx. Они выбрали плохое имя.
для всех, кто заинтересован, я написал статья в блоге об этом с большей конкретикой, немного истории и некоторые примеры.
традиционный веб-сервер не понимает или не имеет никакого способа запуска приложений Python. Вот почему сервер WSGI входит. С другой стороны, Nginx поддерживает обратный прокси для обработки запросов и передачи ответов для серверов Python WSGI.
эта ссылка может помочь вам: https://www.fullstackpython.com/wsgi-servers.html
NGINX в этом случае работает только как обратный прокси, он получает запросы и прокси их на сервер приложений, который будет UWSGI.
сервер UWSGI отвечает за загрузку приложения Flask с помощью интерфейса WSGI. Вы действительно можете заставить UWSGI слушать непосредственно запросы из интернета и удалить NGINX, если хотите, хотя он в основном используется за обратным прокси.
с docs:
на uwsgi поддерживает несколько методов интеграции с веб-серверами. Он также способен обслуживать HTTP-запросы сам по себе.
WSGI - это просто спецификация интерфейса, в простых терминах, она сообщает вам, какие методы вы должны реализовать для передачи запросов и ответов между сервером и приложением. При использовании фреймворков, таких как Flask или Django, это обрабатывается самой фреймворком.
другими словами, WSGI-это в основном контракт между python приложения (колба, Django и т. д.) и веб-серверы (UWSGI, Gunicorn и т. д.). Преимущество заключается в том, что вы можете изменить веб-серверы с небольшими усилиями, потому что вы знаете, что они соответствуют спецификации WSGI, которая на самом деле является одной из целей, как указано в PEP-333.
Python в настоящее время может похвастаться широким спектром фреймворков веб-приложений, таких как Zope, Quixote, Webware, SkunkWeb, PSO и Twisted Web-чтобы назвать только несколько [1]. Этот широкий выбор можно проблема для новых пользователей Python, потому что, вообще говоря, их выбор веб-фреймворка ограничит их выбор используемых веб-серверов, и наоборот