В чем смысл 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, потому что, вообще говоря, их выбор веб-инфраструктуры ограничит их выбор используемых веб-серверов и наоборот.