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 composition de l'API
Ce modèle utilise un compositeur d'API, ou agrégateur, pour implémenter une requête en invoquant les microservices individuels propriétaires des données. Il combine ensuite les résultats en effectuant une jointure en mémoire.
Le schéma suivant illustre la mise en œuvre de ce modèle.
Le schéma suivant illustre le flux de travail suivant :
-
Une passerelle d'API dessert l'API « /customer », qui possède un microservice « Commandes » qui suit les commandes des clients dans une base de données Aurora.
-
Le microservice « Support » suit les problèmes de support client et les stocke dans une base de données Amazon OpenSearch Service.
-
Le microservice CustomerDetails « » conserve les attributs du client (par exemple, adresse, numéro de téléphone ou informations de paiement) dans une table DynamoDB.
-
La fonction Lambda « GetCustomer » exécute les API de ces microservices et effectue une jointure en mémoire sur les données avant de les renvoyer au demandeur. Cela permet de récupérer facilement les informations des clients en un seul appel réseau vers l'API destinée aux utilisateurs, tout en préservant la simplicité de l'interface.
Le modèle de composition de l'API constitue le moyen le plus simple de collecter des données à partir de plusieurs microservices. Cependant, l'utilisation du modèle de composition de l'API présente les inconvénients suivants :
-
Il peut ne pas convenir aux requêtes complexes et aux grands ensembles de données nécessitant des jointures en mémoire.
-
L'ensemble de votre système devient moins disponible si vous augmentez le nombre de microservices connectés au compositeur d'API.
-
L'augmentation des demandes de base de données augmente le trafic réseau, ce qui augmente vos coûts d'exploitation.
