Описание архитектуры веб-приложения

Приложение физически разделено на 2 части. Первая часть представляется собой пользовательский веб-интерфейс, написанный на клиентских технологиях JavaScript, CSS3 и HTML5. Для написания клиентской логики была выбрана современная ревизия языка JavaScript — ECMAScript 6. Причина данного выбора заключается в более удобном API для работы с коллекциями и массивами, а также технология управления асинхронными операциями Promises. Данная версия языка поддерживается подавляющим большинством современных и актуальных браузеров последних версий.

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

Для реализации структурного паттерна Model-View-ViewModel используется библиотека VueJS. Этот паттерн является аналогом паттерна Model-View-Controller и позволяет разделить бизнес-логику, модель данных и представление на 3 независимые компоненты, а VueJS инкапсулирует механизм двусторонней привязки данных (Model) и представлений (View) через легковесную прослойку (ViewModel), с последующим взаимным обновлением состояния.

Поскольку данная библиотека является достаточно молодой, она вобрала многие полезные функции и возможности таких фреймворков и библиотек, как AngularJS, React и jQuery, предоставляя разработчику очень простой API для работы. Именно за счет агрегирования полезных и нужных функций, а также своей простоты была выбрана именно эта библиотека.

Вторая часть клиент-серверного веб-приложения так же физически разделена на 2 части. Это приложение, принимающее запросы от клиента и выводящее главную веб-страницу системы, и абстрагированный от остального кода модуль обработки изображений, который реализует работу сверхточной нейронной сети SRCNN. Данный модуль был вынесен в отдельную библиотеку, поскольку помимо веб-интерфейса (GUI) был разработан интерфейс командной строки (CLI), поэтому привязка к одному из них в рамках данного модуля была недопустимой.

Серверная часть веб-приложения реализована на фреймворке ASP.net Core, который может реализовать работу веб-приложения как в рамках стандартного для Windows веб-сервера IIS, так и в рамках собственного процесса (отдельный саморазвёртываемый веб-сервер для приложения). Так же для возможности развертывания приложения на операционной системе Linux все проекты были написаны для сборки на новой версии платформы.net Core.

Поскольку процесс масштабирования изображения является достаточно долгим при большой загрузке сервера и большом размере изображений, взаимодействие ASP.net приложения и модуля SRCNN осуществляется через брокера очередей сообщений RabbitMQ. Данный брокер является наиболее популярным бесплатным решением, реализующим протокол для очередей сообщений Advanced Message Queuing Protocol (AMQP) [22], а также имеет реализацию для платформы.net Core, что являлось основной мотивацией выбора RabbitMQ для данной задачи.

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

Рисунок 0.1. Мониторинг очередей RabbitMQ.

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

Для реализации асинхронной операции получения увеличенного изображения в брокере сообщений RabbitMQ создано три очереди: ImageInput, ImageProgress и ImageOutput. При получении изображения от клиента, Asp.net приложение формирует объект сообщения для очереди, помещая само изображение в бинарном виде в тело сообщения (Body) и присваивая данной задаче уникальный идентификатор Guid, который прикрепляется ко всем сообщениям, связанным с данной задачей, например, к сообщениям об изменении статуса процесса масштабирования изображения или к сообщению о получении конечного результата. После инициализации сообщения, оно помещается в очередь ImageInput, а клиентской части приложения возвращается тикет, с помощью которого оно периодически опрашивает Asp.net приложение о состоянии задачи. Модуль SRCNN получает сообщение из очереди ImageInput, извлекает из него тикет и изображение, и запускает процесс обработки изображения. При изменении этапа или статуса задачи, модуль SRCNN так же асинхронно отправляет сообщение с данными о текущем статусе в очередь ImageProgress, прикрепляя к нему сохраненный в самом начале тикет задачи. Данные сообщения получает приложение Asp.net, когда к нему приходит запрос на получение последнего актуального состояния задачи с указанным тикетом. При окончании операции, Asp.net приложение получает результат из очереди ImageOutput. Диаграмма последовательностей для процесса отправки файла и получения изображения представлена в Приложении B. Модуль масштабирования может работать как с очередью сообщений, так и через папки, которые имитируют очереди. Последнее использовалась для проведения интеграционных тестов, описанных далее. В Приложении C представлена диаграмма классов модуля масштабирования.

Алгоритм масштабирования так же был переработан по сравнению с предыдущей версией, описанной в рамках курсовой работы. Оптимизация заключается в распараллеливании процессов масштабирования изображения, путем разделения изображения на блоки одинаковых размеров, которые обрабатываются алгоритмом в разных потоках. Так же используется для этих целей библиотека Task Parallel Library, входящая в число стандартных библиотек платформы.net, позволяет задействовать сразу несколько ядер процессора. Таким образом на многоядерных вычислительных машинах процесс будет выполнятся ещё быстрее. Одним из основных достижений применения очередей сообщений и оптимизированного распараллеленного алгоритма является превращения приложения в горизонтально масштабированную систему. Для повышения пропускной способности возможно добавить дополнительные вычислительные машины, что невозможно было реализовать в предыдущем решении на базе клиентского Javascript-приложения. Архитектура приложения представлена на Рисунке 3.4:

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

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