Concepts de messagerie

La messagerie asynchrone permet aux services de communiquer sans s’appeler directement. Un producteur dépose un message ; un consommateur le récupère plus tard. Cela dissocie les services, atténue les pics de charge et maintient la résilience du système lorsqu’un consommateur est momentanément indisponible.

MassTransit est un framework .NET qui s’appuie sur des intermédiaires de messages comme RabbitMQ ou Azure Service Bus. Il gère la sérialisation, le routage, les nouvelles tentatives et bien d’autres aspects, afin que vous vous concentriez sur les messages et les gestionnaires plutôt que sur l’infrastructure du courtier.

Deux intentions de message sont importantes. Une commande demande à un service précis d’effectuer une action (« ChargePayment »). Un événement annonce qu’une action s’est produite (« OrderPlaced ») à tous ceux que cela concerne. Les commandes ont un seul gestionnaire ; les événements peuvent en avoir plusieurs.

Une commande est un type de message simple, nommé à l’impératif. Envoyez-la à un seul consommateur.

Un événement est nommé au passé et publié auprès de tous les abonnés intéressés.

Une file d’attente conserve les messages jusqu’à ce qu’un consommateur les traite. Il s’agit d’une communication point à point : chaque message est remis à un seul consommateur, ce qui permet de répartir la charge entre plusieurs instances de consommateurs (consommateurs concurrents).

Les intermédiaires de messages comme RabbitMQ effectuent le routage par l’intermédiaire d’échanges. Un producteur publie un message dans un échange, qui le distribue à toutes les files d’attente qui lui sont associées. C’est ainsi qu’un événement atteint plusieurs abonnés.

MassTransit associe automatiquement vos types de messages à des échanges et à des files d’attente. Envoyer cible une file d’attente (commande) ; Publier cible un échange afin que la file d’attente de chaque consommateur abonné reçoive une copie (événement).

Le service de commandes publie OrderPlaced puis poursuit son exécution. Indépendamment, un service d’envoi de courriels et un service d’analyse le consomment chacun. Ajouter un nouvel abonné ne nécessite aucune modification du producteur.

Les intermédiaires de messages proposent généralement une livraison au moins une fois : un message peut être remis après un échec. Les consommateurs doivent donc être idempotents, afin que le traitement du même message deux fois ne présente aucun danger.

Privilégiez la messagerie lorsque le travail peut être effectué de manière asynchrone, lorsque vous devez dissocier des services ou pour absorber des pointes d’activité. Pour obtenir immédiatement une réponse à une requête, un appel direct à l’API peut toutefois rester plus simple.

Testez les concepts de messagerie.

La messagerie asynchrone dissocie les services par l’intermédiaire d’un courtier. MassTransit fait abstraction des courtiers comme RabbitMQ. Les commandes (à l’impératif, un seul gestionnaire) sont envoyées vers une file d’attente ; les événements (au passé, plusieurs gestionnaires) sont publiés dans un échange qui les distribue aux abonnés. Attendez-vous à une livraison au moins une fois ; rendez donc les consommateurs idempotents.