메시징 시스템을 사용하여 멋지게 분리 된 워크 플로 시스템에있는 파일을 처리하는 데 몇 가지 빠른 스파이크를 수행합니다.
사람들이 위의 각 프레임 워크를 사용할 때 찾은 장단점은 무엇입니까? WCF 바인딩 및 / 또는 비 MSMQ 솔루션과 함께 수동 롤링 MSMQ 시스템과 비교하여 이러한 기능을 사용하면 어떤 이점이 있습니까?
답변
트랜잭션 처리 방법, 예외가 롤백을 유발하는 방법, 끝없이 롤백을 중지하는 방법 (포이즌 메시지)과 같이 제대로 처리해야하는 다소 어려운 사항이 많이 있으므로 수동으로 롤링 된 솔루션은 사용하지 않는 것이 좋습니다. 장기 실행 워크 플로와 통합하여 상태 관리 경계가 정렬되도록하는 방법 등
일종의 내구성 / 트랜잭션 메시징 인프라를 원할 것이므로 MSMQ를 사용하지 않으면 Microsoft 플랫폼의 Service Broker 또는 ActiveMQ와 같은 다른 대안이 남게됩니다. MSMQ는 그렇지 않은 Service Broker와 달리 모든 Windows 컴퓨터에 이미 설치되어 있다는 이점이 있습니다.
NServiceBus, Mass Transit 및 Rhino Service Bus 중에서 선택하는 측면에서 NServiceBus와 MassTransit을 비교하는 이 Stackoverflow 답변 은 시작하기에 좋은 곳입니다.
3.1 릴리스에서는 더 높은 수준의 추상화에서 시스템을 모델링하고 NServiceBus의 구성 및 초기화를 자동으로 수행 할 수있는 Visual Studio 통합 모델링 도구 세트 인 NSB Studio를 도입했습니다. 나는 이것이 정말로 NServiceBus에 찬성하는 비늘을 팁이라고 말하고 싶습니다.
도움이 되었기를 바랍니다.
면책 조항 : 저는 NServiceBus의 저자입니다.
답변
NServiceBus 는 좋은 제품이지만 라이센스 문제에주의하십시오. 저자가 원하는대로 라이선스 정책을 변경하는 경향이 있습니다. 예를 들어 이전 라이센스 정보를 살펴보십시오 .
프로젝트 개발 도중에 NServiceBus에 많은 돈을 지불해야한다는 것을 알게 될 수 있습니다.
또한 무료 버전에는 성능 제한이 있습니다.
MassTransit 은 완전 무료 오픈 소스이며 제한이 없으며 Apache 2.0 라이선스를 따릅니다.
Rhino Service Bus를 사용하지 않았습니다 .
답변
Rhino와 NServicebus의 상태 업데이트 :
http://www.infoq.com/news/2012/04/nservicebus3-0
InfoQ to Ayende : 이전에 .NET 용 서비스 버스, 즉 Rhino 서비스 버스를 직접 작성했습니다. Rhino Service Bus 사용자는 이제 다시 고려하여 NServiceBus로 이동해야합니까?
Ayende : 2008 년경에 Rhino 서비스 버스를 만들었습니다. 당시 다른 서비스 버스의 상태가 마음에 들지 않았기 때문에 주로 만들었습니다. 서비스 버스를 만들 때 고민과 방향이 달랐지만 4 년 전 일입니다. 그 당시 NServiceBus는 사용하기 쉬운 제품이되고 훨씬 더 나은 개발 스토리를 얻는 데 큰 진전을 이루었다 고 생각합니다. 오늘 서비스 버스로 시작했다면 내 자신의 버스를 만들지 않을 것입니다.
답변
MSMQ 기반의 잠재적 단점은 최대 메시지 크기에 대한 제한입니다. IIRC는 약 4MB로 대용량 파일을 처리하고 메시지 내에 파일 내용을 저장하는 경우 쉽게 실행할 수 있습니다.
답변
