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

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

2) Создание архива прошлых мероприятий с возможностью добавления фото, видео и описания.

3) Предоставление отдельного домена, что обеспечит более эффективную работу поисковых систем и привлечение трафика на страницу.

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

5) Возможность сгенерировать промокоды на определенное количество билетов.

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

Глава 2. Архитектурная организация приложения

В главе рассматривается общая архитектура платформы, приводятся описание модели данных, архитектура базы данных, описывается развертывание инфраструктуры.

2.1 Общая архитектура системы

Поскольку было выявлено требование, о необходимости обеспечения бесперебойной работы платформы в случае различного рода атак, связанных с резким увеличением нагрузкина сервер, было принято решение построить архитектуру, которая при необходимости может горизонтально масштабироваться. Платформа взаимодействует с внешним модулем эквайринга. Архитектура платформы насчитывает 6 сущностей (Рисунок 2).

Реляционная база данных (MySQL)- используется как хранилище.

Кеширующая база данных (Redis) - используется для кеширования тяжелых запросов, по возможности разгружая основную базуот повторяющихся запросов

Главный сервер-бизнес логика платформы, напрямую общается с обеими базами данных, а также с внешним модулем эквайринга.Поскольку потенциально необходима возможность изменения реализаций баз данныхуже на рабочей платформе (например изменить MySQL на MariaDB [12])было принято решение использовать laravel [10]в качестве backendфреймворка.

Кеширующий сервер- разгружает основной сервер, кешируя одинаковые запросы

Для горизонтальной масштабируемости архитектура позволяет добавлять и убирать кеширующие сервера по мере роста нагрузки. Для того, чтобы сам процесс развертывания был автоматизирован, используется ansible [3], на котором были написаны необходимые скрипты.

Сам кеширующий сервер представляет собой кеширующий nginx[14]. Чтобы защитить кеширующие сервера от DDOSатак, было принято решение использовать CloudFlare[2].

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

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

Рисунок 2. Архитектура платформы

Посетитель заходит на доменное имя фестиваля, которое делегировано на сервера CloudFlare. Автоматизированными инструментами CloudFlare проверяет посетителя на то, что тот - реальный человек, а не программа. Если проверка пройдена, то CloudFlareанализирует нагрузку на кеширующие сервера и перенаправляет пользователя на минимально загруженный сервер. Кеширующие сервера возвращают нужную страницу, и в случае попытки покупки билета, посылают запрос по протоколу HTTP на главный сервер. Главный сервер, перенаправляет запрос в банк эквайер, где тот, в случае успешной оплаты билета, с помощью вебхука сообщает главному серверу что оплата прошла успешно и можно отправлять на указанную пользователем почту билет (Рисунок 3).

Рисунок 3.Взаимодействия с инфраструктурой

2.2 Архитектура базы данных

В качестве БД была выбрана реляционная база данных. Привязки к конкретной базе данных нет,и ее можно подменить любой реляционнойв специальном конфигурационном файле.env. В разрабатываемом продукте выбрана БД MySQL[13]. БД имеет 11 основных моделей (Рисунок 4).Для того, чтобы разработанное решение можно было проще переносить между машинами использовались миграции [1]

Рисунок 4.Основные модели БД

2.3 Конфигурирование приложения

Конфигурационный файл главного сервера находится в корне проекта и называется .env. [6]

APP_ENV=local

APP_KEY=KEY

APP_DEBUG =false

DB_CONNECTION=mysql

DB_HOST=127.0.0.1

DB_PORT=3306

DB_DATABASE=jcfest

DB_USERNAME=root

DB_PASSWORD=”password_here”

REDIS_HOST=127.0.0.1

REDIS_PASSWORD=null

REDIS_PORT=6379

MAIL_DRIVER=mailgun

MAIL_HOST=smtp.mailtrap.io

MAIL_PORT=2525

MAIL_USERNAME=username

MAIL_PASSWORD=password

PAYMENT_SECRET_KEY=supersecretkey

Значение некоторых переменных опущено из соображений безопасности. Ниже показаны описания указанных переменных, а также возможные значения.

