Я борюсь со списком плюсов и минусов относительно NServiceBus и MassTransit.
Теперь я знаю, что здесь уже есть ветка, но она не отвечает на мои вопросы.
Вот что я прочитал:
- NServiceBus, да, он лицензирован и не предоставляется бесплатно.
- MassTransit, да, это открытый исходный код, но в документации, похоже, чего-то не хватает.
NServiceBus старше и содержит больше ссылок. Трудно найти что-нибудь о MassTransit, но я непредубежден. Однако я должен предложить твердое решение, поэтому я должен спросить.
Итак, пожалуйста, кто-нибудь с опытом работы с обоими фреймворками. Почему я должен выбрать NServiceBus? ИЛИ Почему мне следует выбрать MassTransit?
Это производительность, безопасность, масштаб или?
.net
nservicebus
esb
masstransit
Джек Андерсен
источник
источник
Как первоначальный автор NServiceBus, я, вероятно, немного предвзято отношусь к моей собственной технологии, но я постараюсь сохранить это как можно более сбалансированным.
Транспортная поддержка
И NServiceBus, и MassTransit поддерживают RabbitMQ и служебную шину Azure , но NServiceBus также поддерживает:
По теме RabbitMQ
Можно привести аргумент, что NServiceBus имеет более сильную поддержку RabbitMQ - например, в своей функции отложенной доставки, в то время как Mass Transit заявляет, что их «плагин по-прежнему считается экспериментальным. Он поддерживается MassTransit, но мы не можем гарантировать ничего, кроме плагина. гарантирует себя ".
Мы также очень тесно сотрудничаем с командой RabbitMQ, внося свой вклад в SDK .net на благо всей экосистемы.
Что касается служебной шины Azure
Уровень нашего сотрудничества с командой служебной шины Azure еще выше, с более чем 70 PR для их SDK ядра .NET .
Когда вы используете NServiceBus, вы извлекаете выгоду из всей глубины этих знаний.
Инструменты
Это самая большая разница.
После того, как вы построили прочную систему, становится действительно важно видеть, как все различные движущиеся части взаимодействуют друг с другом. MassTransit не имеет ничего особенного в этой области, кроме небольшой интеграции через источник диагностики со сторонними инструментами, такими как Application Insights или Open Trace.
Сервисная платформа вокруг NServiceBus идет немного дальше, давая вам возможность видеть диаграммы последовательности на всех конечных точках с помощью ServiceInsight :
Вы также можете получить логическое представление обо всех ваших конечных точках и сообщениях:
По сути, вы получаете живую документацию по архитектуре вашей системы.
Управление и мониторинг
Это еще одна область, в которой у MassTransit не так много. Когда сторонняя система, с которой вы интегрируетесь, становится недоступной, а куча сообщений в вашей системе оказывается в очереди ошибок, у MassTransit есть единственное решение, позволяющее вручную переместить эти сообщения обратно позже с помощью плагина RabbitMQ Shovel .
Платформа обслуживания вокруг NServiceBus включает в себя мониторинг этой очереди ошибок, графические инструменты, чтобы увидеть, каковы причины этих ошибок, а также возможность воспроизводить группы этих неудачных сообщений и видеть, что они действительно были успешно обработаны в простом веб-приложении. называется ServicePulse .
Также существует визуализация периодических проверок работоспособности, которые могут обеспечить раннее предупреждение о проблемах до того, как сообщения начнут выходить из строя.
И, наконец, в платформе доступен мониторинг производительности:
Когда дело доходит до производственной поддержки, вы действительно получаете полный пакет.
Долгосрочная поддержка и обратная совместимость
Хотя специалисты по Mass Transit всегда очень хорошо помогали всем, у кого есть вопросы по этому поводу в Gitter или своей группе Google , я не думаю, что они исправляют ошибки в старых версиях. Когда ваши производственные системы существуют уже пару лет, и вы не можете просто постоянно обновлять все, это становится важным.
С поддержкой NServiceBus входит :
Консультации и обучение
С точки зрения оффлайн, на NServiceBus есть общедоступные курсы, доступные по всему миру, а также множество консультантов, которых можно пригласить на место, чтобы запустить проект или помочь в случае возникновения проблем. Я слышал от нескольких компаний, которые решили перейти с MassTransit на NServiceBus, потому что они не могли найти кого-то на месте, когда им это было нужно.
Лицензирование
Что некоторые люди до сих пор не знают о NServiceBus, так это то, что он БЕСПЛАТНЫЙ для личного использования и стартапов .
Когда дело доходит до коммерческого использования , модели лицензирования NServiceBus очень гибкие, как показывает широкий спектр клиентов, и могут быть хорошо оправданы для руководства. Конечно, с MassTransit лицензирование бесплатное.
Надеюсь, что это каким-то образом поможет.
источник
Я знаю, что уже поздно вмешиваться в этот вопрос, но для удобства я должен упомянуть Ребуса (которого я являюсь основным автором).
Ребусу сейчас около 8 лет, и его с самого начала использовали для перемещения денег и управления электростанциями.
Он поддерживает большинство базовых систем очередей, таких как MSMQ, RabbitMQ, Azure Service Bus, Azure Storage Queues, Amazon SQS и т. Д., Но он также поддерживает более забавные вещи, такие как использование MSSQL, PostgreSQL и Oracle в качестве транспорта.
Вики-документация довольно обширна, хотя многие люди, кажется, обходятся этим, потому что API Rebus очень легко обнаруживаются.
Ребус всегда был (и всегда будет) полностью бесплатным. Он лицензирован MIT, так что вы можете делать с ним все, что хотите.
Если вы в конечном итоге станете серьезным пользователем Rebus и вам потребуется официальное соглашение о поддержке и дополнительные инструменты, вы можете подписаться на Rebus Pro , который предлагает Rebus FM (компания, стоящая за Rebus).
Упомянутый выше «дополнительный инструментарий» в настоящее время представлен в виде Fleet Manager , который может помочь с вещами. Например, Fleet Manager полностью заменяет очереди ошибок , поэтому сообщения с ошибками сохраняются там. Это означает, что неудавшиеся сообщения можно просматривать, управлять и повторять в любое время с помощью нескольких щелчков мышью в Fleet Manager.
источник
Вы всегда можете использовать Shuttle (FOSS): https://github.com/Shuttle/shuttle-esb :)
Документация (постоянно улучшается): http://shuttle.github.io/shuttle-esb/
Проект Shuttle реализуется почти 2 года и использует производственные системы. Это будет вопрос выбора того, что вам нравится.
NServiceBus имеет хорошую репутацию. Я использовал его ранее в производственной системе (1.9), но не с тех пор, как он стал коммерческим (момент, когда я начал с Shuttle).
Я не пробовал MassTransit.
Я думаю, все ваши параметры будут иметь основы (команда / событие / pub-sub). Однако у NServiceBus есть саги и материал о шине данных, хотя я считаю, что достаточно просто обрабатывать данные вне самой служебной шины, например, в обработчиках сообщений конечной точки. Я не знаю, есть ли у MassTransit саги / шина данных, но у Shuttle точно нет.
Еще одно соображение, вероятно, заключается в том, как вы собираетесь использовать служебную шину. Если он должен быть частью продукта, то для коммерческого варианта, такого как NServiceBus, вам нужно будет учитывать финансовые последствия для пользователей вашего продукта, и, хотя это все еще то, что необходимо учитывать для собственной разработки, оно, безусловно, может быть оправдано.
источник
Чтобы дать более свежий ответ, я профессионально разработал обе экосистемы, и теперь обе они поддерживают широкий спектр технологий MQ и .NET Core.
Несколько лет назад я использовал NServicebus в новом облачном продукте, нам требовалось .NET Core, которое Mass Transit в то время не поддерживал. Я должен сказать - это прекрасная вещь для использования в качестве разработчика, есть много хороших лайнеров, отличный инструментарий / мониторинг и действительно хорошая документация.
Доступны различные уровни поддержки и лицензии, и однажды нам потребовалась помощь, она была хорошего качества.
Я использую Mass Transit в течение нескольких месяцев в новой компании, и они предпочитают иметь бесплатную библиотеку с открытым исходным кодом. Путь был немного сложнее - документация по MT местами отсутствует, а многие примеры / проблемы устарели. Здесь также не так много дополнительных функций, но они могут вам не понадобиться для их варианта использования.
Тем не менее, он работает нормально, и разработчики MT, похоже, приложили ОЧЕНЬ много усилий для поддержки своего OSS - намного больше, чем вы могли ожидать.
Так что лично мой TLDR был бы таков: получите NServicebus, если ваша компания сможет убедить вас заплатить за него, но MT - это удобная альтернатива и лучшее, что вы можете получить бесплатно.
источник