Message Broker - Мультивендорная архитектура в. NET Core - PullRequest
Новая
       121

Message Broker - Мультивендорная архитектура в. NET Core

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

В настоящее время я строю систему, следуя «образцу конкурирующего потребителя» в. Net Core. Таким образом, я поместил JobRequest-Message в очередь, на которую подписаны несколько потребителей (работников). Один из получателей получает сообщение и выполняет фактическую обработку задания.

У меня также есть требование для построения системы "независимой от поставщика". Это означает, что мне нужно реализовать систему таким образом, чтобы я мог легко переключаться между поставщиками брокеров сообщений, например: RabbitMq, Azure Service Bus, Amazon SQS, (Kafka).

В настоящее время мы находимся Обсуждая наилучший вариант для архивации, мы предложили следующие альтернативы:

  1. Интерфейсы и различные реализации для каждого поставщика

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

с использованием стандартных клиентских библиотек AMQP 1.0

Я придерживаюсь стандарта AMQP и использую стандартные библиотеки AMQP (https://github.com/Azure/amqpnetlite) для своей реализации. Все брокеры сообщений на основе AMQP должны работать только с одной реализацией. Недостатком является то, что я зависим от AMQP, а также от версии AMQP (RabbitMQ в настоящее время использует 0,9, Kafka не использует AMQP).

с использованием служебной шины сверху, которая уже поддерживает разных брокеров

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

Цель качества номер один - создать надежную и отказоустойчивую систему (> 100 000 рабочих запросов в день).

Пожалуйста, поделитесь своими мыслями:)

1 Ответ

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

Я должен признать, что я предвзят, потому что я автор Ребус . Тем не менее, вот моя рекомендация:

Go с вариантом 3! 100

Все упомянутые библиотеки служебной шины довольно ненавязчивы, а это означает, что основная часть кода, которую вы в итоге пишете, примет форму, похожую на эту (примеры взяты из Rebus, но две другие упомянутые библиотеки очень похожи): 

await bus.Send(command);

для отправки команды или 

await bus.Publish(evt);

для публикации события, где bus - интерфейс (в данном случае IBus) и вот так: 

public class MyCommandHandler : IHandleMessages<MyCommand>
{
    public async Task Handle(MyCommand command)
    {
        // do stuff with the command here
    }
}

для обработки сообщений (независимо от того, были ли они отправлены или опубликованы).

Это означает, что вы получите ВСЕ ПРЕИМУЩЕСТВА переносимости кода и независимости от поставщиков, предоставляемых библиотекой, с очень небольшим влиянием на макет вашего кода.

Если вы когда-нибудь решите внедрить свой собственный код обмена сообщениями, не нужно слишком много работать, чтобы заменить использование библиотеки служебной шины своим собственным кодом обмена сообщениями: создание собственного интерфейса IBus и собственного IHandleMessages<TMessage> интерфейса будет достаточно, чтобы полностью удалить зависимость в этом случае.

Только мои два цента. ?

...