Брокер сообщений (Kafka, RabbitMQ) VS Service Bus (nServiceBus) - PullRequest
Новая
       28

Брокер сообщений (Kafka, RabbitMQ) VS Service Bus (nServiceBus)

0 голосов
/ 26 июня 2018

Я много читал о трех упомянутых системах. Но я все еще не уверен, что использовать. Кажется, все они выполняют то, что мне нужно:

Я хочу, чтобы клиентская служба / службы обновлялась, когда другая служба запускает событие / команду / сообщение. В настоящее время я использую WCF службы, и клиентская служба может активно запрашивать обновленные данные из других служб. Это должно быть изменено с помощью брокера сообщений / служебной шины. Мне также все равно, если клиент выходит из сети и не получает обновлений, так как при выходе в Интернет он автоматически получает самые последние данные через WCF в любом случае. Вот почему я думаю, Kafka - неправильный подход. С другой стороны, я развертываю это программное обеспечение в контексте безопасности в других компаниях. А поскольку это унаследованное приложение (без докера или простого развертывания), для установки Erlang необходимо открыть все порты для RabbitMQ. Это оставляет меня с NServiceBus.

  1. Пропускаю ли я что-то решающее, когда запускаю только NServiceBus вместо часто встречающегося варианта RabbitMQ+NServiceBus?

  2. Кажется, если я использую исключительно стек .net, у меня хорошо получается NServiceBus?

  3. Поскольку у меня уже есть WCF для запроса обновленных данных, следует ли отправлять команду только для инициирования вызова WCF. Или вы должны сами отправить обновленные данные через систему обмена сообщениями?

1 Ответ

0 голосов
/ 27 июня 2018

Примечание: я являюсь разработчиком в Particular Software, создателем NServiceBus. Я прошу прощения, если это звучит слишком много, как реклама.

Так как у меня уже есть WCF для опроса обновленных данных

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

MSMQ, RabbitMQ, Azure Service Bus, Amazon SQS - все это технологии очередей, хотя MSMQ немного отличается, так как это больше стиль шины и распределен по машинам.

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

Чтобы ответить на конкретные вопросы

  1. Если вы используете NServiceBus, вам все еще нужна технология организации очередей, которую мы называем transport. Либо MSMQ, либо RabbitMQ, либо все, что вы хотите.
  2. Конечно, но встроенная интеграция все еще возможна, как вы делали бы при обмене сообщениями между Java и .NET
  3. Это зависит. Отправка этого сообщения обычно более надежна и быстрее / проще, потому что вам не нужно делать вызов WCF. Кроме того, вы можете медленно удалять WCF, и вам нужно меньше разработчиков со знаниями WCF.

Если у вас есть дополнительные вопросы, не стесняйтесь обращаться к нам по телефону https://particular.net/support/

...