Зачем вам использовать систему на основе сообщений?

Question

Каковы мотивы использования системы на основе сообщений?

Я много вижу об сервисных автобусах, таких как NServiceBus и Mass Transit , и мне интересно, каковы преимущества базовой методологии.

Answer 1

Использование систем на основе сообщений дает множество преимуществ.

1. Сообщения образуют четко определенный технологически нейтральный интерфейс между приложениями.
2. Обеспечивает слабое связывание приложений.
3. Множество вариантов производительности, настройки и масштабирования:
   • Разверните инициатор запроса и процесс обслуживания на другом оборудовании.
   • Несколько инициаторов запросов используют один сервер
   • Несколько инициаторов запроса используют несколько серверов
4. Различные промежуточные программы обмена сообщениями реализуют общие шаблоны обмена сообщениями независимо от вашего приложения.
   • Запрос / ответ
   • Отключить и забыть офлайн-обновления
   • Опубликовать / подписаться
5. Многие промежуточные продукты обрабатывают преобразование сообщений (например, SWIFT в SWIFTXML).
6. Многие промежуточные продукты могут разбивать один большой запрос на несколько более мелких запросов.
7. Почти все они поддерживают несколько платформ.

Между прочим, двумя лидерами рынка в этой области являются IBM с их Websphere MQ и сопутствующими продуктами и TIBCO со своей Enterprise Service Bus.

Answer 2

Архитектура на основе сообщений разделяет производителей и потребителей сообщений как во времени, так и в пространстве.Это дает много преимуществ:

• производители и потребители могут работать на разных машинах.
• производители и потребители могут работать в разное время.
• производители и потребители могут работать на разных аппаратных / программных платформах (им нужно понимать только один и тот же протокол сообщений)
• легко координировать работу нескольких производителей / потребителей (например, для ресурсоемких задач, требующих нескольких машин, как описал Дэйв Маркл)
• более высокая стабильность, когда услуги временно недоступны (например, при обработке заказа использование системы обмена сообщениями может помочь избежать "отбрасывания" заказов)

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

Answer 3

Один из вариантов использования - это когда у вас есть пул ресурсов, которые могут работать с данным элементом, и список работ, которые необходимо распределить масштабируемым образом.

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

Answer 4

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

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

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

Не думайте, что архитектуры передачи сообщений требуют необычных (и дорогих!) промежуточных программных продуктов, Windows работает на архитектуре передачи сообщений - каждое сообщение WM_ *, передаваемое окну, является… ну, сообщением, и я думаю, что показывает лучший пример архитектуры - ни одна часть системы не должна знать ни о какой другой части, вы можете расширять ее бесконечно, поскольку вы можете обрабатывать столько элементов управления, сколько захотите в любом диалоге и т. д. и т. д.

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

Answer 5

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

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

Также есть преимущества асинхронной связи (например, электронная почта или онлайн-чат), а также возможности маршрутизации и преобразования сообщений.

Answer 6

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

Сама система обмена сообщениями имеет настраиваемые конвейеры, обрабатывающие каждое сообщение. Вот несколько примеров разработанных нами конвейеров:

• Хранилище (создано / сохранено сообщение в базе данных)
• Маршрутизация (проработано, куда нужно отправить сообщение)
• Безопасность (срабатывает, если клиенту было разрешено его получить)
• Удалить (работает, если сообщение необходимо удалить из системы, что означает, что клиенты должны быть уведомлены, а сообщение удалено из кеша и помечено в БД).
• TakeOwnership (гарантирует, что только один клиент может изменять состояние сообщения за раз, поскольку можно изменять только сообщения, которые принадлежат ему)

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