Применение асинхронного обмена информацией в веб-приложениях

Web-приложение – это интернет-приложение с архитектурой «клиент – сервер», где клиентом является браузер, а сервером – веб-сервер. Логика его распределена между клиентом и сервером, по сети реализуется обмен информацией, преимущественно, на сервере происходит хранение данных [1].

Web-приложения можно разделить на несколько типов:

• 1.    Backend, иными словами серверная часть приложения, работает на удаленном компьютере. Ее можно написать на разных языках программирования: С#, PHP, Python и так далее.

• 2.    Frontend, что означает клиентская часть приложения, выполняется в браузере

• 3.    SPA или одностраничное приложение. Здесь используются и backend, и frontend. Благодаря этому можно реализовать приложение, которое будет работать без перезагрузок страницы в браузере или, когда переходы вызывают перезагрузку, но при этом действия в разделе обходятся без них.

Web-приложения содержат большое количеств кода, который выполняется как часть цикла HTTP – запроса или ответа (рис. 1). Это подходит для более быстрых задач, которые могут быть выполнены в течение сотен миллисекунд. Но любая обработка, которая займет более секунды, будет слишком медленной для синхронного выполнения [2].

пользователя. Пишется на языке программирования Javascript.

Рис. 1

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

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

Рис. 2

Традиционная база данных плохо подходит для случаев асинхронной обработки. Существуют два аспекта у любой асинхронной обработки:

• 1.    Служба, которая создает задачи обработки.

• 2.    Служба, которая использует и обрабатывает эти задачи.

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

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

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

Этот интерфейс соединяет производителей, которые создают сообщения, и потребителей, которые после их обрабатывают. В контексте веб-приложения одним из распространенных случаев является то, что производитель – это клиентское приложение, которое создает сообщения на основе взаимодействия с пользователем [3]. В этом случае потребителем являются задачи rake, которые после могут обрабатывать поступающие сообщения (рис. 3).

Рис. 3

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

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

Помимо всего очереди сообщений могут обеспечить большую видимость объема сообщений.

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

Существует десятки очередей сообщений со всевозможными именами и функциями. AMQP и STOMP являются новыми открытыми стандартными протоколами для очередей сообщений (рис. 4).

Рис. 4

Одной из хорошо поддерживаемым очередями сообщений общего назначения является RabbitMQ.

Лучше всего для веб-приложения Ruby или Python выбирать RabbitMQ на AMQP.

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