View a markdown version of this page

Rejouer des requêtes parallèles pour briser un monolithe - Rejouer des requêtes parallèles pour briser un monolithe

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.

Rejouer des requêtes parallèles pour briser un monolithe

Date de publication : 24 juin 2022 (Historique du diagramme)

Cette architecture montre comment briser votre monolithe en toute confiance en mettant en place une stratégie de course parallèle combinée au schéma Strangler Fig. Vous utilisez des méthodes proxy à remplacer par un microservice, vous stockez des copies des demandes des utilisateurs et des réponses monolithes dans une base de données chronologique, puis vous rejouez les demandes sur votre nouveau microservice pour comparer les réponses.

Rejouer des requêtes parallèles pour briser un monolithe

Schéma d'architecture illustrant une stratégie de relecture de requêtes en parallèle utilisant Amazon API Gateway AWS Lambda, Amazon Kinesis Data Streams AWS Step Functions, Amazon Simple Queue Service et Amazon Simple Notification Service.

Les étapes suivantes décrivent l'architecture :

  1. Appliquez le schéma Strangler Fig avec AWS Migration Hub Refactor Spaces pour placer une API Amazon API Gateway devant votre monolithe cloud existant sur Amazon Elastic Compute Cloud et Amazon RDS. Re-route les terminaux à moderniser pour en faire un système d'enregistrement qui enregistre toutes les demandes et réponses.

  2. Utilisez une AWS Lambda fonction d'enregistrement proxy pour renvoyer les requêtes par proxy vers l'ancien monolithe et transférez une copie de toutes les charges utiles de demandes et de réponses dans Amazon Kinesis Data Streams.

  3. Utilisez Amazon Kinesis Data Firehose pour diffuser le flux de charge utile monolithique dans un compartiment Amazon Simple Storage Service.

  4. Utilisez une fonction de tri pour stocker les charges utiles dans Amazon Timestream par ordre chronologique.

  5. Sauvegardez régulièrement la base de données du monolithe à l'aide d'AWS Backup pour définir l'heure de début du flux de rediffusion.

  6. Utilisez un AWS Step Functions flux de travail pour rejouer les demandes. Réinitialisez d'abord les bases de données temporaires du microservice à partir d'une sauvegarde de base de données monolithe, puis relancez les demandes à partir de la date et de l'heure de la sauvegarde.

  7. Récupérez toutes les demandes dans la fenêtre de replay, triées par date et heure, puis transférez-les vers une file d'attente FIFO (premier entré, premier sorti) à l'aide d'Amazon Simple Queue Service. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html

  8. Pour chaque demande de la file d'attente, invoquez la même demande dans l'API du microservice et enregistrez les réponses dans un compartiment Amazon S3.

  9. Comparez les réponses d'une même requête envoyée au monolithe et au microservice. Déclenchez une alerte en cas de différence à l'aide d'Amazon Simple Notification Service et enregistrez les résultats finaux dans la base de données des requêtes.

Suggestions de lecture

Pour plus d'informations, consultez les ressources suivantes :

Historique du diagramme

Pour être informé des mises à jour de ce schéma d'architecture de référence, abonnez-vous au fil RSS.

ModificationDescriptionDate

Publication initiale

Schéma d'architecture de référence publié pour la première fois.

24 juin 2022

Note

Pour vous abonner aux mises à jour RSS, un plug-in RSS doit être activé pour le navigateur que vous utilisez.