MassTransit под капотом при добавлении потребителя - PullRequest
Новая
       17

MassTransit под капотом при добавлении потребителя

1 голос
/ 10 февраля 2020

Я пытаюсь понять, что происходит при использовании MassTransit таким образом, чтобы не полностью полагаться на эту библиотеку абстракционного слоя, а чтобы действительно знать и понимать, что создается под капотом и почему.

В моем приложении я регистрирую потребителей следующим образом: 

container.AddMassTransit(x =>
{
    x.AddBus(context => Bus.Factory.CreateUsingRabbitMq(cfg =>
    {
        var host = cfg.Host(configurationProvider.RabbitHostName);

        x.AddConsumer<FactAddedHandler>();
        x.AddConsumer<FactAddedOrderHandler>();
        x.AddConsumer<FactCategoryHandler>();

        cfg.ConfigureEndpoints(container);
    }));

});

Следуйте за мной по этому вопросу, поэтому пока у нас есть такой сценарий:

enter image description here

Когда я проверяю, какие очереди создаются через

rabbitmqctl list_queues Имена сообщений потребителей

Я вижу: 

FactAddedHandler     0       1
FactAddedOrderHandler        0       1
FactCategoryHandler  0       1

что заставляет меня поверить, что на каждого конкретного потребителя есть очередь c. Итак, у нас есть такой сценарий:

enter image description here

Давайте посмотрим, как определяются эти обработчики: 

internal class FactAddedHandler : IConsumer<FactAddedIntegrationEvent>
{
    //
}


internal class FactAddedOrderHandler : IConsumer<FactAddedIntegrationEvent>
{
    //
}


internal class FactCategoryHandler : IConsumer<FactCategoryIntegrationEvent>
{
    //
}

Итак, первые 2 обработчика ( FactAddedHandler и FactAddedOrderHandler ) подписываются на одно и то же событие ( FactAddedIntegrationEvent ), а другое ( FactCategoryHandler **) подписывается на другое событие (** FactCategoryIntegrationEvent ).

Поэтому я ожидаю, что существует "по крайней мере" разветвленный обмен поверх первых 2 очередей, передающих FactAddedIntegrationEvent . Итак, давайте проверим обмены через:

rabbitmqctl list_exchanges имя типа

и в результате: 

FactCategoryHandler     fanout
FactAddedOrderHandler      fanout
FactAddedHandler   fanout

IntegrationEvents:FactAddedIntegrationEvent  fanout
IntegrationEvents:FactCategoryIntegrationEvent    fanout

Итак .. что бы я ожидается, что IntegrationEvents: FactAddedIntegrationEvent - это разветвленный обмен, который транслирует FactAddedIntegrationEvent .

Я также считаю, что masstransit по умолчанию создает другой обмен IntegrationEvents: FactCategoryIntegrationEvent таким образом, что легко добавить других потребителей к тому же событию, даже если в моем случае есть только один.

Поэтому мы в конечном итоге в этом сценарии, который все еще имеет смысл:

enter image description here

Я НЕ понимаю и не хочу объяснять причину создания трех других оставшихся обменов. Какова их роль? Почему они там? Заранее спасибо!

1 Ответ

2 голосов
/ 10 февраля 2020

Для конечной точки приема MassTransit создает очередь и соответствующий обмен с одинаковым именем. Очередь привязана к соответствующему обмену.

Типы сообщений, используемые потребителями на конечной точке получения, используются для объявления обменов (как вы показали выше), и соответствующий обмен привязывается к этим обменам типов сообщений. Все эти обмены fanout обмены.

Результирующая топология маршрутизирует все типы сообщений через соответствующий обмен, который затем направляется в очередь.

Это объясняется с помощью пример в документации .

RabbitMQ Publish Topology

Почему соответствующий обмен? Два ответа.

Во-первых, простой ответ, он позволяет отправлять сообщения на обмен с ключом маршрутизации. Для отправки в очередь с помощью RabbitMQ требуется пустой обмен с именем очереди в качестве ключа маршрутизации.

Во-вторых, он позволяет привязывать дополнительные очереди к соответствующему обмену в целях устранения неполадок. Это включает в себя настройку прослушивания для хранения копии всех сообщений, отправленных в конечную точку (либо напрямую, либо посредством обмена опубликованными типами сообщений).

...