Masstransit/RabbitMQ에서 대기열을 구성하는 방법은 무엇입니까?

Question

메시지를 소비하는 모범 사례를 알고 싶습니다. MassTransit 문서를 읽었으며 이에 대해 조사했지만 어떤 결론에 도달하지는 않습니다.

게시 메시지 인 api (버스 인스턴스 호스팅)가 하나 있습니다. 이 API는 마이크로 서비스 (구매, 판매 등을위한 메시지)가 아니기 때문에 다양합니다.

소비자/대기열을 어떻게 구성해야합니까?

1. 큐 유형에 대해 하나의 프로세스가 필요합니까? 예를 들어, 구매 용으로, 판매용으로 기타 등등.이 솔루션에는 많은 프로세스가 필요할 수 있으며 좋은 솔루션인지 여부가 확실하지 않습니다. 구매와 같은 다른 대기열을 원할 경우 (예 : 구매, 구매, 공급 업체 등) 프로세스 번호가 상당히 증가 할 수 있습니다. 나는 이것이 확장 성을위한 좋은 선택이라고 생각하지만 많은 프로세스를 관리하는 것은 까다로울 수 있습니다.
2. 프로세스의 복수 대기열 (도메인별로 대기열 그룹화)? 예를 들어 구매자가 관련 메시지를 소비하고 purchases.stock, purchases.suppliers와 같은 diferents 대기열을 관리하는 여러 소비자가있는 한 프로세스는 다음과 같습니다.이 옵션은 나에게 더 적합하지만 잘 모르겠습니다.

Answer 1

핵심 개념은 다른 메시지 유형에 대해 단일 대기열을 공유하지 않도록하는 것입니다. 예외가 있지만 각 메시지 유형을 별도의 대기열에 보관하면 하나의 메시지 유형이 대기열 트래픽을 압도 할 때 병목 현상을 방지 할 수 있습니다.

프로세스의 경우, MassTransit은 버스 인스턴스 당 여러 개의 수신 엔드 포인트를 가질 수 있으므로 관련 비즈니스 기능을 단일 프로세스로 유지하면 코드 관리 및 배포에 큰 도움이됩니다. 프로세스 경계는 규모 조정에 유용 할 수 있습니다. 예를 들어, 상태 업데이트를 처리하는 프로세스/작업자를 추가하는 것 (이전에는 메시지 볼륨 측면에서 10 배가 될 수 있음)이 있습니다.

분리해야하는 또 다른 이유는 바인딩이 많은 레거시 ERP 시스템과 통신하거나 외부 라이브러리/SDK에 연결하는 소비자가 일부 오래된 라이브러리의 방식으로 인해 메모리 문제를 피하기 위해 별도의 프로세스를 보증 할 수 있습니다. 만들어진. 이러한 라이브러리는보다 빈번한 프로세스 재시작 등을 필요로 할 수 있으며 별도로 유지하면 시간이 지남에 따라 문제를 일으키는 전체 소비자 집합을 다시 시작할 필요가 없습니다.

다음은 몇 가지 일반적인 지침이지만 동일한 프로세스에 적용 할 소비자를 결정할 때 항상 사용하는 지침입니다.