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

У меня была такая же проблема и она была решена, возможно, не лучшим образом, но она работает. Я заменил все разрывы строк до того, как достиг своего реального соответствия:

mystring= Regex.Replace(mystring, "\r\n", "")

Я манипулирую HTML, поэтому разрывы строк для меня в этом случае не имеют большого значения.

Я попробовал все вышеперечисленные предложения без везения, я использую .Net 3.5 FYI

13
задан Bob Aman 9 October 2009 в 02:02
поделиться

6 ответов

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

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

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

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

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

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

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

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

15
ответ дан 1 December 2019 в 20:01
поделиться

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

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

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

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

4
ответ дан 1 December 2019 в 20:01
поделиться

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

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

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

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

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

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

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

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

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

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

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

4
ответ дан 1 December 2019 в 20:01
поделиться

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

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

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

4
ответ дан 1 December 2019 в 20:01
поделиться

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

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

3
ответ дан 1 December 2019 в 20:01
поделиться

Один очень "близкий к требованию" пример из реального проекта. Кто работает от нескольких лет. В ActiveMQ

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

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

  • Каждая система индивидуальна (например, язык, дизайн и т. Д.)

  • Мы написали для каждой компании адаптер «очень специальной ИТ-системы для ActiveMQ»

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

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

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

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

2
ответ дан 1 December 2019 в 20:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: