В чем смысл uWSGI?

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

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

Ответ 1

Ладно, я думаю, что сейчас понимаю.

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

В настоящее время Python может похвастаться широким спектром фреймворков веб-приложений, таких как Zope, Quixote, Webware, SkunkWeb, PSO и Twisted Web, и это лишь некоторые из них [1]. Такой широкий выбор может стать проблемой для новых пользователей Python, потому что, вообще говоря, их выбор веб-инфраструктуры ограничит их выбор используемых веб-серверов и наоборот.