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 passerelle API
Le modèle de passerelle API est recommandé si vous souhaitez concevoir et créer des applications complexes ou volumineuses basées sur des microservices avec plusieurs applications clientes. Le modèle est similaire au modèle de façade issu
Le modèle fournit un proxy inverse pour rediriger ou acheminer les demandes vers vos points de terminaison de microservices internes. Une passerelle d'API fournit un point de terminaison ou une URL unique pour les applications clientes, et elle mappe en interne les demandes aux microservices internes. Une couche d'abstraction est fournie en masquant certains détails d'implémentation (par exemple, le nom et la version de la fonction Lambda), et des fonctionnalités supplémentaires peuvent également être ajoutées au-dessus du service principal, telles que les transformations de réponse et de demande, l'autorisation d'accès aux terminaux ou le suivi.
Vous devriez envisager d'utiliser le modèle de passerelle d'API si :
-
Le nombre de dépendances d'un microservice est gérable et n'augmente pas au fil du temps.
-
Le système d'appel nécessite une réponse synchrone du microservice.
-
Vous avez des exigences de faible latence.
-
Vous devez exposer une API pour collecter des données provenant de plusieurs microservices.
Cas d’utilisation
Dans ce cas d'utilisation, un client effectue des paiements mensuels réguliers dans un système d'assurance composé de quatre microservices déployés sous forme de fonctions Lambda (« Client », « Communication », « Paiements » et « Ventes »). Le microservice « Client » met à jour la base de données clients avec les détails des paiements mensuels. Le microservice « Ventes » met à jour la base de données des ventes avec des informations pertinentes qui aident l'équipe commerciale à suivre les opportunités de ventes croisées auprès du client. Le microservice « Communication » envoie un e-mail de confirmation au client une fois le paiement traité avec succès. Enfin, le microservice « Paiements » est le système global que le client utilise pour effectuer son paiement mensuel. Le modèle utilise les services Web pour intégrer les sous-systèmes « Client », « Ventes » et « Communication » au microservice « Paiements ».
L'utilisation de ce modèle dans ce cas d'utilisation présente trois défis :
Les appels synchrones sont effectués vers les systèmes en aval, ce qui signifie que toute latence causée par ces sous-systèmes affecte le temps de réponse global.
Les coûts de fonctionnement sont plus élevés car le système de « paiements » attend les réponses des autres microservices avant de répondre au système d'appel. La durée totale de fonctionnement est donc relativement supérieure à celle d'un système asynchrone.
La gestion des erreurs et les nouvelles tentatives sont gérées séparément pour chaque microservice au sein du système « Paiements », et non par les microservices individuels.
Les deux exemples suivants expliquent comment utiliser le modèle de passerelle d'API pour intégrer des microservices en utilisant plusieurs passerelles d'API ou une seule passerelle d'API.
Passerelles d'API multiples
Dans l'illustration suivante, chaque microservice possède sa propre passerelle d'API. Le microservice « Payments » fait appel à des systèmes individuels et implémente le modèle de passerelle API.
Passerelle API unique
Dans l'illustration suivante, chaque microservice est déployé en tant que fonction Lambda, mais tous les microservices sont connectés par la même passerelle API.
