Распределенное развертывание

Распределенный подход позволяет конфигурировать серверы приложений для размещения на них различных слоев с целью обеспечения максимального соответствия требованиям каждого слоя. Тем не менее, поскольку основным фактором оптимизации развертывания компонентов является сопоставление профиля потребления ресурсов компонента с определенным сервером, прямое проецирование слоев в уровни часто не является наилучшей стратегией развертывания.

Многоуровневость обеспечивает возможность использования множества инфраструктур. Каждая инфраструктура оптимизируется под определенный набор эксплуатационных требований и требований по использованию системных ресурсов. После этого компоненты могут быть развернуты на уровне, наиболее точно соответствующем требованиям по ресурсам, что обеспечит наилучшие производительность и поведение. Чем больше уровней, тем больше вариантов развертывания имеется для каждого компонента. Распределенное развертывание обеспечивает более гибкую среду, в которой в случае необходимости намного проще реализовать горизонтальное или вертикальное масштабирование. Однако нельзя забывать, что введение большего количества уровней ведет к повышению сложности, увеличению необходимого объема работ по развертыванию и затрат.

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

Вопросы производительности и проектирования в распределенных средах

Распределение компонентов по уровням может привести к снижению производительности изза издержек на удаленные вызовы через физические границы. Однако распределение компонентов может улучшить возможности масштабирования, удобство обслуживания, приводя к снижению затрат в долгосрочной перспективе. При проектировании приложения, которое будет выполняться в физически распределенной инфраструктуре, руководствуйтесь следующими рекомендациями:

При выборе каналов и протоколов связи между уровнями обеспечивайте безопасное взаимодействие между компонентами с минимальным негативным воздействием на производительность. Используйте преимущества асинхронных вызовов, односторонних вызовов или очереди сообщений для максимального сокращения блокировки ресурсов при взаимодействии через физические границы.

Используйте такие свойства сервисов и операционной системы, как поддержка распределенных транзакций и аутентификация, которые могут упростить дизайн и повысить возможности взаимодействия.

Применяйте максимально простые интерфейсы компонентов. Детализированные интерфейсы, требующие множества вызовов для выполнения одной задачи, подходят только, если компоненты физически размещаются на одном компьютере. При распределении компонентов по разным компьютерам лучшая

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

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

Спланируйте оптимальную стратегию введения дополнительных серверов или ресурсов, что обеспечит повышение производительности и доступности.

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

◦Без сохранения состояния. Все необходимые данные о состоянии будут предоставлены при обращении к уровню. Такая стратегия обеспечивает лучшую масштабируемость, но часто требует от клиента предоставления данных о состоянии.

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

Рекомендации по размещению компонентов при распределенном развертывании

При проектировании распределенного развертывания необходимо, прежде всего, распределить имеющиеся логические слои и компоненты по физическим уровням. В большинстве случаев слой представления размещается на клиенте или на Веб-сервере; слой сервисов, бизнес-слой и слой доступа к данным – на сервере приложений; и база данных – на собственном сервере. Но такая схема не является обязательной. При принятии решения о размещении компонентов в распределенной среде руководствуйтесь следующими рекомендациями:

Распределяйте компоненты только в случае необходимости. Основаниями для реализации распределенного развертывания являются политики безопасности, физические ограничения, совместное использование бизнес-логики и масштабируемость.