Имеет ли смысл балансировка нагрузки на одном аппаратном сервере?

Question

Это может быть случай, когда я не понимаю, как работает балансировка нагрузки, но потерпите меня ... Я сейчас нахожусь в процессе разработки веб-приложения, и мне доступен один аппаратный сервер.Большинство известных мне архитектур используют Nginx в качестве балансировщика нагрузки перед несколькими серверами (с прокси Nginx на разные порты).

У меня такой вопрос: я бы очень хотел использовать Docker для контейнерирования Nginx и нескольких экземпляров приложения Django, которое я собираюсь запустить (как и базу данных), но стоит ли иметьнесколько экземпляров приложения, запущенного на одном аппаратном сервере?Сервер может запускать несколько экземпляров приложения Django на разных портах, но, безусловно, балансировка нагрузки заключается в распределении нагрузки на оборудование, и в этом случае не было бы смысла?

Я думаю, что часть путаницытот факт, что «сервер» может означать аппаратное или программное обеспечение.Было бы здорово, если бы кто-то с лучшим пониманием смог мне это прояснить!

Большое спасибо

Answer 1

На земле Docker (и в публичном облаке) есть пара обстоятельств, когда использование балансировщика нагрузки перед одним экземпляром действительно полезно.Основная предпосылка заключается в том, что конфигурация балансировщика нагрузки довольно стабильна, даже если вы будете регулярно перезагружать базовое приложение, поэтому вы можете направлять клиентов на балансировщик нагрузки, не беспокоясь об изменении сведений о соединении.

@ CalumHalpin's answerнамеки на обновления без простоев, что является хорошим примером использования.С простым Docker он может работать так:

1. Запустите балансировщик нагрузки перед одним контейнером приложения.
2. docker build и docker run новая версияконтейнер приложения (со старым еще работающим).
3. Присоедините новый контейнер к балансировщику нагрузки.Теперь балансировщик нагрузки будет обслуживать трафик в обоих направлениях.
4. Отсоедините старый контейнер.docker stop и docker rm it.

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

В различных кластеризованных средах балансировщик нагрузки также позволяет получить доступ к службе, которая может работать на другом узле.Kubernetes Service - это балансировщик нагрузки с внутренним видимым DNS-именем, который в сочетании с Deployment реализует описанный выше путь обновления с нулевым временем простоя.В Amazon ECS вы можете подключать балансировщики нагрузки к сервисам , и раньше это был лучший способ общения одного сервиса с другим даже в кластере ECS.

Answer 2

С точки зрения производительности - способ узнать наверняка, какой подход лучше экспериментальным путем. Я не могу представить себе причину, по которой несколько экземпляров приложения будут работать лучше, чем один, хотя вы собираетесь обслуживать его с помощью Nginx, который уже будет обрабатывать параллельные запросы. Действительно, я ожидал бы, что это будет хуже из-за накладных расходов на контейнеризацию.

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