APP_ENV - переменная окружения, которая показывает приложению, где оно запускается, на локальной машине или на сервере. Возможные значения local и production соответственно.

APP_KEY - специальный ключ который используется фреймворком laravel, может быть автоматически сгенерирован командой phpartisankey:generate [4]

APP_DEBUG- режим логгирования ошибок сервера. Возможные значения true и false. В случае если true, на странице покажется подробный лог ошибки. При развертывании приложения на сервере должено стоять значение false

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

DB_HOST- Адрес, на котором находится база данных, например 127.0.0.1

DB_PORT- Порт на котором находится база данных, например 3306

DB_DATABASE - Имя базы данных, например jcfest

DB_USERNAME- Имя пользователя базы данных, например root

DB_PASSWORD - Пароль пользователя базы данных

REDIS_HOST - Адрес, на котором запущен и доступен Redis

REDIS_PASSWORD - Пароль, отRedis

REDIS_PORT- ПортотRedis

MAIL_DRIVER - драйвер для почтовых рассылок. В разработанном решении используется сервис mailgun [11]

MAIL_HOST - адрес SMTP сервера для почтовых рассылок.

MAIL_PORT- порт от SMTP сервера, рассылающего почту

MAIL_USERNAME- логин, от драйвера почтового рассыльщика

MAIL_PASSWORD - пароль от драйвера почтового рассыльщика

PAYMENT_SECRET_KEY- секретный ключ банка, используется при проверке платежа покупателя.

2.4 Кеширующие сервера и настройка CloudFlare

В качестве облачного решения для защиты от DDOS атак используется СloudFlare. Для настройки необходимо создать аккаунт на сайте www.cloudflare.com. В разделе DNS проставить A записи, указав IP адреса необходимого количества кеширующих серверов.

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

2.4.1 Развертывание кеширующих серверов

За развертывание кеширующих серверов отвечает ansible [3]. Какие сервера развертыватьи sshдоступы [] к этим серверам прописываются в специально конфигурационном файле, доступном по пути ansible/inventory.cfg, относительно корня проекта. Примерфайлаприведенниже:

[webservers]

cache1 ansible_connection=sshansible_user=root ansible_port=22 ansible_ssh_pass=pw1 ansible_host=IP1

cache2 ansible_connection=sshansible_user=root ansible_port=22 ansible_ssh_pass=pw2 ansible_host=IP2

cache3 ansible_connection=sshansible_user=root ansible_port=22 ansible_ssh_pass=pw3 ansible_host=IP3

cache4 ansible_connection=sshansible_user=root ansible_port=22 ansible_ssh_pass=pw4 ansible_host=IP4

cache5 ansible_connection=sshansible_user=root ansible_port=22 ansible_ssh_pass=pw5 ansible_host=IP5

cache6 ansible_connection=sshansible_user=root ansible_port=22 ansible_ssh_pass=pw6 ansible_host=IP6

[webservers:vars]

ansible_become_method=sudo

remote_user=root

Где IP1, IP2, IP3, IP4, IP5, IP6 это аpадреса будущих кеширующих серверов.

ansible_user - имя пользователя на машине кеширующего сервера

ansible_ssh_pass - пароль от ansible_user на машине кеширующего сервера

ansible_port- порт на котором находится ssh клиент (по умолчанию 22)

Скрипт на ansibleподключается к каждой машине поsshи настраивает все необходимое окружение. Гарантируется работоспособность скрипта на машине с операционной системой UbuntuServer16.04 или старше [19]

Кеширующие сервера представляют собой кеширующие nginxсервера[14].Адрес главной машины, запросы с которой они кешируют, настраивается в файле ansible/group_vars/all/main.yaml, который выглядит следующим образом:

production_uri: "http://ip_addr "

nginx_file: "nginx-http.skeleton"

SERVER_FQDN: "full qualified domain name "

production_uri - ip адрес главной машины.

nginx_file- файл с настройкой nginx

SERVER_FQDN - полное доменное имя, например jcfest

