Jaki jest sens uWSGI?

Patrzę na specyfikację WSGI i próbuję dowiedzieć się, jak serwery takie jak uWSGI pasują do obrazu. Rozumiem, że celem specyfikacji WSGI jest oddzielenie serwerów internetowych, takich jak nginx, od aplikacji internetowych, tak jak coś, co napisałbyś za pomocą Flaska . Nie rozumiem, do czego służy uWSGI. Dlaczego nginx nie może bezpośrednio wywołać mojej aplikacji Flask? Czy flask nie może mówić bezpośrednio do niego w WSGI? Dlaczego uWSGI musi znaleźć się między nimi?

Specyfikacja WSGI ma dwie strony: serwer i aplikację internetową. Po której stronie jest uWSGI?

Dobra, myślę, że teraz rozumiem.

Dlaczego nginx nie może bezpośrednio wywołać mojej aplikacji Flask?

Ponieważ nginxnie obsługuje specyfikacji WSGI. Technicznie rzecz biorąc, nginx mógłby zaimplementować WSGIspecyfikację, gdyby chciał, po prostu tego nie zrobił.

W takim przypadku potrzebujemy serwera WWW, który implementuje specyfikację, do której służy uWSGIserwer.

Zauważ, że uWSGIjest to pełnoprawny serwer http, który może i działa dobrze samodzielnie. Używałem go w tej roli kilka razy i działa świetnie. Jeśli potrzebujesz bardzo dużej przepustowości dla zawartości statycznej, możesz trzymać się nginxprzed uWSGIserwerem. Gdy to zrobisz, będą komunikować się za pośrednictwem protokołu niskiego poziomu, znanego jako uwsgi.

„Co do czego ?! Kolejna rzecz zwana uwsgi ?!” ty pytasz. Tak, to zagmatwane. Kiedy się odwołujesz, uWSGImasz na myśli serwer http. Kiedy mówisz o uwsgi(wszystkie małe litery), mówisz o protokole binarnym , którego uWSGI serwer używa do komunikacji z innymi serwerami, takimi jak nginx. Wybrali złe imię na tym.

Dla każdego, kto jest zainteresowany, napisałem o tym artykuł na blogu , zawierający więcej szczegółów, trochę historii i kilka przykładów.

NGINX w tym przypadku działa tylko jako odwrotne proxy i renderuje pliki statyczne, a nie pliki dynamiczne , odbiera żądania i przekazuje je do serwera aplikacji, którym będzie UWSGI.

Serwer UWSGI jest odpowiedzialny za ładowanie aplikacji Flask za pomocą interfejsu WSGI. W rzeczywistości możesz sprawić, aby UWSGI nasłuchiwało bezpośrednio żądań z Internetu i usuwał NGINX, jeśli chcesz, chociaż jest on głównie używany za odwrotnym proxy.

Z dokumentów :

uWSGI obsługuje kilka metod integracji z serwerami WWW. Jest również w stanie samodzielnie obsługiwać żądania HTTP.

WSGI to tylko specyfikacja interfejsu, w prostych słowach mówi, jakie metody należy zaimplementować w celu przekazywania żądań i odpowiedzi między serwerem a aplikacją. Podczas używania frameworków, takich jak Flask lub Django, jest to obsługiwane przez sam framework.

Innymi słowy, WSGI jest w zasadzie umową między aplikacjami Pythona (Flask, Django itp.) A serwerami internetowymi (UWSGI, Gunicorn itp.). Zaletą jest to, że możesz zmienić serwery internetowe przy niewielkim wysiłku, ponieważ wiesz, że są one zgodne ze specyfikacją WSGI, która jest w rzeczywistości jednym z celów, jak określono w PEP-333 .

Obecnie Python oferuje szeroką gamę struktur aplikacji internetowych, takich jak Zope, Quixote, Webware, SkunkWeb, PSO i Twisted Web - by wymienić tylko kilka 1 . Ta szeroka gama opcji może stanowić problem dla nowych użytkowników Pythona, ponieważ ogólnie rzecz biorąc, ich wybór frameworka internetowego ograniczy ich wybór użytecznych serwerów WWW i odwrotnie.

Tradycyjny serwer WWW nie rozumie ani nie ma żadnego sposobu na uruchamianie aplikacji Python. Dlatego właśnie pojawił się serwer WSGI. Z drugiej strony Nginx obsługuje zwrotne proxy do obsługi żądań i przekazywania odpowiedzi zwrotnych dla serwerów Python WSGI.

Ten link może ci pomóc: https://www.fullstackpython.com/wsgi-servers.html

Mówiąc prościej, pomyśl tylko o analogii, w której uruchamiasz aplikację CGI lub PHP z serwerem WWW Nginx. Będziesz używać odpowiednich programów obsługi, takich jak php-fpm, do uruchamiania tych plików, ponieważ serwer sieciowy w swojej natywnej formie nie renderuje tych formatów.