И есть ли они? Для меня MB знает как подписчиков, так и издателей и выступает в качестве посредника, уведомляя подписчиков о новых сообщениях (фактически «push» модель). С другой стороны, MQ — это скорее модель «извлечения», когда потребители извлекают сообщения из очереди.

Я полностью сбился с пути?

Шина сообщений

Шина сообщений — это инфраструктура обмена сообщениями, позволяющая различным системам взаимодействовать через общий набор интерфейсов (шина сообщений).

Источник: EIP

Очередь сообщений

Основная идея очереди сообщений проста:

• Два (или более) процесса могут обмениваться информацией через доступ к общей системной очереди сообщений.

• Процесс отправки помещает через некоторый модуль передачи сообщений (OS) сообщение в очередь, которое может быть прочитано другим процессом

Источник: Дэйв Маршалл

Источник изображения

Разница

Очередь сообщений содержит правило FIFO (first in first out), тогда как в шине сообщений нет.

Заключение

Оба ВЫГЛЯДЯТ как выполнение одинаковой работы — передача сообщений между двумя приложениями или модулями или интерфейсами или системами или процессами, за исключением небольшой разницы в FIFO

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

ШИНА против ОЧЕРЕДИ — это действительно в некоторой степени устаревшая концепция, совсем недавно появившаяся в таких системах, как IBM MQ и Tibco Rendezvous. Изначально MQ была системой 1: 1, действительно очередью для разделения различных систем.

Tibco, напротив, была (продавалась как) магистраль обмена сообщениями, где у вас могло быть несколько издателей и подписчиков на одни и те же темы.

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

Однако фраза message-queue также используется для внутренних перекачиваний сообщений внутри потока и т.п., и в этом контексте использование действительно отличается. Если вы думаете о классической перекачке сообщений Windows, это действительно скорее модель извлечения, которую вы описываете, но на самом деле она больше внутри приложения, чем между приложениями или между ящиками.

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

ОЧЕРЕДЬ

Очередь сообщений получает сообщения от приложения и делает их доступными для одного или нескольких других приложений в порядке поступления-отправки (FIFO). Во многих архитектурных сценариях, если приложению A необходимо отправлять обновления или команды приложениям B и C, то для B и C. A могут быть настроены отдельные очереди сообщений для каждой очереди, и каждое зависимое приложение будет считывать из своей очереди (сообщение удаляется при удалении из очереди). Ни B, ни C не должны быть доступны, чтобы A отправлял обновления. Каждая очередь сообщений является постоянной, поэтому, если приложение перезапускается, оно начнет извлекать из своей очереди, как только оно снова подключится к сети. Это помогает разорвать зависимости между зависимыми системами и может обеспечить большую масштабируемость и отказоустойчивость приложений.

Автобус

Шина сообщений или служебная шина обеспечивают способ для одного (или нескольких) приложений передавать сообщения одному или нескольким другим приложениям. Может не быть гарантии упорядочения в порядке поступления, а подписчики на шину могут приходить и уходить без ведома отправителей сообщений. Таким образом, приложение A может быть написано для передачи обновлений статуса приложению B через шину сообщений. Позже будет написано приложение C, которое также может извлечь выгоду из этих обновлений. Приложение C можно настроить для прослушивания шины сообщений и выполнения действий на основе этих обновлений, не требуя никаких обновлений для приложения A. В отличие от очередей, где отправляющее приложение явно добавляет сообщения в каждую очередь, шина сообщений использует модель публикации / подписки. Сообщения публикуются на шине, и любое приложение, подписавшееся на такого рода сообщения, получит его. Этот подход позволяет приложениям следовать принципу «открыто / закрыто», поскольку они становятся открытыми для будущих изменений, оставаясь закрытыми для дополнительных модификаций.

Источник

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

Я вижу это так, что очередь сообщений создает шину сообщений. Затем клиенты (т. Е. Узлы) могут прослушивать шину сообщений. Это особенно верно для случая, когда у вас есть MQ, передающий сообщения через UDP, другими словами, он отправляет сообщения на широковещательный / многоадресный адрес, не зная и не заботясь о том, кто их получит. Для более подробного описания этого сценария вы можете ознакомиться с этой статьей .

Шина сообщений — это модель распределения «один ко многим». Адресат в этой модели обычно называется темой или темой. Одно и то же опубликованное сообщение получают все подписчики-потребители. Вы также можете назвать это «широковещательной» моделью. Вы можете думать о теме как об эквиваленте темы в шаблоне проектирования Observer для распределенных вычислений. Некоторые поставщики шины сообщений эффективно предпочитают реализовывать это как UDP вместо TCP. Для темы доставка сообщений — это «запуск и забвение» — если никто не слушает, сообщение просто исчезает. Если это не то, что вы хотите, вы можете использовать «долгосрочные подписки».

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

Я бы сказал, что в большинстве сред темы являются лучшим выбором, потому что вы всегда можете добавить дополнительные компоненты без необходимости изменять архитектуру. Добавленными компонентами могут быть мониторинг, ведение журнала, аналитика и т. Д. Вы никогда не знаете в начале проекта, какими будут требования через 1 год, 5 лет, 10 лет. Изменения неизбежны, примите их 🙂

Служебная шина — более общий термин, чем очередь сообщений.

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