Traduction
La messagerie est une composante fondamentale de tout système distribué. Cela permet à un producteur d’envoyer un message à n’importe quel nombre de consommateurs, et il n’est pas nécessaire de connaître des informations sur le consommateur. C’est d’une grande aide pour une communication véritablement asynchrone et de découplage.
Lorsque vous utilisez RabbitMQ, le schéma ci-dessus montre une structure très basique mais typique. Un producteur envoie un message à l’interrupteur. Selon la logique de routage, le commutateur place le message dans la file d’attente liée au commutateur. Plus précisément, s’il s’agit d’un commutateur de type broadcast, la copie de ce message sera envoyée à chaque file d’attente à plusieurs reprises. Un consommateur peut alors recevoir et traiter le message.
Une hypothèse importante pour que la structure ci-dessus fonctionne efficacement pour les producteurs et les consommateurs est que tous les composants RabbitMQ (c’est-à-dire les files d’attente, commutateurs et liaisons) doivent être créés à l’avance. Un consommateur ne peut pas envoyer un message à un commutateur Si le commutateur n’existe pas, un consommateur ne peut pas traiter les messages d’une file d’attente qui n’existe pas.
Il n’est donc pas difficile de comprendre qu’avant que le producteur/consommateur n’envoie/reçoive le message, il faut laisser une valeur producteur/consommateur créer une file d’attente, un commutateur et une relation de liaison. Examinons les avantages et les inconvénients de chaque méthode.
1. Distinguer les responsabilités
Traduction d’image (1. Le producteur crée un commutateur 2. Le consommateur crée une file d’attente et lie la file au commutateur)
Pour que producteurs et consommateurs puissent complètement se découpler, idéalement, les producteurs ne connaissent que les informations sur le commutateur (pas la file d’attente), et les consommateurs ne connaissent que la file d’attente (pas le commutateur). La relation de liaison indique la relation entre le commutateur et la file d’attente
Une façon possible est que le producteur s’occupe de la création du commutateur, et que le consommateur fasse la file d’attente et lie la file au commutateur. L’avantage de cette méthode de découplage est que si le consommateur a besoin d’une file d’attente, il est simplement nécessaire de créer une file d’attente et de les lier selon la demande, et le producteur n’a pas besoin de connaître d’informations sur la file d’attente. Mais ce n’est pas un découplage suffisant : car le consommateur doit connaître l’interrupteur pour pouvoir le lier.
2. Les producteurs créent tout
Lorsque le producteur est en cours, il peut être configuré pour créer tous les composants nécessaires (commutateurs, files d’attente et liaisons). L’avantage de cette approche est qu’aucun message n’est perdu (car la file d’attente est déjà créée et liée au commutateur, et aucun consommateur n’a besoin de la démarrer en premier).
Cependant, cela signifie que le producteur doit connaître toutes les files d’attente à relier au switch. C’est une méthode très couplée. La raison est qu’à chaque fois qu’une nouvelle file doit être ajoutée, le producteur doit reconfigurer et déployer pour créer et lier des files d’attente
3. Les consommateurs créent tout
L’inverse est de laisser le consommateur créer les commutateurs, files d’attente et liaisons dont il a besoin lorsqu’il fonctionne. Comme dans l’approche précédente, cette méthode produit le couplage car le consommateur doit connaître les informations concernant le commutateur auquel il est lié à la file d’attente. Toute modification du commutateur (comme le renommage) signifie que tous les consommateurs doivent être reconfigurés et déployés. Lorsqu’il y a de grandes files d’attente et de consommateurs, cette complexité peut être prohibitif.
4. Aucun ne crée rien
Une approche complètement différente consiste à ce que ni le producteur ni le consommateur ne créent les composants nécessaires. À la place, il est créé à l’aide de l’interface utilisateur du plugin admin ou de la CLI admin à l’avance. Cette méthode repose sur les avantages suivants :
- Les producteurs et les consommateurs peuvent être complètement découplés. Les producteurs ne connaissent que l’échange, et les consommateurs ne connaissent que la file d’attente.
- Cela peut être facilement scripté et automatisé dans le cadre du pipeline de déploiement
- Tout changement, comme de nouvelles files d’attente, peut être ajouté sans toucher aux éditeurs et consommateurs déjà déployés
résumé
Dans les systèmes distribués, les messages asynchrones sont un moyen utile de découpler, mais pour les maintenir découplés, il est nécessaire de maintenir une stratégie efficace pour maintenir la structure de messagerie sous-jacente (dans RabbitMQ, il s’agit de files d’attente, de commutateurs et de liaisons).
Bien que les services publics et grand public puissent être responsables de créer eux-mêmes ce dont ils ont besoin, ils peuvent être coûteux en termes de perte initiale de message, de couplage et de maintenance opérationnelle (en termes de configuration et de déploiement).
Probablement la meilleure façon de gérer la configuration du système de messagerie là où il doit être : écrire des scripts en dehors de l’application. Cela garantit que les services restent découplés et que le système de files d’attente peut évoluer dynamiquement selon les besoins sans affecter un grand nombre de services existants.
Langue source:La connexion hyperlientérée est visible.
Anglais original :La connexion hyperlientérée est visible.
|
Publié sur 03/05/2023 22:31:59
|
|
|
|
