몇 년 전에 저는 같은 질문을 던졌습니다. NServiceBus를 다른 메시지 대기열과 함께 사용하기 위해 조사했지만 문제는 동일했습니다.
나는 NServiceBus를 사용하지 않기로 결정했습니다.
6 개월 후, NServiceBus가 수행 한 작업의 절반을 다시 작성했음을 깨달았습니다 ... 단지 훨씬 열악했습니다.
왜 RabbitMQ와 함께 NServiceBus가 필요한지와 비슷한 질문은 ASP.NET MVC, WinForms 또는 XAML 또는 .NET Framework와 함께 .NET Framework가 필요한 이유를 묻는 것입니다. Common Language Runtime을 가지고있을 때 함께 배송됩니다.
결국 CLR로 충분하지 않아야합니까?
물론 아닙니다. MSIL 인터프리터와 실행 엔진과 같이 코드를 실행할 수있는 런타임을 갖는 것이 생산성 향상에 충분하지 않습니다.
물론 입력을 받아 출력을 생성하는 명령 줄 응용 프로그램을 작성할 수 있습니다. 그러나 내장 된 SQL Server 드라이버없이 공용 라이브러리없이 실제 응용 프로그램을 빌드하십시오. 타사 컨트롤이나 라이브러리없이 System.Windows 네임 스페이스없이 Windows 데스크톱 응용 프로그램을 작성하십시오.
컬렉션, 데이터베이스 액세스, 창 개체 및 UI 컨트롤을 제공하려면 라이브러리가 필요합니다.
마찬가지로 RabbitMQ는 시작과 작업에 필요한 모든 것을 제공하지만 생산성을 유지하기에 충분하지 않습니다.
물론, RabbitMQ 용 .NET 드라이버를 가져 와서 메시지 생성 및 사용을 시작할 수 있습니다.
잠시 동안은 정상적으로 작동합니다.
곧 드라이버를 둘러싼 래퍼가 생성되므로 작성해야하는 코드의 양을 줄일 수 있습니다.
그러면 ack와 nack을 처리해야 할 필요가 있음을 알게 될 것입니다. 간단한 API를 만들면됩니다.
그런 다음 데드 - 레터 대기열에 대한 필요성이 nack 호출로 팝업되고,이를 API에 랩핑 할 것입니다. 물론 rabbitmq 드라이버에 비해 간단합니다.
결국 포이즌 메시지, 즉 형식이 잘못되어 예외가 발생하는 메시지를 처리해야합니다. 다시 한번 말하지만, 일회용 코드를 작성하지 않으므로이를 처리 할 라이브러리를 작성합니다.
목록이 계속 켜져 있습니다.
6 개월 후, NServiceBus (또는 MassTransit 또는 기타 서비스 버스 라이브러리를 선택하는 것)의 가치와 기능을 모방 한 절반 밖에 작성되지 않은, 거의 지정되지 않은 테스트 할 수없는 라이브러리로 작업하게 될 것입니다.
NServiceBus를 사용해야한다고 말하지 않습니다. 그리고 RabbitMQ가 없으면 RabbitMQ가 어떻게 작동하는지 배워야한다고합니다. 그러나 일단 메시지를 보내고받는 기본 사항을 벗어나면 NServiceBus 및 기타 서비스 버스 구현의 가치는 매우 분명하고 매우 빠르게됩니다.
두 번째 [관련 질문] (http://stackoverflow.com/questions/9558128/specific-advantages-of-nservicebus-over-plan-rabbitmq) – vappolinario
@vappolinario 감사합니다. 카프카도 마찬가지입니까? – MJK
나는 카프카를 전혀 사용하지 않으므로 – vappolinario