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

8 мин

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

Хранилище очередей Azure
Служебная шина Azure

Что такое хранилище очередей Azure?

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

Что такое очереди сервисной шины Azure?

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

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

Что такое темы служебной шины Azure?

Темы Azure Service Bus похожи на очереди, но могут иметь нескольких подписчиков. Когда сообщение отправляется в тему, а не в очередь, могут быть активированы несколько компонентов для выполнения своей работы. Представьте, что пользователь слушает песню в приложении для обмена музыкой. Мобильное приложение может отправить сообщение в раздел Listened. В этой теме будет подписка для UpdateUserListenHistory и отдельная подписка для UpdateArtistsFanList. Каждая из этих функций обрабатывается другим компонентом, который получает собственную копию сообщения.

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

Преимущества очередей

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

Повышение надежности

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

Гарантии доставки сообщений

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

при-Least-Once доставке: В этом подходе гарантируется доставка каждого сообщения как минимум одному из компонентов, извлекающих сообщения из очереди. Обратите внимание, что в определенных обстоятельствах возможно, что одно и то же сообщение доставляется более одного раза. Например, если есть два экземпляра веб-приложения, извлекающего сообщения из очереди, обычно каждое сообщение переходит только к одному из этих экземпляров. Однако, если один экземпляр тратит много времени на обработку сообщения, и время ожидания истекает, сообщение может быть отправлено другому экземпляру. Код веб-приложения должен быть разработан с учетом этой возможности.
ДоставкаMost-Once: в этом подходе доставка каждого сообщения не гарантируется, и есть небольшая вероятность того, что оно может не дойти. Однако в отличие от доставки типа at-Least-Once, нет шансов, что сообщение будет доставлено дважды. Иногда это называется автоматическое обнаружение дубликата.
first-In-First-Out (FIFO): в большинстве систем обмена сообщениями сообщения обычно покидают очередь в том же порядке, в котором они были добавлены, но следует учитывать, гарантируется ли эта доставка. Если распределенное приложение требует, чтобы сообщения обрабатывались точно в правильном порядке, необходимо выбрать систему очередей, содержащую гарантию FIFO.

Поддержка транзакций

Некоторые тесно связанные группы сообщений могут вызвать проблемы при сбое доставки одного сообщения в группе.

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

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

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

Какую службу следует выбрать?

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

Используйте очереди шины Service Bus, если вы:

Требуется гарантия доставки для At-Most-Once.
Требуется гарантия FIFO.
Необходимо сгруппировать сообщения в транзакции.
Хотите получать сообщения без опроса очереди.
Необходимо предоставить очередям модель доступа на основе ролей.
Необходимо обрабатывать сообщения размером более 64 КБ, но менее 100 МБ. Максимальный размер сообщения, поддерживаемый стандартным уровнем, составляет 256 КБ, а уровень "Премиум" составляет 100 МБ.
Размер очереди не увеличится больше 1 ТБ. Максимальный размер очереди для уровня "Стандартный" составляет 80 ГБ, а для уровня "Премиум" — 1 ТБ.
Желаете публиковать и потреблять пакеты сообщений.

Используйте топики Service Bus, если вы:

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

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

Используйте хранилище очередей, если вы:

Требуется аудиторский журнал всех сообщений, проходящих через очередь сообщений.
Ожидается, что размер очереди превысит 1 ТБ.
Хотите отслеживать ход выполнения обработки сообщения внутри очереди.

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

Используйте очереди хранилища, если вам нужна простая в реализации система очередей. Для более сложных потребностей используйте очереди Service Bus. Если вам нужно направить одно сообщение в несколько пунктов назначения, но требуется поведение очереди, используйте топики Service Bus.