Общая архитектура приложения

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

• — Серверной части веб_приложения, для взаимодействия с пользователем.
• — Клиентской части веб_приложения.
• — Очереди сообщений.
• — Сервера баз данных.
• — Нескольких вычислительных узлов, выполняющих сложные функции.

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

Серверная часть будет состоять из нескольких модулей:

• — Обработчик запросов.
• — Обработчик сообщений в исходящей (input) очереди.
• — Обработчик сообщений во входящей (output) очереди.
• — Модуль для работы с базой данных.

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

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

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

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

Для работы с очередями сообщений была выбрана платформа RabbitMQ, основанная на стандарте Advanced Message Queuing Protocol (AMQP). В протоколе AMQP используются такие понятия, как:

• — Exchange — место, куда пишутся сообщения.
• — Queue — место, откуда читаются сообщения.
• — Route — связывает Exchange и Queue.

На рисунке B.1 [24] показана схема работы RabbitMQ с одной очередью. Видно, что слева находится Publisher — субъект, который отправляет сообщение в Exchange, после этого Route перенаправляет сообщения с помощью метаданных сообщения в соответствующую очередь — Queue. Такая схема позволяет добиться большой гибкости, т.к. приложение может публиковать сообщения в N Exchange и читать из M очередей (рис. B.2 [24]). При этом из одной очереди могут читать несколько клиентов, в этом случае сообщения раздаются по алгоритму round_robin, что наделяет RabbitMQ функцией балансировщика. Помимо этого, RabbitMQ, отдав сообщение, требует подтверждения его обработки сервером, или отправки отказа в обработке, что приводит к возврату отправленного сообщения обратно в очередь, и сообщение снова отправляется подписанным на очередь серверам по алгоритму round_robin. В пользу выбора RabbitMQ можно отметить следующие функции: отправка сообщений в очереди, балансировка между серверами, а также повышение отказоустойчивости, за счет подтверждения обработки сообщения.

В разрабатываемом веб_приложении было решено использовать реляционную систему управления базами данных (СУБД) PostgreSQL. К преимуществам данной СУБД можно отнести:

• — Данная СУБД распространяется бесплатно и имеет открытый исходный код.
• — Поддержка объектно-реляционной модели данных.
• — Возможность расширения функционала за счет хранимых процедур.
• — Большое сообщество — это позволит легко найти ответы на возникшие вопросы.
• — Поддержка большого списка типов данных, включая XML и JSON, а также есть тип для быстрого поиска по JSON — JSONB.
• — Возможность написания хранимых процедур на разных языках программирования, например, SQL, PL/PGSQL, JavaScript, Perl и др.
• — Возможность создавать индексы не только по полям, но и функциям от них.
• — Имеется поддержка транзакций.
• — Возможность полнотекстового поиска без надстроек и дополнительных расширений.

PostgreSQL обладает большим числом преимуществ по сравнению с другими бесплатными СУБД. Важным моментом для выбора данной СУБД является возможность полнотекстового поиска из «коробки», а также хранение данных в типах JSON и XML, т.к. предполагается, что модель будет храниться в формате XML, а дополнительные данные в формате JSON.

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

• 1. Для каждой написанной уникальной функции для автономных (standalone) серверов создаются исходящие (input) очереди и очереди вывода (output).
• 2. Для каждого узла определяется набор функций, которые он будет выполнять.
• 3. Каждый узел подписывается на очереди сообщений в соответствии с теми функциями, которые он может выполнять.
• 4. RabbitMQ автоматически распределяет входящие сообщения между подписанными на очередь (input) узлами по алгоритму round_robin.
• 5. Шина считывает сообщение, отправляет данные на требуемый обработчик.
• 6. По завершению выполнения функции, обработчик передает данные обратно шине, которая в свое время отправляет результат выполнения функции в очередь вывода (output).

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