NServiceBus 및 MassTransit에 관한 장단점 목록으로 어려움을 겪고 있습니다.
이제 여기에 이미 스레드가 있다는 것을 알고 있지만 실제로 내 질문에 답하지 않습니다.
지금까지 읽은 내용은 다음과 같습니다.
NServiceBus는 오래되었으며 더 많은 참조를 가지고 있습니다. MassTransit에 대해 찾기는 어렵지만 개방적입니다. 그러나 저는 견고한 솔루션을 제공해야하므로 물어봐야합니다.
두 프레임 워크에 대한 경험이있는 사람을 부탁드립니다. NServiceBus를 선택해야하는 이유는 무엇입니까? 또는 MassTransit을 선택해야하는 이유는 무엇입니까?
성능, 보안, 규모 또는?
답변:
요약해야한다면 다음과 같이 말합니다.
상업적 지원이 필요한 경우 NServiceBus로 이동하십시오. 포럼을 지원 수단으로 사용하는 데 익숙하다면 MassTransit이 훌륭한 옵션입니다. 개발자들은 지금까지 우리 문제에 매우 반응했습니다. MassTransit을 선택하면 이제 MSMQ와 RabbitMQ 중에서 선택하게됩니다. DTC가 필요한 경우 MSMQ를 사용하십시오. 더 많은 기능과 더 나은 관리를 원한다면 RabbitMQ를 사용하십시오.
프로젝트에서 다음 두 가지 이유로 NServiceBus에서 MassTransit으로 전환했습니다.
두 프레임 워크를 모두 사용했습니다. MassTransit을 NServiceBus보다 오래 사용했습니다. 내가 본 하이라이트는 다음과 같습니다.
비용:
지원하다:
수송:
RabbitMQ 대 MSMQ :
Udi Dahan과 MassTransit 직원 (Chris Patterson, Dru Sellers 및 Travis Smith)은 모두 훌륭한 사람들입니다.
NServiceBus의 원저자 인 저는 제 자신의 기술에 약간 편견이있을 수 있지만 가능한 한 균형을 유지하려고 노력할 것입니다.
NServiceBus 및 MassTransit 모두 RabbitMQ 및 Azure Service Bus 를 지원하지만 NServiceBus는 다음도 지원합니다.
RabbitMQ 주제에 대해
인수는 NServiceBus가 RabbitMQ에 대한 강한지지를 받고 있다고 할 수있다 - 예를 들어, 자사의 지연 배달 기능 대중 교통은 동안 상태 . 그것은 MassTransit 지원하는 그들의 "플러그인이 아직 실험으로 간주됩니다,하지만 우리는 더 많은 플러그인 이상의 보증 아무것도 할 수 없습니다 스스로를 보장합니다. "
또한 RabbitMQ 팀과 매우 긴밀하게 협력 하여 전체 생태계의 이익을 위해 .net SDK 에 기여합니다 .
Azure Service Bus의 경우
Azure Service Bus 팀과의 공동 작업 수준은 .net 코어 SDK에 대한 70 개 이상의 PR로 훨씬 더 높습니다 .
NServiceBus를 사용하면 해당 지식의 전체 깊이를 활용할 수 있습니다.
압형
이것이 가장 큰 차이점입니다.
상당한 시스템을 구축 한 후에는 모든 다른 움직이는 부품이 서로 어떻게 대화하는지에 대한 가시성을 확보하는 것이 정말 중요해집니다. MassTransit은 진단 소스 를 통해 Application Insights 또는 Open Trace와 같은 타사 도구에 대한 소규모 통합 외에는이 영역에서 그다지 많지 않습니다 .
NServiceBus 주변의 서비스 플랫폼은 훨씬 더 발전하여 ServiceInsight를 사용 하여 모든 엔드 포인트에서 시퀀스 다이어그램을 볼 수있는 기능을 제공합니다 .
또한 모든 엔드 포인트 및 메시지의 논리적보기를 얻을 수 있습니다.
본질적으로 시스템 아키텍처에 대한 살아있는 문서를 얻을 수 있습니다.
관리 및 모니터링
이것은 MassTransit에 그다지 많지 않은 또 다른 영역입니다. 통합하고있는 타사 시스템을 사용할 수 없게되고 시스템의 많은 메시지가 오류 대기열에 들어가면 MassTransit이 나중에 RabbitMQ Shovel 플러그인을 사용하여 해당 메시지를 수동으로 다시 이동할 수있는 유일한 솔루션 입니다.
NServiceBus 주변의 서비스 플랫폼에는 해당 오류 대기열의 모니터링, 해당 오류의 원인을 확인하는 그래픽 도구, 실패한 메시지 그룹을 재생 하고 간단한 웹 앱에서 모두 성공적으로 처리되었는지 확인 하는 기능이 포함됩니다. ServicePulse 라고 합니다.
메시지가 실패하기 시작하기 전에 문제에 대한 조기 경고를 제공 할 수있는 주기적으로 실행되는 상태 확인의 시각화도 있습니다.
마지막으로 플랫폼에서 사용할 수 있는 성능 모니터링이 있습니다.
프로덕션 지원과 관련하여 실제로 전체 패키지를 얻을 수 있습니다.
장기 지원 및 이전 버전과의 호환성
Mass Transit 직원은 항상 Gitter 또는 Google 그룹 에서 질문이있는 모든 사람을 돕는 데 매우 능숙했지만 , 이전 버전에서 버그 수정을 제공하지 않는다고 생각합니다. 프로덕션 시스템이 몇 년 동안 사용되어 왔고 항상 모든 것을 업그레이드 할 수는 없을 때 중요하기 시작합니다.
컨설팅 및 교육
오프라인 관점에서 볼 때 NServiceBus에 대한 전 세계의 공개 과정은 물론 프로젝트를 시작하거나 문제 발생시 도움을주기 위해 현장에 올 수있는 많은 컨설턴트가 있습니다. 필요로 할 때 현장에 누군가를 모을 수 없기 때문에 MassTransit에서 NServiceBus로 전환하기로 결정한 여러 회사로부터 들었습니다.
라이센싱
일부 사람들은 여전히 NServiceBus에 대해 알지 못합니다 . 개인용 및 신생 기업 에게는 무료 라는 것입니다 .
이에 관해서 상업적 사용 , NServiceBus 주변의 라이센싱 모델은 고객의 폭 넓은 스펙트럼을 나타냅니다으로, 매우 유연하고 잘 관리 정당화 될 수있다. 물론 MassTransit에서는 라이센스가 무료입니다.
어떤면에서 도움이되기를 바랍니다.
나는이 질문에 대한 차임에 늦었다는 것을 알고 있지만, 폭행 가능성을 위해 나는 Rebus 를 언급해야한다 .
Rebus는 이제 약 8 년이되었으며 처음부터 자금을 이동하고 발전소를 제어하는 데 사용되었습니다.
MSMQ, RabbitMQ, Azure Service Bus, Azure Storage Queues, Amazon SQS 등과 같은 대부분의 기본 대기열 시스템을 지원하지만 MSSQL, PostgreSQL 및 Oracle을 전송으로 사용하는 것과 같은 더 재미있는 항목도 지원합니다.
Rebus의 API는 매우 쉽게 발견 할 수 있기 때문에 많은 사람들이 사용하는 것 같지만 문서 위키 는 상당히 포괄적입니다.
Rebus는 항상 완전히 무료였습니다. MIT 라이센스이므로 기본적으로 원하는대로 할 수 있습니다.
진지한 Rebus 사용자가되어 공식적인 지원 계약과 추가 도구가 필요한 경우 Rebus FM (Rebus 뒤에있는 회사)에서 제공하는 Rebus Pro를 구독 할 수 있습니다 .
위에서 언급 한 "추가 도구"는 현재 작업에 도움이 될 수있는 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)에서 사용했지만 상용화 (셔틀로 시작한 시점) 이후로는 사용하지 않았습니다.
MassTransit을 시도하지 않았습니다.
모든 옵션에는 기본 (명령 / 이벤트 / pub-sub)이있을 것입니다. 그러나 NServiceBus에는 끝점 메시지 처리기에서와 같이 서비스 버스 자체 외부의 데이터를 처리하는 것이 충분히 쉽다고 생각하지만 sagas 및 데이터 버스 항목이 있습니다. MassTransit에 sagas / data 버스가 있는지 여부는 모르지만 Shuttle은 확실히 그렇지 않습니다.
또 다른 고려 사항은 아마도 서비스 버스를 사용하는 방법입니다. 제품의 일부인 경우 NServiceBus와 같은 상용 옵션의 경우 제품 사용자에 대한 비용 영향을 고려해야하며 여전히 사내 개발을 위해 고려해야 할 사항이지만 확실히 그럴 수 있습니다. 정당화.
최신 답변을 제공하기 위해 두 에코 시스템을 모두 전문적으로 개발했으며 이제 둘 다 광범위한 MQ 기술과 .NET Core를 지원합니다.
저는 몇 년 전에 새로운 클라우드 제품에서 NServicebus를 사용했지만 당시 Mass Transit에서 지원하지 않았던 .NET Core가 필요했습니다. 개발자로서 사용하는 것은 정말 멋진 일이고, 멋진 하나의 라이너, 훌륭한 툴링 / 모니터링, 그리고 문서가 정말 훌륭합니다.
다양한 수준의 지원과 라이센스를 사용할 수 있으며 한 번은 도움이 필요했지만 좋은 품질이었습니다.
저는 새 회사에서 몇 달 동안 Mass Transit을 사용해 왔으며 무료 오픈 소스 라이브러리를 선호합니다. 여정은 좀 더 불안정했습니다. MT에 대한 문서는 장소가 부족하며 많은 예제 / 문제가 오래되었습니다. 고급 기능의 범위도 많지 않지만 사용 사례에는 필요하지 않을 수 있습니다.
그래도 잘 작동하고 MT 개발자는 OSS 지원에 많은 노력을 기울이는 것 같습니다.
그래서 개인적으로 제 TLDR은-귀사가 비용을 지불 할 수 있다고 확신 할 수 있다면 NServicebus를 받으십시오. 그러나 MT는 서비스 가능한 대안이며 무료로 얻을 수있는 최선의 방법입니다.