2.5 Разработка шаблона под платформу

В качестве шаблона в систему нужно загружать файл в формате blade.php, который является обратно совместим с HTML.

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

<scripttype="text/javascript">

window.FESTIVAL_ID = '{{ $fest_id }}';

</script>

Переменная FESTIVAL_ID может быть названа иным образом на усмотрение разработчика, правая часть выражения должна оставаться неизменной.

При рендеринге шаблона на сервере перед выдачей его посетителю, произойдет подмена строки и вместо {{ $fest_id }} подставится номер фестиваля, например:

Было:

<script type="text/javascript">

window.FESTIVAL_ID = '{{ $fest_id }}';

</script>

Стало (при загрузке шаблона к фестивалю с ID = 3):

<script type="text/javascript">

window.FESTIVAL_ID = '3';

</script>

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

2.6 API платформы

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

GET /api/fests/{FESTIVAL_ID}/ticket_types - Получение списка всех возможных типов билетов.

Пример запроса: https://jcfest.ru/api/fests/4/ticket_types

Пример ответа:

[

{

"id": 1,

"name": "VIP+Парковка",

"price": 5500,

"amount": 25,

"description": "Випбилет с парковкой",

"is_active": 0,

"festival_id": 1,

"additional_type": "PARKING",

"created_at": "2017-11-18 01:07:34",

"updated_at": "2017-12-12 23:13:22",

"tickets_count": 8

},

{

"id": 3,

"name": "Обычный",

"price": 1200,

"amount": 3500,

"description": "Обычныйбилет",

"is_active": 0,

"festival_id": 1,

"additional_type": "NORMAL",

"created_at": "2017-11-18 01:09:43",

"updated_at": "2017-12-29 03:19:22",

"tickets_count": 2821

},

{

"id": 4,

"name": "Билет+Парковка",

"price": 1700,

"amount": 160,

"description": "Билеты с парковкой",

"is_active": 0,

"festival_id": 1,

"additional_type": "PARKING",

"created_at": "2017-11-18 01:11:32",

"updated_at": "2017-12-12 22:34:10",

"tickets_count": 160

}

]

GET /api/fests/{FESTIVAL_ID}/buyable_ticket_types - Получение всех возможных типов билетов, которые можно купить

Пример запроса:

https://jcfest.ru/api/fests/2/ticket_types

Примерответа:

{"status":"ok","0":"festival is not sale now"}

GET/fests/{ FESTIVAL_ID }/photos - Получение списка адресов фотографий, загруженных через административную панель.

GET /fests/{ FESTIVAL_ID }/is_sale_now - Получение информации, доступна ли сейчас продажа билетов и причины если не доступна (продажа приостановлена, начнется через конкретное время, иная причина)

GET /fests/{ FESTIVAL_ID }/tickets_count

GET /date - Получение даты на сервере в формате ISO

POST /send_feedback - Отправка на сервер формы обратной связи

POST /start-payment - покупкабилета

2.7 Архитектура клиентской части

2.7.1 Структура компонентов Vue

Файл с компонентом Vue имеет расширение .vue, и представляет собой следующую структуру:

<template>

Текст HTML

</template>

<style>

Стили таблицы css

</style>

<script>

Бизнес логика компонента на языке JavaScript

</script>

Далее будет разобран написанный компонент StarredTitle. На клиентской странице он используется для того, чтобы можно было сократить количество кода при верстке графического элемента(Рисунок 5).

Рисунок 5. StarredTitle

Исходный код StarredTitle находится ниже.

<template>

<div>

<async-image class="star-icon" :url="imgUrl"></async-image>

<span :style="titleStyle" class="starred-title">{{title}}</span>

<async-image class="star-icon" :url="imgUrl"></async-image>

</div>

</template>

<style lang="scss" scoped>

.star-icon {

width: 1.1em;

vertical-align: top;

padding-top:0.3em;

}

.starred-title {

font-size: 2.466em;

font-weight: bold;

line-height: 0.9em;

}

</style>

<script>

