Comment organiser les files d'attente dans Masstransit/RabbitMQ?

Question

J'aimerais connaître les meilleures pratiques pour la consommation de messages. J'ai lu des documents de MassTransit et j'ai cherché à ce sujet, mais je ne parviens à aucune conclusion.

J'ai une API (hébergeant une instance de bus) qui publie des messages. Ces messages sont variés car cette api n'est pas un microservice (messages d'achats, de ventes, etc.).

Comment dois-je organiser mes consommateurs/files d'attente?

1. Un processus pour le type de file d'attente? Par exemple un pour les achats, d'autres pour les ventes, etc. cette solution pourrait impliquer de nombreux processus et je ne sais pas si c'est une bonne solution. Que faire si je veux des files d'attente différentes pour les achats, comme les achats.stock, les achats.suppliers, etc? Le nombre de processus pourrait augmenter considérablement. Je pense que c'est une bonne option pour l'évolutivité, mais gérer autant de processus pourrait être difficile.
2. Plusieurs files d'attente pour le processus (regroupement des files d'attente par domaine)? Par exemple un processus ayant plusieurs consommateurs consommant des achats liés à des messages et gérant des files d'attente différentes, comme des achats.stock, des achats.suppliers ... Cette option a plus de sens pour moi, mais je ne suis pas sûr à ce sujet.

Answer 1

Le concept clé consiste à éviter de partager une seule file d'attente pour différents types de message. Il existe des exceptions, mais le maintien de chaque type de message dans une file d'attente distincte empêche les goulots d'étranglement lorsqu'un type de message domine le trafic de la file d'attente. En ce qui concerne les processus, étant donné que MassTransit peut avoir un nombre illimité de points de terminaison de réception par instance de bus, le maintien des fonctions métier associées en un seul processus peut considérablement améliorer la gestion et le déploiement des codes. Les limites de processus peuvent être utiles pour la mise à l'échelle, par exemple, en ajoutant plus de processus/travailleurs pour gérer les mises à jour d'état par rapport aux nouvelles commandes (le précédent peut être 10x en terme de volume de message). Une autre raison de séparer les dépendances est qu'un consommateur qui communique avec un système ERP hérité avec beaucoup de liaisons ou un couplage avec des bibliothèques/SDK externes peut justifier un processus séparé juste pour éviter les problèmes de mémoire dus au fait que certaines bibliothèques plus anciennes sont créé. Ces bibliothèques peuvent nécessiter des redémarrages de processus plus fréquents, etc. et en les maintenant séparées, il n'est plus nécessaire de redémarrer un ensemble de consommateurs pour celui qui cause des problèmes au fil du temps.

Ce ne sont que quelques lignes directrices générales, mais celles que nous utilisons tout le temps pour déterminer quels consommateurs à mettre dans le même processus.