Лучшая практика для стратегии балансировки нагрузки в 3-х уровневой архитектуре

Question

Прежде чем перейти к вопросам, позвольте мне уточнить мою терминологию.

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

Веб-уровень - Состоит из веб-серверов, выполняющих работу прокси. Например. IIS Rewrite

Уровень приложения - Состоит из серверов приложений, которые имеют фактический исходный код приложения. Например. Приложение ASP.NET

Уровень базы данных - Состоит из серверов баз данных, на которых хранятся данные. Например. MS SQL Server.

У меня есть две общие архитектуры, как вы можете видеть ниже. схема

И что было бы лучше для практики между рисунком 1 и рисунком 2 (или, может быть, за и против). Я рассматриваю аспекты высокой доступности (HA), ремонтопригодности, сложности, разделения проблем и т. Д.

Answer 1

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

Мой вопрос: почему бы не объединить ваше приложение и уровни прокси на одном оборудовании и иметь 4 узла в вашем пуле резервирования вместо двух.Это увеличит вашу фактическую избыточность, а также устранит сетевой скачок.Ваша поверхность атаки уже уменьшена вашим аппаратным балансировщиком нагрузки.