Может кто-нибудь объяснить, для чего используются брокеры сообщений?

Question

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

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

Answer 1

Решения очереди сообщений, такие как серии MQ или MSMQ, широко используются для интеграции распределенных корпоративных приложений, особенно работающих на разных платформах. Выполнено правильно (с постоянными очередями, асинхронным дизайном, а не «RPC over MQ» и вниманием к операционным требованиям), это дает вам высокую доступность по сравнению с синхронными интеграциями запросов и ответов, такими как RPC или шаблонные веб-службы (доступность которых является продуктом из соответствующих возможностей: интеграция десяти систем с 99% -ой доступностью синхронно дает вам общую доступность не более 90% - или хуже, если есть только одна слабая связь). Имейте в виду, для этого очереди сообщений должны иметь высокую доступность: мы используем наш мэйнфрейм для этой цели (предположим, какой продукт мы используем!).

Брокеры с сообщением (или интеграцией) и «автобусы» являются более сложным котлом рыбы. Они могут добавить

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Мы построили два разных варианта интеграции. Первым был подход ftp, где файлы фиксированной ширины были отправлены туда и обратно через регулярные промежутки времени, и мы добавили всевозможные правила, чтобы гарантировать, что мы не пропустили никаких данных.

Второй - это серия MQ, в которой сообщения помещались в очередь с использованием доставки guarenteed. Затем мы выходим в очередь и обрабатываем сообщения. Система queing была здесь очень полезной, поскольку она позволила нам надежный способ передачи критических сообщений, которые привели к перемещению реальных денег.

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

Вторым примером и на этот раз было использование MSMQ - это сайт, который собирал информацию из кода dialhome, введенного в клиентские приложения. Код dialhome собирал бы статистику использования функций, такую ​​как SQM-программа Microsoft.Когда сообщения поступали в веб-службу, мы бросали их в очередь. Тогда у нас могло бы появиться любое количество серверов приложений, которые появлялись бы в сообщениях и подталкивали их к базе данных, которая будет свернута на склад.

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

Answer 4

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

Очередь сообщений гарантирует, что сообщение будет доставлено ровно одному клиенту.

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

Answer 5

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

A a back назад (10 лет) Я использовал отправку метафоры для внедрения системы ценообразования на фронт-офис для посредника-посредника. У нас были сервисы, реализованные в C++, VB6 и Excel/VBA (даже с использованием решения Excel!), Хранилище данных в виде плоских файлов и sql, приложения для конечных пользователей, написанные в Excel и VB6, со сложной моделью данных (рыночные данные, доходность кривые и объемные поверхности). Асинхронный обмен сообщениями (с постоянными/надежными сообщениями и паб/суб) сделал все это очень эффективно и масштабируемо - мы смогли добавить офисы в Токио и Нью-Йорк в лондонскую инфраструктуру, даже не посетив удаленный сайт - просто установить стандартную версию болота.

Я большой поклонник, хотя я удивлен тем, как далеко они не появились за последние 10 лет или около того.

Answer 6

Один очень «близкий к требованию» является примером из настоящего проекта. Кто бежит с нескольких лет. On ActiveMQ

1) Торговый центр для рынка перевозок.

• Отгрузка compagny имеет систему, которая знает, сколько пакетов они могут отправить в режиме реального времени.

• Каждая система отличается (язык, дизайн ...)

• мы писали адаптер для каждого Compagny «очень специальная информационная система для ActiveMQ»

• Каждый адаптер имеет простую работу, чтобы сделать : post, когда у compagny есть свободное место и по какой цене. («транспортное предложение»)

• Мы написали клиента, который собирает все «транспортные предложения» и хорошо их отображать.

=> Ta-da. у вас есть перекрестная платформа/язык/система процессов, для compagny, которые не хотят разговаривать друг с другом.

=> Ta-da 2: Если новая торговая система захочет войти в вашу торговую систему, им нужно написать адаптер.