В чем смысл uWSGI?

Я смотрю на спецификацию WSGI и пытаюсь понять, как серверы, подобные uWSGI, вписываются в картину. Я понимаю, что спецификация WSGI состоит в том, чтобы отделить веб-серверы, такие как nginx, от веб-приложений, как то, что вы бы написали с помощью Flask . Я не понимаю, для чего нужен uWSGI. Почему nginx не может напрямую вызвать мое приложение Flask? Flask не может напрямую обращаться к WSGI? Почему uWSGI нужно встать между ними?

В спецификации WSGI есть две стороны: сервер и веб-приложение. На какой стороне uWSGI?

Ладно, думаю, теперь я понял.

Почему nginx не может напрямую вызвать мое приложение Flask?

Потому nginxчто не поддерживает спецификацию WSGI. Технически nginx мог бы реализовать WSGIспецификацию, если бы захотел, но этого не произошло.

В этом случае нам нужен веб-сервер, который реализует спецификацию, для чего этот uWSGIсервер.

Обратите внимание, что uWSGIэто полноценный http-сервер, который может хорошо работать сам по себе. Я использовал его в этом качестве несколько раз, и он отлично работает. Если вам нужна сверхвысокая пропускная способность для статического контента, у вас есть возможность остаться nginxперед своим uWSGIсервером. Когда вы это сделаете, они будут общаться по протоколу низкого уровня, известному как uwsgi.

«Что за что ?! Еще одна штука называется uwsgi ?!» ты спрашиваешь. Да, это сбивает с толку. Когда вы ссылаетесь, uWSGIвы говорите о http-сервере. Когда вы говорите uwsgi(все в нижнем регистре), вы говорите о двоичном протоколе, который uWSGI сервер использует для взаимодействия с другими серверами nginx. Они выбрали для этого плохую репутацию.

Для всех, кому это интересно, я написал об этом статью в блоге, в которой было больше подробностей, немного истории и несколько примеров.

NGINX в этом случае работает только как обратный прокси и отображает статические файлы, а не динамические файлы , он получает запросы и передает их серверу приложений, которым будет UWSGI.

Сервер UWSGI отвечает за загрузку вашего приложения Flask с помощью интерфейса WSGI. На самом деле вы можете заставить UWSGI напрямую прослушивать запросы из Интернета и удалять NGINX, если хотите, хотя в основном он используется за обратным прокси.

Из документов :

uWSGI поддерживает несколько методов интеграции с веб-серверами. Он также способен самостоятельно обслуживать HTTP-запросы.

WSGI - это просто спецификация интерфейса, проще говоря, он сообщает вам, какие методы должны быть реализованы для передачи запросов и ответов между сервером и приложением. При использовании таких фреймворков, как Flask или Django, этим занимается сам фреймворк.

Другими словами, WSGI - это в основном контракт между приложениями Python (Flask, Django и т. Д.) И веб-серверами (UWSGI, Gunicorn и т. Д.). Преимущество состоит в том, что вы можете изменять веб-серверы без особых усилий, потому что вы знаете, что они соответствуют спецификации WSGI, что на самом деле является одной из целей, как указано в PEP-333 .

Python в настоящее время имеет широкий спектр рамок веб - приложения, такие как Zope, Кихот, Webware, SkunkWeb, ПСА и Twisted Web - назвать лишь несколько 1 . Такое разнообразие вариантов может стать проблемой для новых пользователей Python, потому что, вообще говоря, их выбор веб-фреймворка будет ограничивать их выбор используемых веб-серверов, и наоборот.

Традиционный веб-сервер не понимает и не имеет возможности запускать приложения Python. Вот почему появился сервер WSGI. С другой стороны, Nginx поддерживает обратный прокси для обработки запросов и передачи ответов для серверов Python WSGI.

Эта ссылка может вам помочь: https://www.fullstackpython.com/wsgi-servers.html

Проще говоря, просто представьте себе аналогию, когда вы запускаете приложение CGI или PHP с веб-сервером Nginx. Вы будете использовать соответствующие обработчики, такие как php-fpm, для запуска этих файлов, поскольку веб-сервер в своей собственной форме не отображает эти форматы.