У чому сенс uWSGI?

Я розглядаю специфікацію WSGI і намагаюся зрозуміти, як такі сервери, як uWSGI, вписуються в картину. Я розумію, що сенс специфікації WSGI полягає у тому, щоб відокремити веб-сервери, такі як nginx, від веб-додатків, як щось, що ви писали б за допомогою Flask . Я не розумію, для чого призначений uWSGI. Чому nginx не може безпосередньо викликати мою програму 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, Quixote, Webware, SkunkWeb, PSO та Twisted Web - назвемо лише декілька 1 . Цей широкий вибір варіантів може стати проблемою для нових користувачів Python, оскільки загалом, вибір веб-фреймворку обмежить їх вибір корисних веб-серверів і навпаки.

Традиційний веб-сервер не розуміє і не може запустити програми Python. Ось чому приходить сервер WSGI. З іншого боку, Nginx підтримує зворотний проксі-сервер для обробки запитів та передачі відповідей на сервери WSGI Python.

Це посилання може вам допомогти: https://www.fullstackpython.com/wsgi-servers.html

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