NServiceBus et Rabbit MQ ou Kafka
J'essaie d'apprendre le système de messagerie. J'ai trouvé que RabbitMq et NServiceBus utilisent ensemble à quelques endroits. Mes questions sont
- Si j'utilise RabbitMQ, pourquoi ai-je besoin de NServiceBus? et vice versa
- Que peut faire NServiceBus mais RabbitMQ ou Kafka ne peut pas?
- Puis-je utiliser NServiceBus et kafka ensemble? Ou Apache-Kafka ne nécessite pas NServiceBus
Il y a des années, je me suis posé la même question. Je regardais NServiceBus pour travailler avec une file d'attente de messages différente, mais la question était la même.
J'ai décidé de ne pas utiliser NServiceBus.
6 mois plus tard, j'ai réalisé que j'avais reconstruit la moitié de ce que NServiceBus avait fait ... mais beaucoup plus mal.
La question équivalente de la raison pour laquelle vous auriez besoin de NServiceBus avec RabbitMQ est de vous demander pourquoi vous auriez besoin du .NET Framework avec ASP.NET MVC, ou de WinForms, ou XAML, ou de l'une des bibliothèques intégrées fournies avec .NET, lorsque vous disposez du Common Language Runtime.
Le CLR ne devrait-il pas suffire, après tout?
Bien sûr que non. Avoir le runtime sur lequel le code peut s'exécuter - l'interpréteur MSIL et le moteur d'exécution - n'est pas suffisant pour être productif.
Bien sûr, vous pouvez écrire des applications en ligne de commande qui prennent des entrées et produisent des sorties. Mais essayez de créer une véritable application sans les bibliothèques communes - sans les pilotes SQL Server intégrés; sans aucun contrôle ni bibliothèque tiers. Créez une application Windows Desktop sans l'espace de noms System.Windows.
Vous avez besoin de ces bibliothèques pour vous donner des collections, un accès à la base de données, des objets de fenêtre et des contrôles d'interface utilisateur.
De même, RabbitMQ vous donne tout ce dont vous avez besoin pour commencer et travailler, mais pas assez pour maintenir la productivité.
Bien sûr, vous pouvez récupérer le pilote .NET pour RabbitMQ et commencer à produire et à consommer des messages.
Pendant un certain temps, cela fonctionnera très bien.
Très bientôt, vous vous retrouverez à créer un wrapper autour du pilote, afin que vous puissiez réduire la quantité de code que vous devez écrire.
Ensuite, vous vous retrouverez devant traiter ack vs nack, et vous créerez une API simple pour cela.
Ensuite, le besoin de files d'attente de lettres mortes apparaîtra avec des appels nack, et vous envelopperez cela dans votre API - simplifié par rapport au pilote rabbitmq, bien sûr.
Finalement, vous voudrez traiter les messages empoisonnés - des messages mal formés et provoquant des exceptions. Encore une fois, vous ne voulez pas écrire de code unique pour cela, vous allez donc écrire une bibliothèque pour le gérer.
La liste se rallonge de plus en plus.
Dans 6 mois, vous vous retrouverez à travailler avec une bibliothèque à moitié écrite, à peine spécifiée et non testable qui imite uniquement la valeur et les capacités de NServiceBus (ou MassTransit ou toute autre bibliothèque de bus de service que vous choisissez).
Je ne dirai pas que vous devez utiliser NServiceBus. Et je dirais que vous devriez apprendre comment fonctionne RabbitMQ, sans cela. Mais une fois que vous avez dépassé les bases de l'envoi et de la réception de messages, la valeur de NServiceBus et d'autres implémentations de bus de service devient très apparente, très rapidement.
Il semble qu'il y ait un support communautaire pour Kafka transport dans NServiceBus maintenant: https://docs.particular.net/nservicebus/kafka/ (je ne l'ai pas essayé moi-même encore).