менеджер очередей что это
Очереди на очереди: Magento 2 + RabbitMQ
Привет! Меня зовут Павел и я Magento 2 бэкенд-разработчик. Когда-то давно, когда я только начинал знакомство с Magento 2 (для краткости буду называть ее M2), мне понадобилось автоматизировать обработку однотипных событий при разработке одного решения. Тогда я удивился, насколько мало информации на русском языке об интеграции очередей в M2. Время идет, а ситуация не меняется: информации об этом на просторах рунета все так же мало. Раскроем эту тему. Для начала кратко поговорим про очереди: что это такое и зачем они нужны, потом рассмотрим интеграцию M2 с популярным менеджером очередей Rabbit MQ (далее по тексту — RMQ), а также напишем простую реализацию работы с очередями в качестве примера. Погнали!
Менеджеры очередей
Менеджеры очередей обеспечивают асинхронную процедуру обмена данными между элементами одной системы или разными системами. Для хранения сообщений используются очереди. Менеджер через обменник (exchange) принимает сообщение (некие данные) от издателя (publisher) и помещает в именованную очередь (queue), откуда их может запросить потребитель (consumer) и определенным образом обработать.
Использование менеджеров очередей обладает рядом преимуществ, вот главные из них:
Слабая связанность издателя и потребителя — данные подсистемы работают асинхронно, используя менеджер очередей в качестве посредника, что обеспечивает возможность независимой модификации систем при условии неизменности интерфейсов;
Экономия и балансировка потребления ресурсов — использование очередей позволяет избежать дублирования сообщений, а также обеспечивает возможность управления потреблением вычислительных ресурсов, затрачиваемых на обработку сообщений;
Гарантия сохранения данных — менеджер очередей обеспечивает сохранность данных в случае непредвиденного отказа издателя или потребителя;
Асинхронная обработка данных позволяет публиковать и обрабатывать сообщения независимо, в разных потоках, системах и в разное время.
Это далеко не полный список преимуществ, однако достаточный для понимания удобства использования очередей, а также случаев, когда такое использование уместно.
«Из коробки» М2 умеет интегрироваться с RMQ, чего достаточно для подавляющего большинства сценариев использования очередей. На хабре есть отличный сериал про RMQ от пользователя @artemmatveev, рекомендую ознакомиться для углубленного понимания того, как это работает (ну и, конечно же, официальную документацию никто не отменял). В рамках данной статьи нам будет достаточно базовых сведений.
Интеграция RMQ в M2
Условимся, что RMQ у нас установлен, настроен и работает. Если нет, то нужно обратиться к первоисточнику, после чего вернуться к данной статье. Наиболее частый сценарий использования — RMQ установлен на том же сервере, что и M2. Но это не обязательно, поскольку RMQ является полностью независимым, и для подключения к нему нам нужно знать хост, порт и реквизиты доступа (об этом чуть ниже).
Итак, RMQ работает, теперь нужно подружить M2 с ним. Для этого идем в /app/etc/env.php и добавляем такой раздел:
Выполняем bin/magento setup:upgrade для достижения эффекта. Если все компоненты работают корректно, то работа завершена: теперь M2 умеет общаться с RMQ.
Процедуру настройки также можно выполнить сразу при установке M2. Для этого в команду bin/magento setup:install нужно добавить необходимые параметры, например:
Настоятельно рекомендую установить плагин для RMQ, который называется Management, это позволит через браузер настраивать конфигурацию RMQ, просматривать очереди и делать много всего полезного (в том числе убедиться, что все работает как надо).
В очередь!
Обожаю совмещать теорию с практикой, поэтому сейчас мы реализуем процесс с поддержкой очередей в М2.
Создадим стандартный модуль М2. Условимся, что у нас уже есть реализация объекта (модель, ресурс-модель и т.д.), которую назовем по традиции WhiteRabbit.
Теперь нам нужно объявить несколько сущностей, для этого создадим несколько xml файлов в папке etc нашего модуля.
communication.xml — задает общую конфигурацию для взаимодействия модуля с очередью сообщений.
Создаем топик с именем white.rabbit и задаем интерфейс, реализация которого описывает объект, содержащийся в запросе.
Полное описание XML-схемы этого файла можно найти на странице документации.
queue_consumer.xml — описываем потребителя, назначаем ему очередь, которую он будет слушать, а также класс и метод, которые будут обрабатывать сообщения, полученные из очереди.
Полное описание XML-схемы этого файла можно найти на странице документации.
queue_topology.xml — объявляем обменники, роутинг и очереди.
Здесь мы создаем обменник с именем rshb.white.rabbit, а также привязываем к нему топик white.rabbit и очередь white_rabbit в качестве пункта назначения.
Полное описание XML-схемы этого файла можно найти на странице документации.
queue_publisher.xml — объявляем издателя, привязываем его к топику и указываем обменник, который будет им использоваться.
Полное описание XML-схемы этого файла можно найти на странице документации.
Пришла очередь написать объявленные классы. Описываем потребителя:
На этом наша реализация готова. Попробуем что нибудь положить в очередь:
На данном этапе потребитель должен получить сообщение из очереди и каким-то образом его обработать (метод processMessage в классе потребителя). По умолчанию cron-задача запускает потребителя 1 раз в секунду (потребителю можно задать произвольный период опроса очереди путем указания атрибута sleep элемента consumer в файле queue_consumer.xml ).
На этом наша демонстрационная реализация очередей в M2 закончена.
Выводы
Интеграция в RMQ и M2 легко настраивается, но, вместе с тем, обладает отличной гибкостью и позволяет использовать все штатные возможности RMQ, причем как с размещением RMQ на том же сервере, так и на отдельном. Использование RMQ в связке с M2 заметно повышает и так незаурядные способности M2 к расширению.
На этом все. Пишите код с удовольствием и используйте правильные решения. До встречи!
Менеджеры очередей: общее представление и настройка
5.3. Менеджер очередей сообщений
Менеджер очередей сообщений служит для приложения точкой входа в инфраструктуру. Подключившись к своему менеджеру, оно может отправлять с помощью него сообщения очередям под управлением других менеджеров очередей сообщений в инфраструктуре очередей.
Для обеспечения движения сообщений от одного менеджера к другому каждый менеджер в инфраструктуре должен иметь сетевое соединение с теми из менеджеров, которым он может маршрутизировать сообщения. По мере своего продвижения от приложения-отправителя в итоговую очередь назначения сообщение может проходить целый ряд менеджеров.
5.3.1. Наименование менеджеров очередей
Все менеджеры имеют свое название. Оно должно быть уникальным в инфраструктуре, что позволяет каждой очереди в ее пределах быть уникальным местом назначения сообщений. Название менеджера используется при установлении соединения и указании местоположения очереди в составе инфраструктуры.
Контроль за уникальностью названий менеджеров очередей сообщений WebSphere MQ осуществляет только в отношении менеджеров, работающих на одной и той же машине.
Немаловажен и выбор подходящего названия менеджера, которое может отражать характер его использования, название и местоположение машины.
При назначении имен менеджерам очередей сообщений советуем не забывать о росте инфраструктуры, в том числе появлении дополнительных менеджеров на тех же самых машинах, или слиянии нескольких инфраструктур WebSphere MQ в будущем.
После того как менеджер очередей создан, переименовать его невозможно. Для смены имени менеджера он должен быть удален и создан повторно. Это касается и всех его элементов конфигурации.
WebSphere MQ полностью поддерживает как названия из букв смешанного регистра, так и названия, отличные только регистром букв. Однако, во избежание проблем в применении приложений, подключаемых к менеджерам очередей сообщений или пересылающих сообщения очередям, относитесь к использованию регистра символов с осторожностью.
5.3.2. Объекты WebSphere MQ
Значительная часть этой главы будет посвящена типам объектов, которые могут входить в состав менеджера очередей сообщений, их описанию и настройке, а также функциональности объектов каждого типа. Примерами объектов, которые мы подробнее рассмотрим в этой главе, являются:
Имеется немало разнообразных системных объектов, которые мы по отдельности обсудим в соответствующих разделах этой главы. Заметим, что ни один системный объект не подлежит удалению администратором. По характеру применения эти объекты можно разделить следующим образом:
Несколько системных объектов выступают в роли объектов по умолчанию для выполнения конкретных функций. Обычно для подмены функциональности этих объектов администраторам рекомендуется создавать собственные объекты, отвечающие их собственным соглашениям об именах.
Для каждого из типов объектов существует системный объект с именем вида
Каждый вновь созданный объект этого типа по умолчанию наследует атрибуты однотипного с ним системного объекта по умолчанию. Изменение свойств системного объекта по умолчанию приводит к изменению атрибутов новых объектов того же типа, однако не изменяет атрибуты объектов, которые уже существуют. Кроме того, объект может быть создан на базе атрибутов любого другого объекта того же типа, определенного ранее. В этом случае говорят, что новый объект похож (like) на имеющийся в системе.
5.3.3. Группы с разделением очередей в WebSphere MQ для z/OS
WebSphere MQ для z/OS работает на аппаратной платформе мейнфреймов IBM @Eserver zSeries 
под управлением операционной системы z/OS. В этой книге экземпляр z/OS, способный функционировать в логическом разделе (LPAR), мы чаще всего будем называть образом (z/OS image).
WebSphere MQ для z/OS базируется на функциях платформы z/OS и имеет дополнительные, недоступные на прочих платформах возможности, наиболее значимой из которых являются группы с разделением очередей (QSG).
Множество являющихся членами QSG менеджеров очередей сообщений имеют доступ к содержащимся в QSG общим очередям (shared queues). Любая общая очередь QSG доступна всем образующим группу менеджерам, подобно тому как если бы она управлялась менеджером локально.
Сказанное означает, что одно приложение, подключенное к менеджеру очередей сообщений, может поместить сообщение в общую очередь, а другое приложение, связанное с другим менеджером очередей сообщений в той же QSG-группе, может оттуда его извлечь.
При отказе от применения общих очередей сообщений его пришлось бы передавать в очередь под управлением второго менеджера, пересылая по распределенному или кластерному каналу до того, как второе приложение смогло его получить.
Другое значимое преимущество QSG заключается в том, что при возникновении сбоя в одном из менеджеров в составе подобной группы другие менеджеры этой же QSG смогут продолжить обрабатывать данные из общих для данной группы очередей.
В основу QSG-групп заложены функции, реализуемые объединением нескольких образов z/OS в сисплекс (sysplex). Все менеджеры очередей сообщений – члены QSG-группы должны располагаться в пределах образов z/OS одного сисплекса.
Сисплекс включает в себя устройство сопряжения (CF – coupling facility), которое дает возможность ряду образов z/OS в сисплексе иметь совместные данные. WebSphere MQ для z/OS использует устройство сопряжения совместно с функциональностью системы баз данных IBM DB2 .
В силу этого обстоятельства каждый входящий в QSG менеджер очередей сообщений должен иметь доступ и к DB2. Экземпляры БД DB2, к которым обращаются менеджеры очередей в QSG, должны располагаться в одной и той же группе с разделением данных (data-sharing group). Группа с разделением данных – это одна из возможностей DB2, дающая возможность множеству экземпляров баз данных совместно пользоваться хранилищем информации.
WebSphere MQ для z/OS использует устройство сопряжения и DB2 для обеспечения коллективного доступа к описанию очереди и сообщениям в ней всех менеджеров очередей сообщений, являющихся членами QSG. После описания очереди для одного менеджера в QSG-группе доступ к этой разделяемой очереди получает каждый менеджер QSG.
Каждая QSG-группа имеет свое название. Правила именования QSG совершенно аналогичны описанным выше правилам для имен менеджеров очередей в WebSphere MQ для z/OS.
5.3.4. Структура и создание менеджера очередей
Подробное изложение нюансов работы менеджера выходит за рамки курса. Однако в этом разделе мы приведем обзор ряда платформ WebSphere MQ Version 6.0. При обсуждении каждой платформы мы подчеркнем самое основное.
WebSphere MQ для Windows
В WebSphere MQ для Windows менеджер очередей сообщений работает как совокупность процессов в операционной системе.
Каждый менеджер очередей владеет и поддерживает определенный набор файлов в файловой системе машины.
Каталог данных менеджера очередей сообщений содержит определения объектов, данные сообщений, а также прочие данные менеджера. По умолчанию путь к этому каталогу имеет вид:
Файлы, содержащие журнал менеджера очередей сообщений. Журнализацию мы обсудим в «Менеджеры очередей: общее представление и настройка» » Журнализация «. По умолчанию путь к этим файлам имеет вид:
Входящее в указанные пути название_менеджера может частично не совпадать с реальным названием менеджера очередей сообщений. Подробнее о построении входящего в состав пути имени каталога из названия менеджера читайте в руководстве WebSphere MQ System Administration Guide, SC34-6584. Основное различие между ними состоит в том, что неалфавитные символы в названии менеджера заменяются в имени каталога: символ «.» меняется на «!», символ «/» на «&».
Базовая информация о настройках менеджера очередей сообщений хранится в реестре Windows. Она включает информацию о подходе к журнализации менеджера и настройках протокола коммуникации. Вносимые в эту информацию изменения не видны менеджерам, работающим в текущий момент, пока они не остановлены и не запущены снова.
Менеджер очередей сообщений в WebSphere MQ для Windows может быть создан следующими путями.
Команда WebSphere MQ crtmqm описана в части 6 » WebSphere MQ control commands» руководства WebSphere MQ System Administration Guide, SC34-6584.
Параметры, заданные при создании менеджера, имеют значения по умолчанию. Последние вместе с другой не относящейся к конкретному менеджеру информацией о настройках WebSphere MQ хранятся в реестре Windows.
WebSphere MQ для UNIX
В WebSphere MQ для платформ UNIX менеджер очередей сообщений работает как совокупность процессов в операционной системе.
Каждый менеджер очередей владеет и поддерживает определенный набор файлов в файловой системе машины.
Каталог данных менеджера очередей сообщений содержит определения объектов, данные сообщений, а также прочие данные менеджера. По умолчанию путь к этому каталогу имеет вид:
Файлы, содержащие журнал менеджера очередей сообщений. Журнализацию мы обсудим в «Менеджеры очередей: общее представление и настройка» » Журнализация «. По умолчанию путь к этим файлам имеет вид:
Входящее в указанные пути название_менеджера может частично не совпадать с реальным названием менеджера очередей сообщений. Подробнее о построении входящего в состав пути имени каталога из названия менеджера читайте в разделе » Understanding WebSphere MQ file names» руководства WebSphere MQ System Administration Guide, SC34-6584. Основное различие между ними состоит в том, что неалфавитные символы в названии менеджера заменяются в имени каталога: символ «.» меняется на «!», символ «/» на «&».
В нем содержится информация об организации журнализации менеджера и настройках протоколов коммуникации. Вносимые в эту информацию изменения не видны менеджерам, работающим в текущий момент, пока они не остановлены и не запущены снова.
Зачем нужны очереди сообщений в микросервисной архитектуре: разбираем преимущества и недостатки
При проектировании микросервисов часто возникает вопрос: какой способ связи между ними выбрать.
Многие отдают предпочтение RESTful API. Однако этот подход не всегда эффективен, так как в отдельных случаях чреват долгим ожиданием на клиентской стороне и потерей информации в случае сбоев.
Мы расскажем про такой вариант для взаимодействия микросервисов, как очереди сообщений, а также попытаемся выяснить, для каких сценариев они подходят лучше всего. Разобраться в вопросе нам помог Павел Юдин, руководитель команды облачных продуктов, Tarantool / VK.
Sync vs Async: синхронное и асинхронное взаимодействие
Очереди сообщений (Message Queue) — это форма асинхронной коммуникации между сервисами. Поэтому, прежде чем говорить о них, покажем на упрощенном, немного искусственном примере разницу между синхронным и асинхронным взаимодействием.
Предположим, вы разрабатываете сайт книжного магазина и у вас есть сервис, к которому обращается пользователь, например отправка рецензии на прочитанную книгу. При нажатии кнопки «Отправить» вызывается некоторый API, который, в свою очередь, может обратиться к другим API.
При синхронном взаимодействии все запросы в этой цепочке вызовов выполняются строго друг за другом, а при выполнении последнего запроса ответы последовательно передаются в обратном направлении. В итоге пользователь вынужден пару секунд ждать сообщения о публикации своего отзыва, хотя его не интересуют особенности серверной обработки и он вполне обоснованно хочет увидеть сообщение сразу после нажатия кнопки. Конечно, время ожидания будет во многом определяться мощностью оборудования, но при пиковых нагрузках оно может стать серьезной проблемой.
Еще один недостаток такой схемы — обработка сбоев. Если на одном из шагов возникнет исключение, оно каскадно возвратится назад, и пользователь получит уведомление об ошибке с просьбой повторно отправить рецензию. Вряд ли кого-то обрадует получение подобного сообщения после длительного ожидания.
Синхронное взаимодействие на основе REST API
Описанную схему можно изменить, добавив асинхронные вызовы. Достаточно вызвать в асинхронном режиме первый REST API и параллельно вернуть пользователю сообщение о том, что его рецензия принята и будет размещена, например, в течение суток. В итоге сайт не блокируется, а вызовы всех последующих API происходят независимо от пользователя.
Но у такой схемы также есть существенный недостаток: в случае сбоя в одном из API информация, введенная пользователем, будет потеряна. Если в первом примере в случае ошибок достаточно повторно отправить рецензию, то здесь ее необходимо заполнить заново.
Вариант асинхронного взаимодействия на основе REST API
Для устранения недостатков обеих схем как раз и предназначены очереди сообщений.
Принципы работы очередей сообщений
Очереди предоставляют буфер для временного хранения сообщений и конечные точки, которые позволяют подключаться к очереди для отправки и получения сообщений в асинхронном режиме.
В сообщениях могут содержаться запросы, ответы, ошибки и иные данные, передаваемые между программными компонентами. Компонент, называемый производителем (Producer), добавляет сообщение в очередь, где оно будет храниться, пока другой компонент, называемый потребителем (Consumer), не извлечет сообщение и не выполнит с ним необходимую операцию.
Очереди поддерживают получение сообщений как методом Push, так и методом Pull:
Так как очереди могут использоваться несколькими производителями и потребителями одновременно, обычно их реализуют с помощью дополнительной системы, называемой брокером. Брокер сообщений (Message Broker) занимается сбором и маршрутизацией сообщений на основе предопределенной логики. Сообщения могут передаваться с некоторым ключом — по этому ключу брокер понимает, в какую из очередей (одну или несколько) должно попасть сообщение.
Вернемся к примеру с отправкой рецензии. Пусть та часть сервиса, к которому обращается пользователь, выступит в качестве производителя и будет направлять запросы на создание рецензий в очередь. Сразу после добавления сообщения в очередь пользователю можно направлять уведомление об успехе операции. Вся последующая логика обработки будет выполняться независимо от него на стороне потребителя, подписанного на очередь.
Завершив обработку, потребитель отправит подтверждение в очередь, после чего исходное сообщение будет удалено. Но если во время обработки произойдет сбой и подтверждение не будет получено вовремя, сообщение может быть повторно извлечено потребителем из очереди.
Вариант асинхронного взаимодействия на основе очереди сообщений
Польза и преимущества очередей сообщений в микросервисной архитектуре
Используя очереди сообщений в качестве основного средства взаимодействия микросервисов (Microservices Communication), можно добиться следующих преимуществ:
Отличительная черта микросервисов — их автономность. И очереди во многом помогают уменьшить зависимости между ними. Каждое сообщение, передаваемое в очереди, — это всего лишь массив байтов с некоторыми метаданными. Метаданные нужны для направления в конкретную очередь, а информация, содержащаяся в основной части (теле) сообщения, может быть практически любой. Брокер не анализирует данные, он выступает лишь в качестве маршрутизатора. Это позволяет настроить взаимодействие между компонентами, работающими даже на разных языках и платформах.
Очереди сообщений упрощают независимое масштабирование микросервисов. Наблюдая за состоянием очередей, можно масштабировать те сервисы, на которые приходится большая часть нагрузки. Кроме этого, очереди легко позволяют не только увеличивать число экземпляров существующих сервисов, но и добавлять новые с минимальным временем простоя. Все, что для этого требуется, — добавить нового потребителя, прослушивающего события в очереди.
Однако сами очереди также необходимо масштабировать, и это может создать дополнительные сложности.
Если один из сервисов не справляется с нагрузкой, требуется возможность запускать больше его экземпляров быстро и без дополнительных настроек. Обычно для этих целей используют балансировщик нагрузки, интегрированный с сервером обнаружения служб и предназначенный для распределения трафика. При использовании очередей сообщений сам брокер по умолчанию является балансировщиком нагрузки. Если несколько потребителей слушают очередь одновременно, сообщения будут распределяться между ними в соответствии с настроенной стратегией.
Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты.
Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.
Большинство брокеров выполняют аутентификацию приложений, которые пытаются получить доступ к очереди, и позволяют использовать шифрование сообщений как при их передаче по сети, так и при хранении в самой очереди. Таким образом, очередь снимает с ваших сервисов бремя организации авторизации запросов.
Варианты использования очередей сообщений
Очереди сообщений полезны в тех случаях, где возможна асинхронная обработка. Рассмотрим наиболее частые сценарии использования очередей сообщений (Message Queue use Cases):
Сюда можно отнести задачи, которые не связаны напрямую с основным действием пользователя сайта и могут быть выполнены в фоновом режиме без необходимости ожидания с его стороны. Это обработка изображений, преобразование видео в различные форматы, создание отзывов, индексирование в поисковых системах после изменения данных, отправка электронной почты, формирование файлов и так далее.
Очереди можно использовать в качестве буфера для некоторой массовой обработки, например пакетной вставки данных в БД или HDFS. Очевидно, что гораздо эффективнее добавлять сто записей за раз, чем по одной сто раз, так как сокращаются накладные расходы на инициализацию и завершение каждой операции. Но для стандартной архитектуры может стать проблемой генерация данных клиентской службой быстрее, чем их может обработать получатель. Очередь же предоставляет временное хранилище для пакетов с данными, где они будут храниться до завершения обработки принимающей стороной.
Многие системы очередей позволяют производителю указать, что доставка сообщений должна быть отложена. Это может быть полезно при реализации льготных периодов. Например, вы разрешаете покупателю отказаться от размещения заказа в течение определенного времени и ставите отложенное задание в очередь. Если покупатель отменит операцию в указанный срок, сообщение можно удалить из очереди.
Помещая данные в очередь, вы можете быть уверены, что данные будут сохранены и в конечном итоге обработаны, даже если это займет немного больше времени, чем обычно, из-за большого скачка трафика. Увеличить скорость обработки в таких случаях также возможно — за счет масштабирования нужных обработчиков.
Нестабильная сеть в сочетании с очередью сообщений создает надежный системный ландшафт: каждое сообщение будет отправлено, как только это будет технически возможно.
Многие брокеры поддерживают очереди FIFO, полезные в системах, где важно сохранить порядок транзакций. Если 1000 человек размещают заказ на вашем веб-сайте одновременно, это может создать некоторые проблемы с параллелизмом и не будет гарантировать, что первый заказ будет выполнен первым. С помощью очереди можно определить порядок их обработки.
Очереди часто применяют для сбора некоторой статистики, например использования определенной системы и ее функций. Как правило, моментальная обработка такой информации не требуется. Когда сообщения поступают в веб-службу, они помещаются в очередь, а затем при помощи дополнительных серверов приложений обрабатываются и отправляются в базу данных.
Если у вас есть некоторая задача для группы серверов, то вам необходимо выполнить ее на каждом сервере. Например, при редактировании шаблона мониторинга потребуется обновить мониторы на каждом сервере, использующем этот шаблон. Вы можете поставить сообщение в очередь для каждого сервера и выполнять их одновременно в виде небольших операций.
Это обработка финансовых транзакций, бронирование авиабилетов, обновление записей о пациентах в сфере здравоохранения и так далее.
Сложности использования и недостатки очередей сообщений: как с ними справляться
Несмотря на многочисленные преимущества очередей сообщений, самостоятельное их внедрение может оказаться довольно сложной задачей по нескольким причинам:
Хорошая новость в том, что многие облачные провайдеры сейчас предлагают очереди как сервис (MQ as a Service). Поэтому если у вас недостаточно ресурсов для самостоятельной настройки и поддержки очередей сообщений, то можно воспользоваться одним из готовых решений. Большинство из них включает автоматизацию настройки, масштабирование, диагностику ошибок и техническую поддержку, а также поддерживает строго однократную доставку в очередях FIFO.
В каких случаях очереди неэффективны
Конечно, очереди не являются универсальным средством для любых приложений. Рассмотрим варианты, когда очереди не будут самым эффективным решением:
Выбирая инструмент для будущего приложения, обязательно взвесьте все за и против. Не стоит использовать очереди сообщений для задач, которые могут быть решены другим, более простым в настройке и обслуживании способом. Но в тех случаях, когда запланирован переход на микросервисы и бизнес-логика допускает возможность асинхронной обработки, очереди сообщений могут стать лучшим выбором для повышения производительности и надежности вашего продукта.
Если вы заинтересованы в использовании очередей, но опасаетесь, что команда не справится с их конфигурированием и последующей поддержкой самостоятельно, всегда можно воспользоваться одним из Managed-решений, представленных на рынке.