Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Modèle de messagerie découplé
Ce modèle fournit une communication asynchrone entre les microservices en utilisant un modèle de sondage asynchrone. Lorsque le système principal reçoit un appel, il répond immédiatement avec un identifiant de demande, puis traite la demande de manière asynchrone. Il est possible de créer une architecture faiblement couplée, qui évite les goulots d'étranglement causés par la communication synchrone, la latence et les opérations d'entrée/sortie (IO). Dans le cas d'utilisation du modèle, Amazon Simple Queue Service (Amazon SQS) et Lambda sont utilisés pour implémenter une communication asynchrone entre différents microservices.
Vous devriez envisager d'utiliser ce modèle si :
-
Vous souhaitez créer une architecture faiblement couplée.
-
Il n'est pas nécessaire que toutes les opérations soient effectuées en une seule transaction, et certaines opérations peuvent être asynchrones.
-
Le système en aval ne peut pas gérer le taux de transactions entrantes par seconde (TPS). Les messages peuvent être écrits dans la file d'attente et traités en fonction de la disponibilité des ressources.
L'inconvénient de ce modèle est que les transactions commerciales sont synchrones. Même si le système d'appel reçoit une réponse, il est possible qu'une partie de la transaction continue d'être traitée par les systèmes en aval.
Important
Ce modèle étant plus adapté à un fire-and-forget modèle, le client qui appelle ce service doit interroger le service réel en utilisant un ID de demande pour obtenir le statut de la transaction.
Cas d’utilisation
Dans ce cas d'utilisation, le système d'assurance dispose d'une base de données des ventes qui est automatiquement mise à jour avec les détails des transactions du client après le paiement mensuel. L'illustration suivante montre comment créer ce système en utilisant le modèle de messagerie découplé.
Le flux de travail se compose des étapes suivantes :
L'application frontale appelle l'API Gateway avec les informations de paiement une fois que l'utilisateur a effectué son paiement mensuel.
L'API Gateway exécute la fonction Lambda « Customer » qui enregistre les informations de paiement dans une base de données Amazon Aurora, écrit les détails de la transaction dans un message adressé au service « Sales » Amazon SQS et répond au système d'appel par un message de confirmation.
Une fonction Lambda « Sales » extrait les détails de la transaction du message SQS et met à jour les données de vente. La logique d'échec et de nouvelle tentative de mise à jour de la base de données des ventes est intégrée à la fonction Lambda « Sales ».