export default {

props: {

title: { type: String, required:true },

offset: { type: Number, 'default': 0},

isWhite: { type: Boolean, 'default': false}

},

computed: {

imgUrl() {

return this.isWhite? '/static/summer2018/stars/whitestar.svg' :'/static/summer2018/stars/star.svg';

},

titleStyle(){

return {"padding-left": this.offset+'em', "padding-right": this.offset+'em' };

}

}

};

</script>

Компоненты vue могут иметь свойства props, это свойства, которые передаются родителями компонента. У них может быть задан тип, например String. В разделе template использует компонент async-image, и передает в его propurl, значение imgUrl, который в свою очередь является compute dproperty, и расположен в разделе computed. Compute dproperty служат в качестве вычисляемой переменной, значение которой будет пересчитываться всякий раз, когда изменяется то, отчего она зависит. Например, computedimg Url возвращает путь до картинки со звездой, но в некоторых местах используется звезда желтого цвета, как на рисунке 3, а в некоторых белая. Поэтому компоненту передается в propis White значение true или false, от которой зависит значение computedimgUrl. В свойство title родитель передает заголовок текста. Результат работы компонента представлен на рисунке 3.

2.7.2 Архитектура административной панели платформы

Клиентская часть платформы написана на фреймворкеVue, все приложение построено с использованием шаблона MVVM, который расшифровывается как Model-View-ViewModel (Рисунок 6).

Рисунок 6. Шаблон проектирования MVVM

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

Сущность View - представление, определяет как будет выглядеть интерфейс, с которым пользователь будет взаимодействовать. В случае компонент Vue - это раздел template в структуре компонента.

2.8 Процесс оплаты билетов

В разработанном продукте интегрирована внешняя система эквайринга, в качестве банка эквайера выступает RFI банк. Но подключение любого другого эквайринга не будет сильно отличаться.

Процесс покупки проходит следующим образом:

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

Для безопасности, банк генерирует на своей стороне секретный ключ. Вместе с данными, отправляется так же хеш сумма от конкатенации номера информации о билетах и секретного ключа. Сам по себе секретный ключ в открытом виде не передается. Он сохраняется локально один на все приложение. Ключ можно узнать, получив аккаунт банка, в разделе ключи API, на стороне сервиса ключ должен лежать в файле .env в корне проекта.

Выводы по главе

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

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

Глава 3. Интерфейс платформы и ее реализация

Глава посвящена особенностям проектных решений и реализации интерфейса платформы.

3.1 Инструменты разработки

Клиентская часть приложения реализована на диалекте языка JavaScript - ES6. Для получения итоговой сборки используется webpack. Webpack транслирует весь написанный код в JavaScript, который поддерживается всеми браузерами.

3.2 Проектирование административных страниц платформы

На административную часть системы налагались следующие функции:

1)Создание и редактирование фестиваля

2)Создание различных типов билетов

3)Загрузка файла-шаблона фестиваля

4)Управление архивом фестивалей

5)Управление отображаемыми страницами по адресу /summer, /winter

В разработанной платформе использовалась библиотека компонентов vuetify.

3.2.1 Главная страница

На главной странице расположены следующие элементы: активный сезон, где можно выбрать, какой сезон является активным на данный момент (лето/зима),фестивали, у которых установлен переключатель «активный» (в сезоне может быть только один активный фестиваль). Ниже мы видим список, куда попадают фестивали, которые были помечены как архивные. У пользователя есть возможность нажать на любой фестиваль и перейти к его редактированию (Рисунок 7).

Рисунок 7. Главная страница администратора

3.2.2 Страница фестивалей

На странице фестивалей представлены все фестивали, созданные в системе (Рисунок 8), при нажатии на кнопку “+” в правом углу окна, появится страница создания нового фестиваля.

Рисунок 8. Страница фестивалей

3.2.3 Страница создания фестиваля

На странице создания фестиваля пользователю предлагается создать фестиваль, заполнив несколько полей:

Название фестиваля - название фестиваля в системе.

Сезон - сезон, когда проходит фестиваль (например, лето/зима).

Дата и время начала и окончания фестиваля - влияет на возможность покупки билетов.

