Estoy luchando con una lista de pros y contras con respecto a NServiceBus y MassTransit.
Ahora sé que ya hay un hilo aquí, pero realmente no responde a mis preguntas.
Esto es lo que he leído hasta ahora:
- NServiceBus, sí, tiene licencia y no es gratis.
- MassTransit, sí, es de código abierto, pero la documentación parece faltar algo.
NServiceBus es más antiguo y tiene más referencias. Es difícil encontrar cosas sobre MassTransit, pero soy de mente abierta. Sin embargo, tengo que ofrecer una solución sólida, por lo que tengo que preguntar.
Así que, por favor, alguien con experiencia con ambos marcos. ¿Por qué debería elegir NServiceBus? O ¿Por qué debería elegir MassTransit?
¿Es rendimiento, seguridad, escala o?
.net
nservicebus
esb
masstransit
Jack Andersen
fuente
fuente
Como autor original de NServiceBus, probablemente estoy un poco inclinado hacia mi propia tecnología, pero intentaré mantener esto lo más equilibrado posible.
Soporte de transporte
Tanto NServiceBus como MassTransit son compatibles con RabbitMQ y Azure Service Bus , pero NServiceBus también admite:
Sobre el tema de RabbitMQ
Se podría argumentar que NServiceBus tiene un mayor soporte para RabbitMQ, por ejemplo, en su funcionalidad de entrega retrasada, mientras que Mass Transit afirma que su "complemento todavía se considera experimental. Es compatible con MassTransit, pero no podemos garantizar nada más que el complemento se garantiza a sí mismo ".
También trabajamos muy de cerca con el equipo de RabbitMQ, contribuyendo al .net SDK en beneficio de todo el ecosistema.
Cuando se trata de Azure Service Bus
El nivel de colaboración que tenemos con el equipo de Azure Service Bus es aún mayor, con más de 70 RP en su SDK principal de .net .
Cuando utiliza NServiceBus, se beneficia de la profundidad total de ese conocimiento.
Estampación
Ésta es la mayor diferencia.
Una vez que haya construido un sistema sustancial, tener visibilidad de cómo se comunican las diferentes partes móviles se vuelve realmente importante. MassTransit no tiene mucho en esta área más allá de una pequeña integración a través de una fuente de diagnóstico con herramientas de terceros como Application Insights o Open Trace.
La plataforma de servicio en torno a NServiceBus va un poco más allá y le brinda la capacidad de ver diagramas de secuencia en todos los puntos finales con ServiceInsight :
También puede obtener la vista lógica de todos sus puntos finales y mensajes:
En esencia, obtiene documentación viva de la arquitectura de su sistema.
Gestión y seguimiento
Esta es otra área en la que MassTransit no tiene mucho. Cuando un sistema de terceros con el que se está integrando deja de estar disponible y un montón de mensajes en su sistema terminan en la cola de errores, la única solución que MassTransit tiene para que usted mueva manualmente esos mensajes más tarde utilizando el complemento RabbitMQ Shovel .
La plataforma de servicio alrededor de NServiceBus incluye el monitoreo de esa cola de errores, herramientas gráficas para ver cuáles fueron las causas de esos errores, así como la capacidad de reproducir grupos de esos mensajes fallidos y ver que en realidad se procesaron con éxito, todo en una aplicación web simple. llamado ServicePulse .
También hay una visualización de comprobaciones de estado que se ejecutan periódicamente y que pueden proporcionar advertencias tempranas de problemas antes de que los mensajes comiencen a fallar.
Y finalmente, está el monitoreo de rendimiento disponible en la plataforma:
Realmente obtiene el paquete completo cuando se trata de soporte de producción.
Soporte a largo plazo y compatibilidad con versiones anteriores
Si bien la gente de Mass Transit siempre ha sido extremadamente buena para ayudar a cualquiera que tenga preguntas al respecto en Gitter o su Grupo de Google , no creo que proporcionen correcciones de errores en versiones anteriores. Cuando sus sistemas de producción han existido durante un par de años, y no puede simplemente actualizar todo todo el tiempo, eso comienza a ser importante.
Con NServiceBus, el soporte incluye :
Consultoría y formación
Desde una perspectiva fuera de línea, hay cursos públicos disponibles en todo el mundo en NServiceBus, así como muchos consultores que se pueden llevar al sitio para iniciar un proyecto o ayudar en caso de problemas. Escuché de varias empresas que decidieron cambiar de MassTransit a NServiceBus porque no podían conseguir a alguien en el sitio cuando lo necesitaban.
Licencia
Lo que algunas personas aún no saben sobre NServiceBus es que es GRATIS para uso personal y para empresas emergentes .
Cuando se trata de uso comercial , los modelos de licencia en torno a NServiceBus son muy flexibles, como indica el amplio espectro de clientes, y pueden estar bien justificados para la administración. Por supuesto, con MassTransit, la licencia es gratuita.
Espero que eso ayude de algún modo.
fuente
Sé que es tarde para intervenir en esta pregunta, pero por el bien de bingleability, tengo que mencionar a Rebus (que resulta que soy el autor principal).
Rebus tiene ahora unos 8 años y se ha utilizado para mover dinero y controlar plantas de energía desde el principio.
Es compatible con la mayoría de los sistemas de cola básicos, como MSMQ, RabbitMQ, Azure Service Bus, Azure Storage Queues, Amazon SQS, etc., pero también admite cosas más divertidas como el uso de MSSQL, PostgreSQL y Oracle como transportes.
La wiki de documentación es bastante completa, aunque muchas personas parecen arreglárselas, porque las API de Rebus son fácilmente detectables.
Rebus siempre ha sido (y siempre será) completamente gratis. Tiene licencia del MIT, por lo que básicamente puedes hacer con él lo que te apetezca.
Si termina siendo un usuario serio de Rebus y necesita un acuerdo de soporte formal y herramientas adicionales, puede suscribirse a Rebus Pro , que ofrece Rebus FM (la empresa detrás de Rebus).
Las "herramientas adicionales" mencionadas anteriormente vienen actualmente en forma de Fleet Manager , que puede ayudar con las cosas. Por ejemplo, Fleet Manager reemplaza completamente las colas de errores , por lo que los mensajes fallidos se almacenan allí. Esto significa que los mensajes fallidos se pueden ver, administrar y reintentar en cualquier momento con unos pocos clics en Fleet Manager.
fuente
Siempre puede usar Shuttle (FOSS): https://github.com/Shuttle/shuttle-esb :)
Documentación (siempre mejorando): http://shuttle.github.io/shuttle-esb/
El proyecto Shuttle lleva casi 2 años y se utilizan sistemas de producción. Será cuestión de elegir lo que resuene contigo.
NServiceBus tiene un buen historial. Lo he usado anteriormente en un sistema de producción (1.9) pero no desde que se volvió comercial (el punto en el que comencé con Shuttle).
No he probado MassTransit.
Supongo que todas tus opciones tendrán lo básico (comando / evento / pub-sub). Sin embargo, NServiceBus tiene sagas y el material del bus de datos, aunque creo que es bastante fácil manejar datos fuera del bus de servicio en sí, como en los controladores de mensajes de su punto final. No sé si MassTransit tiene sagas / bus de datos, pero Shuttle ciertamente no lo tiene.
Otra consideración es probablemente cómo piensa usar el autobús de servicio. Si va a ser parte de un producto, entonces, para una opción comercial como NServiceBus, deberá considerar las implicaciones de costos para los usuarios de su producto y, aunque todavía es algo que debe tenerse en cuenta para el desarrollo interno, ciertamente puede serlo. justificado.
fuente
Solo para dar una respuesta más actualizada, he desarrollado profesionalmente con ambos ecosistemas y ambos ahora admiten una amplia gama de tecnologías MQ y .NET Core.
Usé NServicebus hace unos años en un nuevo producto en la nube, necesitábamos .NET Core que Mass Transit no admitía en ese momento. Debo decir que es algo encantador para usar como desarrollador, hay muchas frases interesantes, excelentes herramientas / monitoreo y la documentación es realmente buena.
Hay varios niveles de soporte y licencia disponibles, y en la única ocasión en que necesitamos ayuda, fue de buena calidad.
He estado usando Mass Transit durante unos meses en una nueva empresa y prefieren tener una biblioteca gratuita de código abierto. El viaje ha sido un poco más complicado: la documentación para MT falta en algunos lugares y muchos ejemplos / problemas están desactualizados. Tampoco existe la gama de funciones avanzadas, pero es posible que no las necesite para su caso de uso.
Sin embargo, funciona bien y los desarrolladores de MT parecen poner MUCHO esfuerzo en admitir su OSS, mucho más de lo que razonablemente podría esperar.
Entonces, personalmente, mi TLDR sería: obtenga NServicebus si su empresa puede estar convencida de que lo pague, pero MT es una alternativa útil y lo mejor que puede obtener de forma gratuita.
fuente