Технологии разработки распределенных приложений для социальных сетей (часть 2)
Адаптивная инфраструктура распределенных приложений. Основу инфраструктуры составляют: архитектура приложения (функциональное ПО), архитектура обеспечивающих средств (рис. 2), т.е., ПО, на котором работает функциональное ПО и аппаратный комплекс, на который будет осуществляться гибкая проекция двух предыдущих компонента.
Любое распределенное приложение функционирует с использованием двух основных компонентов – web-сервера, который непосредственно осуществляет обработку пользовательских запросов, и системы управления базами данных. При использовании этих двух компонентов возникают следующие проблемы: основная нагрузка приходится на web-сервер, т.к. данный компонент кроме обработки запросов должен также проводить диспетчеризацию запросов, при этом некоторые части сервера СУБД задействованы и несут повышенную нагрузку, в то время как другие – бездействуют.
Рис. 2. Модифицированная архитектура обеспечивающего ПО
Следовательно, при использовании двухкомпонентной архитектуры обеспечивающего ПО система является плохо масштабируемой при повышении нагрузки со стороны пользователей. Кроме того, поскольку нагрузка на компоненты регулируется неравномерно и web-сервер осуществляет также функции диспетчеризации, то это может быть предпосылкой выхода системы из строя или отказа в обслуживании запросов. Поскольку разрабатывается инфраструктура непосредственно для социальных сетей, то к архитектуре добавим еще один компонент – прокси-сервер (рис. 2). Этот компонент предназначен для фильтрации запросов пользователей, регулирования нагрузки на компоненты обеспечивающего ПО, что позволяет снизить нагрузку на web-сервер.
На рис. 3 представлена схема взаимодействия компонентов функционального и обеспечивающего ПО и показано, как может быть спроектировано функциональное ПО, работающее внутри контейнеров (web-сервера и СУБД), при использовании пятислойной архитектуры. Следует обратить внимание на то, что межкомпонентное взаимодействие осуществляется только на уровне контейнеров. В данном случае увеличение количества уровней абстракции улучшает расширяемость и масштабируемость приложения.
При использовании трехслойной архитектуры для функционального ПО рис. 3 незначительно изменится: в контейнере сервера БД будет отсутствовать слой «Сопоставления данных уровня СУБД», а в контейнере web-сервера – соответственно слои «Сопоставление данных» и «Контроллер/Медиатор». Таким образом, прослеживается расширяемость и масштабируемость создаваемой инфраструктуры, т.е. независимо от применяемой архитектуры функционального ПО контейнера будут работать таким же образом. Это позволяет говорить, что совокупность архитектур функционального и обеспечивающего ПО является расширяемой и масштабируемой.
Однако возможностей данной инфраструктуры недостаточно для обеспечения распределения нагрузки и подавления пиков пользовательской активности. Недостатком является то, что компонент «прокси-сервер» при своем участии является «пассивным фильтром», а между web-сервером и сервером БД отсутствуют фильтры как таковые, что не дает возможности регулировать поток запросов между web-сервером и сервером БД. В связи с этим, необходимо добавить дополнительные компоненты – программные агенты. В число этих агентов входят: программный агент сбора статистической информации, программный агент передачи управляющих воздействий, главный агент и информационная магистраль передачи данных. Кроме того, необходимо ввести дополнительный прокси-сервер, который будет фильтровать и распределять запросы между web-сервером и сервером БД.
Рис. 3. Схема взаимодействия компонентов функционального и обеспечивающего ПО
Рассмотрим эти дополнительные компоненты более подробно в следующей части публикации.