Создание фестиваля происходит при нажатии на кнопку создать, в правом углу окна (Рисунок 9).

Рисунок 9. Создание фестиваля

3.2.4 Страница редактирования фестиваля

На странице редактирования фестиваля предоставляется возможность изменять данные уже созданного в системе фестиваля, а также загрузить шаблон фестиваля. В случае если шаблон уже загружен, его можно скачать для просмотра, а также удалить, чтобы загрузить другой. Удаление происходит при нажатии на крестик справа от кнопки “загрузить” (Рисунок 10).Далее следует информация о билетах. Можно указать дату продажи билетов для того, чтобы продажа билетов запустилась в определенное время. Так же в окне для редактирования фестиваля можно увидеть переключатель для ручного выключения продаж билетов.В пункте “Билеты” отображаются все билеты, созданные для этого фестиваля. При нажатии на строчку с билетом, открывается выпадающее меню, где можно его отредактировать (Рисунок 11). Редактирование билета состоит из заполнения полей:

Название билета - будет показано посетителю при покупке.

Описание билета - будет показано посетителю при покупке.

Количество билетов - максимальное количество билетов, сверх которого система не позволит приобрести билет.

Цена билета - самая важная характеристика, цена за которую билет может быть куплен.

Особые свойства билета - для определенного типа билетов, которые включают парковочное место для посетителя, можно установить переключатель “Требовать номер машины”, чтобы при покупке билета у покупателя принудительно запрашивался номер его автомобиля. Это может быть необходимо для некоторых площадок проведения мероприятий, которые заранее просят предоставить номера машин, для которых зарезервирована парковка. В случае, если билет не предполагает наличие парковочного места, переключатель должен стоять в положении “без особенностей”.При нажатии на “+” появляется окно для создания нового типа билета (Рисунок 12).

Рисунок 10. Редактирование фестиваля

Рисунок 11. Редактирование типа билета

Рисунок 12. Создание типа билета

Если отметить фестиваль как “архивный”, то появятся дополнительные поля для редактирования (Рисунок 13). Появляется возможность задать описание фестиваля, указать количество участников, указать ссылку на видео youtube []. Ниже можно загрузить или удалить фотографии к фестивалю. Чтобы загрузить фото, нужно нажать на свободное место в рамке и выбрать желаемые фото для загрузки.

Рисунок 13. Редактирование архивного фестиваля

3.2.5 Навигация по приложению

Для навигации по приложению используется специальное меню. Его можно увидеть если нажать на иконку в левом верхнем углу окна (Рисунок 14).

Рисунок 14. Навигационное меню

3.2.6 Страница статистики

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

Из выпадающего списка можно выбрать желаемый фестиваль, ниже указать диапазон времени (Рисунок 15).

Рисунок 15. Настройка просматриваемой статистики.

В системе реализована два типа графиков - просмотр продаж по каждому типу билетов, и по их сумме (рисунок 14 и 15 соответственно).

Более того, на графике, показывающем продажи билетов по всем типам билетов, можно выбрать, какие типы билетов наиболее интересны для визуализации. Для визуализации графиков за основу была взята библиотека ChartJS.

Рисунок 16. График продаж по всем типам билетов

Рисунок 17. Суммарный график продаж

3.3 Проектирование шаблонов для фестивалей

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

Рисунок 18. Шаблон зима.

Рисунок 19. Шаблон лето

При нажатии на кнопку купить билет - появляется всплывающее окно (Рисунок 20), где посетитель может купить билет.

Рисунок 20. Окно покупки билетов

Далее пользователя перенаправляет на страницу банка эквайера, где и происходит оплата.

Выводы по главе

В третьей главе рассмотрен пользовательский интерфейс платформы и ее реализация.

Продемонстрированы следующие функции административной панели:

1) Создание фестиваля и его редактирование

2) Создание и изменение типов билетов

3) Загрузка шаблона для сайта

4) Добавление фестиваля в архив

5) Возможности раздела статистики.

Заключение

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

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

Размещено на Allbest.ru