Статьи в блоге Праймсофт

Главная / Блог / Статьи / Мобильность / Архитектура информационной системы «Парк-Патриот» для проведения мероприятия «Армия-2015». Часть 1

Архитектура информационной системы «Парк-Патриот» для проведения мероприятия «Армия-2015». Часть 1

Требования

Заказчиком в работе поставлена задача реализовать информационную систему, обеспечивающую проведение различных мероприятий на территории «Парк-Патриот». В качестве первого мероприятия определен форум «Армия-2015», который будет проходить с 16 по 19 июня 2015 г.

Информационная система должна включать:

  • публичный сайт «Парк-Патриот» ‑ основная точка входа всех посетителей, сайт должен предоставлять всю необходимую информацию о мероприятии, участниках, выставочных образцах, деловой и открытой программе, календаре событий, схеме проезда и др.;
  • web-портал для администрирования системой и управления информационным контентом системы;
  • мобильное приложение для посетителей;
  • медиа-сервер с функциями публикации статического и live видео-контента. При этом определено, что количество онлайн-каналов может достигать 16.

При этом система должна иметь возможность настраиваться (расширяться) для хранения и управления различными мероприятиями, т.к. после проведения форума «Армия-2015» будет определен новый форум и система должна продолжить функционировать без внесения в нее принципиальных изменений.

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

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

Публичный сайт должен обеспечивать приемлемый уровень отклика при нагрузках до 5000 одновременно подключенных пользователей. Одновременно с этим серверная часть системы должна одновременно обрабатывать запросы сопоставимого количества мобильных клиентов.

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

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

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

Анализируя варианты использования системы, видно, что нагрузка на ИС будет носить лавионообразный характер и станет максимальной в период 16 по 19 июня. Остальное время нагрузка будет минимальной и в основном относиться к административной части системы в период подготовки мероприятия и наполнения системы информационным контентом. При этом отдельные элементы системы, такие как медиа-сервер, будут иметь большую нагрузку, т.к. это связано с большим количеством онлайн-каналов и необходимостью поддержки различных протоколов доступа к видео-контенту (RTMP, HLS).

Состав системы

В результате анализа требований совместно с заказчиком были определены основные элементы системы.

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

Кроме того, предполагается возможность горизонтального масштабирования серверов в случае превышения порогового значения по загрузке ЦП/памяти/каналов связи. Балансировкой загруженности сервером будет управлять DNS-балансировщик, который определяет маршруты относительно данных по загруженности серверов. Балансировщик нагрузки должен обеспечивать равномерную загрузку серверов и/или переключение запросов клиентов с случае сбоев или сервисных работ.

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

Модель данных

Заказчиком были выставлены следующие требования к модели данных:

  • все информационное наполнение должно быть представлено на двух языках: русский, английский;
  • все информационные объекты должны иметь теги для облегчения поиска и группирования информации;
  • модель данных должна иметь возможность без крупных изменений использоваться для других мероприятий после «Армия-2015».

На основании требований и специфики системы сформировали общие сущности логической модели данных.

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

Физическая модель данных реализована по реляционной схеме на базе СУБД MySQL 5.6. Для проектирования использован продукт MySQLWorkbench, который позволяет в том числе подготавливать структурную схему через ReverseEngineeringБД.

Реляционная модель данных принята по двум причинам: 1) сильная связность информационных сущностей с необходимостью частых изменений данных, 2) опыт использования реляционных СУБД, 3) простота интеграции с Web-фреймворками при разработке портала. От NoSQL-решений решено было отказаться.

Для поддержки тегов ко всем информационным объектам реализована схема «наследования» объектов. Все объекты логически наследуются от одного типа объекта – информационного объекта, который включает ID, время создания, модификации, создателя. Все остальные объекты (новости, события, …) наследуются от данного объекта и расширяют его необходимыми атрибутами.

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

Для поддержки многоязычности информационного контента использована схема с translation-таблицами. Все объекты, содержащие текст, разделены на основную таблицу и таблицу-перевода (events и events_ru/events_en). Основная таблица содержит общие данные, таблица перевода содержит только текстовые поля на требуемом языке и ссылку на базовый объект. В результате, количество таблиц перевода соответствует количеству информационных таблиц.

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

Модель данных мобильного приложения

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

В процессе работы мобильное приложение периодически синхронизирует данные с порталом, что позволяет: 1) иметь в приложении всегда актуальные данные, 2) не выполнять полную загрузку данных при каждом обращении пользователя к какому-то ресурсу (описание выставочного образца, предприятия или представителя).