Назад | Перейти на главную страницу

Использование встроенного балансировщика нагрузки uWSGI против nginx

У меня есть приложение на Python, которое предоставляется через wsgi, и я собирался развернуть его по всему миру. Из него не обслуживаются статические ресурсы. Приложение будет развернуто на одном компьютере. Я собираюсь обслуживать приложение wsgi с помощью uwsgi и могу подумать о двух вариантах:

  1. обслуживать через один экземпляр uwsgi на машине (выяснить и вертеться с большим количеством рабочих / процессов для использования, возможно, начать с 2 * # ядер)

  2. Запустите несколько экземпляров uwsgi, каждый с одним рабочим, за nginx на одной машине.

  3. Запустить один экземпляр uwsgi за nginx

Следует иметь в виду, что сервер уже находится за балансировщиком нагрузки.

Я бы подумал об эксперименте с №2 или №3, если бы у меня были статические ресурсы для обслуживания. Поскольку нет статических файлов, это кажется излишним.

В этом случае будет ли польза от запуска uwsgi за nginx? против одного сервера uswgi с соответствующим количеством рабочих?

Ответ на этот вопрос во многом зависит от вашего варианта использования.

Я мало что знаю о uWSGI, но я не могу представить себе ни одного варианта использования, где было бы разумно иметь несколько подобных экземпляров, работающих на одной и той же машине / vm, поскольку он, очевидно, предназначен для многопоточности. Это просто дополнительные накладные расходы. Итак, №2 на самом деле не вариант (если ваше приложение нужно часто перезапускать, исправьте свой код, а не используйте такую ​​настройку).

# 3 сейчас звучит бесполезно, но это не так. nginx не требует больших накладных расходов, его производительность и объем памяти, вероятно, в этом случае незначительны по сравнению с приложением python. Это действительно влияет на задержку, но опять же, это не должно иметь значения для чего-либо, кроме игрового сервера RTS (и http в любом случае не предназначен для низкой задержки). Настоящая проблема - это дополнительная настройка и еще одна точка отказа. Однако у вашего приложения гораздо больше шансов выйти из строя, чем у хорошо протестированного, активно используемого веб-сервера, поэтому все в основном сводится к конфигурации.

Разобравшись с этим, вот некоторые вещи, которые следует учитывать.

  • Если это небольшое веб-приложение, в котором вы не ожидаете большего количества пользователей, чем может без проблем обрабатывать один сервер (например, ваша личная домашняя страница, домашняя страница небольшой школы), единственный uWSGI вполне подойдет. Поскольку uWSGI имеет свой собственный балансировщик нагрузки, у вас будет запасной вариант, который может обрабатывать масштабирование для небольших экземпляров (однако я не уверен в крупных развертываниях).
  • Если вы уверены, что ваше приложение будет оставаться там, где оно размещено сейчас (например, на AWS), вы все равно можете использовать №1 и использовать встроенный балансировщик нагрузки хостеров. Это сокращает ваши накладные расходы, и вам не нужно беспокоиться о дополнительной настройке. Однако вы должны знать, что цены и услуги могут измениться, и небольшие хостеры могут прекратить свою деятельность (с AWS этот риск достаточно мал).
  • Если вы считаете, что ваше приложение может быстро масштабироваться с одной виртуальной машины, а балансировщик нагрузки вашего хостера не является гарантией, вам действительно стоит добавить nginx. Как я уже говорил выше, это небольшие накладные расходы, и если вам вдруг понадобится вторая виртуальная машина, вы будете очень благодарны. Он также позволяет обрабатывать сбои вашего приложения и фильтровать запросы (например, если вы находитесь под DOS). Если вы добавляете https, nginx вам тоже поможет.

TL; DR

Если вы уверены, что ваше приложение не будет масштабироваться быстрее, чем вы можете масштабировать код (или не собираетесь масштабироваться вообще), вам не нужны его дополнительные функции (ваше приложение не так стабильно, как вы думаете !) и вы уверены в возможности балансировки нагрузки хостеров, пропустите nginx. Если нет или вы не на 100% уверены, что это останется верным, используйте nginx. Это не так много накладных расходов, но может избавить вас от многих проблем.