Архитектура ПС. Разработка веб-приложений для электронных заметок

Для выбора архитектуры ПС нам необходимо определить основные требования к ней. Система предназначена для работы в среде Internet, соответственно следует отталкиваться от стандартной архитектуры веб приложения (рис. 7). электронные заметки программный приложение.

Рис. 7 Архитектура веб приложения

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

Рис. 8 Архитектура нагруженного веб приложения

Рассмотрим некоторые из блоков, представленных на данном рисунке подробнее.

Приложение в реальной системе будет представлять собой сервер приложений (mvc). Его архитектура (рис. 9) проста, назначение его в том, чтобы разгрузить сервер базы данных от обработки лишних запросов, связанных с работой приложения. Стрелками на рисунке указаны процессы взаимодействия элементов архитектуры.

• 1. Пользователь взаимодействует с контроллером, совершая действия с элементами управления приложения.
• 2. Как реакция на действия пользователя контроллер обновляет представление модели приложения.
• 3. Действия пользователя могут привести к смене модели представления приложения. Контролер манипулирует этими изменениями.
• 4. Для формирования представления модели могут потребоваться данные из базы данных. Модель представления взаимодействует с базой данных.
• 5. Представление модели показывается пользователю.

Рис. 9 Архитектура сервера приложений.

Статика. В реальной системе этот блок будет представлен сервером статических данных. Выше говорилось о том, что модель представления приложения может обращаться к базе данных с целью получения необходимой для формирования представления информации. Допустим, что пользователь активен и совершает множество действий в системе. Его действия в программе интерпретируются в SQL-запросы к базе данных. Эти запросы можно разделить на две группы: запросы, связанные с функциональными возможностями системы, то есть создание и редактирование заметок, и запросы, связанные с изменениями представления приложения, так как выше описанная модель сервера приложений связана с базой данных. Чем активнее пользователь, тем больше запросов, причем обоих типов. Это перегружает сервер базы данных. Данные, необходимые модели представления, как правило, однотипны и не очень вариативны. Однако, если моделей в системе множество, то количество таких побочных данных резко возрастает. Это сокращает как полезное место в базе данных, так и замедляет ее работу в виду увеличения количества запросов к ней. Что же делать? Решение просто. Необходимо вынести эти побочные данные на отдельный сервер и разгрузить сервер основной базы данных системы.

База данных. О перегрузках базы данных в виду большого количества запросов говорилось много. Даже если вынести всю информацию кроме той, которой заполняют ее пользователи, тем самым уменьшить количество запросов, все равно их число останется внушительным. С ростом количества запросов начнется снижение времени отклика приложения, что вызовет недовольства пользователей. Понятно, что ни одна система не в состоянии обрабатывать больше двух-трех запросов одновременно. В системе формируется очередь запросов, и с течением времени эта очередь переполняется, и запросы начинают теряться. Проблему может решить размножение серверов с базами данных, однако необходим механизм, позволяющий распределять запросы между этими серверами. Таким механизмом служит сервер балансировки (рис. 10).

Теперь, разобравшись в компонентах системы, сформируем ее окончательное подробное представление (рис. 11).

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

Рис. 11 Архитектура системы