은 NServiceBus가 유용합니까?

Question

방금 ​​nservicebus를 조사하기 시작했고, 내 상황에 적절하거나 어쩌면 과장 할 수도 없습니다. 건축 포인터가 크게 감사 드리며, 저는 조금 고심하고 있습니다.

나는 MVC 웹 사이트와 WCF REST 서비스를 가지고있어 둘 다 메시지를 받는다. "질문 게시". 이렇게하면 엔티티 저장, 규칙 엔진에 의한 검사, 푸시 메시지 전송, 일부 집계 데이터 업데이트와 같은 여러 작업이 트리거됩니다. 규칙 엔진의 결과로 인해 새 메시지가 작성 될 수도 있습니다. 이러한 요구 사항은 앞으로 변경 될 수 있습니다. 수신 엔드 포인트가 수신 대기중인 사람 (사람 X가 새 질문을 작성한)에게 메시지를 보내는 방식으로이를 구현하고 싶습니다.

DB 테이블에 메시지를 저장하고 모듈이 테이블을 모니터링하도록 생각했습니다. 이 생각 프로세스는 msmq로 이동 한 다음 nservicebus를 사용하여 pub sub로 이동했습니다. 그러나 이것이 어떻게 구현되어야하는지 잘 모르겠습니다.

현재 다음 시나리오에 대해 생각하고 있습니다. 질문이 WCF REST 서비스에 제공됩니다. WCF 서비스는 질문을 지속하고 새로운 질문 메시지를 게시합니다 (따라서 nservicebus를 어떻게 든 호스팅해야합니까?). 메시지에 가입 한 모듈은 알림을 보내거나 정의 된 규칙을 기반으로 작업을 실행하는 등의 조치를 취합니다.

nservicebus를 사용하는 pub sub가 나에게 도움이되는 시나리오입니까? 그리고 이것이 실제로 그것을 함축하는 방법일까요?

Answer 1

는 WCF 서비스는 질문을 계속하고 (그래서 어떻게 든 nservicebus 개최해야?) 새로운 질문 메시지를 게시

NServiceBus는 IIS를 포함하여 모든 관리 과정에서 호스팅 할 수

. 이렇게하려면 (WCF 서비스 내부)

• WCF 서비스가 시작될 때 IBus 인스턴스를 만듭니다.
• 서비스에 대한 질문 요청을 받으면 NServiceBus 메시지를 어셈블합니다.
• IBus.Publish (MyMessage)를 사용하여 메시지를 게시합니다.

IIS에서 IBus의 인스턴스를 생성하는 일반적인 방법은 전역 asmx에서 유창한 구성을 사용하는 것입니다. 일반적인 구성은 다음과 같습니다.

public class Global : System.Web.HttpApplication 
{ 
    public static IBus Bus { get; private set; } 

    void Application_Start(object sender, EventArgs e) 
    { 
     Bus = NServiceBus.Configure.WithWeb() 
      .Log4Net() 
      .DefaultBuilder() 
      .XmlSerializer() 
      .MsmqTransport() 
       .IsTransactional(false) 
       .PurgeOnStartup(false) 
      .UnicastBus() 
       .ImpersonateSender(false) 
      .CreateBus() 
      .Start(); 
    } 

웹을 사용하여 NServiceBus 끝점 (대기열)을 정의합니다.설정 :

귀하의 다운 스트림 가입자

각 아마 가장 쉬운 호스팅 옵션 Windows 서비스로 실행하는 NServiceBus 일반적인 호스트 내부에서 호스팅 할 수있는 메시지 테이크 액션에 가입

<configSections> 
    <section name="MsmqTransportConfig" 
      type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" /> 
</configSections> 

<MsmqTransportConfig InputQueue="WebFrontEnd" 
        ErrorQueue="error" 
        NumberOfWorkerThreads="1" 
        MaxRetries="5" /> 

내 모듈 . 구독자는 각각 IHandleMessages을 구현하는 메시지 처리기 클래스를 갖습니다. NServiceBus에서

방법 술집/서브 작품 :

1. 게시자 서비스는 입력 큐 및 가입 저장소가 있습니다.
2. 가입자 서비스는 게시자의 입력 큐에 가입 메시지를 보내드립니다 스타트 업에 입력 큐
3. 가입자를 가지고
구독 메시지는 메시지 가입자의 유형을 포함
4. 은 및 가입자 관심 대기열 주소
5. 게시자가 구독 저장소에 구독을 기록합니다.
6. 게시자가 메시지를받습니다.
7. 게시자는 구독 목록에 대해 메시지 유형을 평가합니다.
8. 일치하는 항목마다 게시자가 메시지를 대기열 주소로 보냅니다.

이 내용을 더 잘 이해하려면 NServiceBus pub-sub 샘플을 다운로드해야합니다.

Answer 2

WCF 대신 NSB를 사용하고 WCF를 사용하지 않을 것이라고 생각합니다. 서비스 버스는 많은 새로운 개념과 디자인을 도입합니다. 비동기 작업의 아이디어는 전통적인 요청/응답과는 매우 다릅니다.

시작하려면 요청/응답 설계가 병목 현상 자체가 될 때까지 서비스 버스를 도입해야합니다. 서비스 버스는 응용 프로그램에 "들어가는"것이 아닙니다. 기존 애플리케이션에 서비스 버스를 도입 할 때 명령/이벤트/메시지 처리가 궁극적 인 응답 인 & 요청을 사용하여 설계된 시스템에 어떻게 영향을 미치는지 생각해야합니다.

Answer 3

REST API가 GET을 처리한다고 가정하고 일부 PUT/POST/DELETE를 "비동기"호출로 전환하려고합니다. 기본 제공 WCF 통합 끝점을 사용할 수 있지만 SOAP 바인딩에 묶여 있습니다. REST를 해킹 할 수는 있지만 이제 GET과 다른 모든 끝 점이 본질적으로 2 개 있습니다.

우리는 다른 답변 (HttpModule 사용)과 비슷하지만 부트 스트래핑 NSB를 WCF에 통합했습니다. 변경 작업을 위해 메시지를 다른 종점에 Bus.Send()하여 클라이언트로 반환하면됩니다. 수신 엔드 포인트는 단순히 필요에 따라 메시지를 처리합니다.

논리의 파이프 라인이 필요한 경우에는 내장되어 있습니다. 정의 된 순서로 처리하기 위해 메시지 핸들러를 함께 끈으로 묶을 수 있습니다. 나는 이것이 당신이 바라는 효과라면 Pub/Sub가 전혀 필요 없다고 생각하고 있습니다. 이것은 엔드 포인트의 수를 줄입니다. 엔드 포인트에 과부하가 걸리면 디스트리뷰터를 추가하여 확장 할 수 있지만 그 또 다른 이야기입니다.