eServices-Chp5: Microservices et API Management

Microservices & API Management
Chapitre 5 - eServices
GL5
2015/2016
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1

Microservices
API Management
API Gateway
2
PLAN

Microservices
Définition des Microservices
Approche Monolithique vs Microservices
Caractéristiques de l’Architecture Microservices
API Management
API Gateway
3
PLAN

Définition des Microservices
Style d’architecture
Approche pour développer une seule application comme suite de petits
services:
•  Déployables les uns indépendamment des autres
•  Chacun s’exécute sur son propre processus
•  Communiquent via des mécanismes légers, souvent une ressource HTTP
•  Constuits autours des compétences métier
•  Peuvent être rédigés dans des langages et technologies différentes
•  Peuvent utiliser des technologies de stockage de données diverses
4
Microservices

Approche Monolithique vs Approche Microservices
Approche Monolithique
•  Application construire comme une seule unité
•  Usuellement, les applications sont divisées en trois parties:
•  L’interface utilisateur
•  Une base de données
•  Une couche métier
•  La couche métier se charge de:
Gérer les requêtes HTTP, Exécuter la logique du domaine, Extraire et modifier
les données de la base de données, Sélectionner et charger les vues HTML…
•  Cela représente une application Monolithe
•  Toute modification du système implique la compilation et déploiement d’une
nouvelle version de la couche métier
Dr. Lilia SFAXI
Slide 5
Microservices

Approche Monolithique: Caractéristiques et Avantages
•  Approche naturelle pour la construction d’un système
•  Toute la logique métier tourne sur un seul processus
•  Utilisation des caractéristiques de base de votre langage pour diviser
l’application en classes, packages, namespaces…
•  Il est possible de lancer et tester l’application Monolithe sur la machine
du développeur, puis la déployer en production
•  Il est possible d’utiliser un Load Balancer pour gérer la répartition de
charge entre plusieurs instances de cette application
•  Applications qui produisent de bons résultats, rapidement conçues et
déployées
Mais…
Dr. Lilia SFAXI
Slide 6
Microservices

Approche Monolithique: Inconvénients
•  Avec l’utilisation massive du cloud, les utilisateurs deviennet frustrés
•  Les cycles de changement sont très reliés:
•  Une modification dans une petite partie de l’application requiert un rebuild
et redéploiement entier
•  Il est difficile de garder une structure modulaire et une séparation des
préoccupations
•  La mise à l’échelle d’une partie qui a besoin de plus de ressources
requiert celle de toute l’application
Besoin de construire des applications sous formes de services
indépendants
Dr. Lilia SFAXI
Slide 7
Microservices

Approche Microservices
•  S’inspire des principes de conception du système UNIX
•  loin d’être récents, mais peu considérés dans le développement logiciel
•  Services sont déployables indépendamment les uns des autres
•  Mise à l’échelle plus facile et ciblée à chaque service
•  Chaque service définit des limites bien fermes
•  Chaque service peut être écrit dans un langage différent
•  Chaque service peut être géré par une équipe différente
Dr. Lilia SFAXI
Slide 8
Microservices

Dr. Lilia SFAXI
Slide 9
Microservices

Architecture Microservices : Caractéristiques
Division en Composants via les Services
•  S’inspirer du monde réel, qui est une association de composants reliés
•  Composant: Unité logicielle qui est indépendamment remplaçable et
modifiable
•  Utilisation simultanée de librairies et de services:
•  Librairies: composants reliés dans un programme et invoqués via des appels de
fonctions in-memory
•  Services: composants out-of-process, communiquant via des mécanismes
distants tels que les web services ou les appels de procédures distantes
•  Avantage des services:
•  Indépendamment déployables: un changement dans un service ne nécessite
que le déploiement du service concerné
•  Interface de composant plus explicite
•  Inconvénients des services:
•  Appels distants plus coûteux
Dr. Lilia SFAXI
Slide 10
Microservices

Organisation autours des Capacités Métiers
•  La décomposition classique d’une application est souvent orientée vers
les couches techniques (vue, contrôle et modèle)
•  Cela entraîne souvent que chaque changement touchera plusieurs équipes,
ce qui est coûteux en temps et en budget
•  Solution: Division logique des équipes
•  Chaque service concerne un domaine
métier différent
•  Les équipes sont inter-fonctionnelles, avec
tous les niveaux de compétences
(UI, stockage et gestion de projet)
Dr. Lilia SFAXI
Slide 11
Microservices
UI Métier BD
Service1
Service2 Service3

Produits, pas Projets
•  Traditionnellement, l’effort de développement utilise un modèle de
projet: l’objectif est de livrer un logiciel complet
•  À la fin du projet, le logiciel est transmis à une équipe de maintenance, et
l’équipe de développement est dissoute
•  Dans la vision Microservices, une équipe doit posséder un produit,
durant tout son cycle de vie
•  L’équipe de développement est entièrement responsable du logiciel produit
•  « You build it, you run it »
•  L’équipe reste au courant du comportement de son produit en production
•  Cette approche peut être prise pour les applications monolithiques,
mais la granularité plus fine des services peut rendre plus efficace la
relation développeur-client.
Dr. Lilia SFAXI
Slide 12
Microservices

Extrémités Intelligentes et Canaux Stupides
•  Plusieurs approches mettent beaucoup d’intelligence dans les canaux
de communication entre les services
•  Exemple: ESB, avec des opérations sophistiquées pour le routage, la
chorégraphie, la transformation…
•  Les applications utilisant les microservices favorisent l’utilisation de
communications sans intelligence, qui ne font que transmettre les
messages, alors que le service lui-même fait le reste
•  Protocoles utilisés:
•  HTTP pour les requêtes/réponses, principes et protocoles du web
•  Bus de messagerie asynchrone et léger, ne faisant qu’un simple routage (ex:
RabbitMQ ou ZeroMQ)
Dr. Lilia SFAXI
Slide 13
Microservices

Une Gouvernance Décentralisée
•  Gouvernance centralisée => tendance à s’orienter vers une technologie et
plateforme unifiée
•  Difficile de trouver une seule technologie qui résout tous les problèmes
•  Dans les architectures Microservices, chaque service pourra utiliser la
technologie/langage/plateforme le plus adéquat pour ses besoins
•  Chaque équipe est responsable du service qu’elle réalise
•  Responsabiliser les équipes et les obliger à fournir un code de qualité depuis le
début
•  Favoriser l’idée du partage, de l’open source, aider les autres développeurs à
résoudre les mêmes problèmes
•  Abandonner l’idée classique des contrats de services pour des concepts plus
modernes, plus légers, par ex:
•  Tolerant Reader: le consommateur d’un service utilise uniquement les données
dont il a besoin pour éviter le dilemme du YAGNI (You Aren’t Going to Need IT)
Dr. Lilia SFAXI
Slide 14
Microservices

Gestion des Données Décentralisée
•  Le modèle conceptuel diffère entre les différents systèmes, ou services
d’une même application
•  Décentralisation des décisions sur le stockage des données
•  Utilisation de bases de données différentes ou de différentes instances d’une
même base de données, pour chaque service
•  Approche Polyglot Persistence: une variété de technologies de stockage pour
plusieurs types de données
•  Architecture souvent distribuée, donc il est difficile d’assurer une
consistance continue via le principe de transactions, car cela induit un
couplage temporel et un problème de disponibilité
•  Les Microservices optent plutôt pour le principe de consistance éventuelle
Dr. Lilia SFAXI
Slide 15
Microservices

Automatisation de l’Infrastructure
•  Devenue très populaire avec l’évolution du cloud
•  Principes de:
•  Livraison Continue: le logiciel est développé de manière à ce qu’il puisse être
livré en production à tout moment
•  Intégration Continue: les membres de l’équipe intègrent leur travail
fréquemment, à raison de plusieurs intégrations par jour, chaque intégration
étant vérifiée par un build et des tests automatiques
•  Besoin donc d’outils d’automatisation de l’infrastructure
Dr. Lilia SFAXI
Slide 16
Microservices

Design for Failure
•  Les applications sont conçues pour être tolérantes aux fautes
•  Si un service est inaccessible, le client doit y répondre le plus
gracieusement possible
•  Rajoute de la complexité par rapport à une application monolithique
•  Les équipes réfléchissent à l’impact de l’échec de chaque service sur
l’utilisateur
•  Il faut que:
•  Les failles soit détectées très rapidement
•  Restaurer le service automatiquement, si possible
•  Le monitoring en temps réel des applications Microservices est très
important
Dr. Lilia SFAXI
Slide 17
Microservices

Conception évolutive
•  La décomposition de services permet de contrôler les changements de
l’application sans les ralentir
•  L’évolution de l’application est donc plus fluide
•  Les composants sont définis de manière à être indépendamment
remplaçables et mis à jour
•  Donc, la modification d’un composant ne devrait pas affecter ses
collaborateurs de manière significative
•  Utilisation d’un principe de la conception modulaire : définir la
modularité suivant le patron du changement
•  Regrouper dans le même module les éléments qui changent en même temps,
ou dont le changement de l’un affecte l’autre
Dr. Lilia SFAXI
Slide 18
Microservices

Microservices
API Management
Définition et Utilité
Challenges du API Management
Fonctionnalités du API Management
Solutions du API Management
Recommandations pour la Conception des APIs
API Gateway
19
PLAN

Mouvement Open API
•  Appelé aussi Public API
•  Tendance qui autorise un accès à un logiciel propriétaire via une API
publique
•  Exposition de certaines fonctionnalités du logiciel en protégeant les
autres
•  Souvent une implémentation de REST
•  Les Open APIs sont publiés sur Internet et partagés librement
•  Permet d’encourager les développeurs d’autres entreprises (parfois
concurrentes) d’utiliser leur logiciel, et de se montrer innovants
•  Facilite la création de Mashups à partir de plusieurs applications
•  Problème:
•  Les utilisateurs des APIs sont dépendants de l’entreprise qui publie l’API
(modification de l’API, ajout de frais…)
Dr. Lilia SFAXI
Slide 20
API Management

Définition
•  Entre dans le mouvement Open API, promu par de grands noms du web
comme Facebook, Twitter et Google
•  Processus de publier, promouvoir et surveiller les interfaces de
programmation des applications (APIs) dans un environnement
sécurisé et extensible
•  Inclut la création d’un support pour définir et documenter ces APIs
•  Permet de :
•  Gérer le cycle de vie de l’interface
•  S’assurer que les besoins des consommateurs (développeurs et
applications) sont satisfaits
•  Favoriser les services légers REST et le format JSON aux services SOA
classiques
Dr. Lilia SFAXI
Slide 21
API Management

Challenges de l’API Management
•  Comment protéger les actifs de l’entreprise des éventuelles attaques
ou abus?
•  Comment offrir votre API comme services fiables, sans temps d’arrêt
qui peut nuire à des utilisateurs?
•  Comment gouverner l’accès et l’usage de l’API de manière consistante
et de manière axée sur la politique (policy-driven)?
•  Comment gagner de l’argent grâce à vos APIs?
•  Comment aider les utilisateurs à découvrir vos APIs et gérer leurs
accès eux-mêmes?
Dr. Lilia SFAXI
Slide 22
API Management

Fonctionnalités des Outils de API Management
1.  Sécurité
•  Protéger les données exposées
•  Au moins, une gestion de l’identité et un contrôle d’accès
2.  Gestion du cycle de vie de l’API
•  S’assurer que les mises à jour ou versionning de l’API, ou tout mouvement
d’environnement, géographique des datacenters ou du cloud ne va pas
impacter leur utilisation
•  Fournir des workflows pour:
•  Promouvoir des APIs du développement à la production
•  Gérer les métadonnées associées à la politique adoptée
•  Restreindre les droits en modification en utilisant un contrôle d’accès basé sur les
rôles (RBAC)
•  Permettre les approbations et les rollbacks
3.  Gouvernance de l’API
•  Définir les termes et conditions sous lesquelles une API est exposée à un ou
plusieurs consommateurs
•  Contrôler et suivre la manière dont les APIs sont exposées aux différents
partenaires et développeurs, via des politiques, telles que les SLA, la
disponibilité et la performance
Dr. Lilia SFAXI
Slide 23
API Management

4.  Engagement du développeur et construction de la communauté
•  Comment amener les développeurs à bord et les aider?
•  Offrir un portail accessible pour les développeurs pour:
•  Supporter les différentes classes de développeurs (droits différents pour les partenaires et
pour les développeurs publics, par exemple)
•  Fournir des capacités de self-service
•  Donner aux développeurs la visibilité necessaire sur leur utilisation de l’API et les
métriques clefs de performance (temps de réponse par ex.)
•  Permetre aux développeurs de partager les bonnes pratiques via un portail communautaire
(ex. forum)
5.  Monétisation
•  Permettre de monétiser l’API si le besoin se présente
•  Plusieurs modèles, par exemple:
•  Freemium: usage gratuit u dessus d’un certain seuil d’utilisation
•  Charger uniquement certaines fonctionnalités
•  Charger pour une certaine priorité d’usage ou pour une qualité de service meilleure
6.  Disponibilité
•  L’API doit être disponible, évolutive et redondante
•  Le service doit pouvoir gérer tout type d’erreurs, problèmes ou congestion
Dr. Lilia SFAXI
Slide 24
API Management

7.  Documentation
•  Fournir un moyen facile de lire la documentation et la possibilité de
« essayer avant d’acheter »
8.  Analytics et Statistiques
•  Comprendre comment est-ce que les utilisateurs utilisent votre API
9.  Déploiement
•  Doit être flexible, et doit supporter les clouds publics et privés
10.  Offrir un « Sendbox Environment »
•  Environnement de test qui isole les changements et l’expérimentation de
l’environnement de production
•  Permettre au consommateur de l’API de tester l’API avant de l’utiliser
11.  Gestion du traffic
•  Contrôler le traffic et autoriser le caching pour un accès rapide aux pages
les plus visitées, gérer les quotas, détecter les congestions
Dr. Lilia SFAXI
Slide 25
API Management

Types de Solutions de API Management
Proxies
•  Solution entre l’utilisateur et l’application
•  Fournissent des capacités de caching, et protection de l’infrastructure
des pics de traffic
•  Problèmes : Augmentation des coûts et problèmes de latence
Agents
•  Utilisation du concept d’agents: plugins à intégrer dans votre serveur
•  Pas de latence du réseau ni de dépendance
•  Problème : difficulté d’implémenter la notion de caching
Hybrides
•  Possibilité d’utiliser un agent et un proxy
•  Exemple: un agent pour le caching, et un proxy pour l’authentification
Dr. Lilia SFAXI
Slide 26
API Management

Classement des Outils de API Management
Dr. Lilia SFAXI
Slide 27
API Management
Gartner Magic Quadrant for Application Services Governance

Recommandations pour la Conception d’APIs
Voici quelques recommandations pour l’écriture d’une
« bonne » API, ce n’est pas la seule, peut-être pas la meilleure,
mais c’est celle définie par les développeurs d’apigee, l’un des
leaders en API Management, dans leur white paper:
Web API Design: Crafting Interfaces that Developers Love
Dr. Lilia SFAXI
Slide 28
API Management

1. Accès aux ressources : Nouns are Good, Verbs are Bad
•  Garder votre URL de base simple et intuitive
•  Utiliser seulement 2 URLs de base par ressource:
•  Une pour la collection : /dogs
•  Une pour accéder à un élément spécifique de la collection (via son id)
/dogs/1234
•  Éviter les verbes dans les URLs pour manipuler les ressources : les verbes HTTP,
appliqués aux 2 URLs précédents, suffisent:
Dr. Lilia SFAXI
Slide 29
Recommandations pour la Conception d'APIs
Ressource POST GET PUT DELETE
/dogs Créer un nouveau
chien
Lister les chiens Modifier plusieurs
chiens en masse
Supprimer tous les
chiens
/dogs/1234 Erreur Afficher le chien
1234
Si le chien existe,
l’afficher, sinon Erreur
Supprimer le chien
1234

2. Noms Explicites et au Pluriel
•  Il est plus lisible d’utiliser le pluriel pour représenter un type de
ressources (/dogs)
•  Dans tous les cas, rester consistants: soit pluriel partout, soit
singulier partout
•  Utiliser des noms explicites pour les ressources
•  Éviter d’utiliser un type abstrait, pour que la ressource soit compréhensible
par le développeur
•  Ex. utiliser /videos,/blogs,/articles au lieu de /items
pour représenter tous les types en un seul
Dr. Lilia SFAXI
Slide 30

3. Simplifier les Associations
•  Une association entre deux ressources devrait être représentée de la
manière suivante:
/ressource1/id1/ressource2
•  Par exemple, si on cherche les chiens du propriétaire 5678, on écrira:
/owners/5678/dogs
Dr. Lilia SFAXI
Slide 31

4. Utiliser les Paramètres derrière le ‘?’
•  Éviter d’inclure des détails dans les URLs de base, utiliser les
paramètres pour représenter les états optionnels:
•  Ex. Pour représenter tous les chiens rouges qui courent dans
le parc:
GET /dogs?color=red&state=running&location=park
Dr. Lilia SFAXI
Slide 32

5. Gestion des Erreurs
•  Les messages retournés par
une API sont les seules
indications sur le
comportement de votre
application, qui est une
boîte noire pour le
développeur
•  Utiliser les HTTP Status
Codes
•  Pas forcément les 70 codes,
mais les plus connus
•  Plus le message est verbeux,
mieux c’est
•  Inclure de préférence un lien
pour plus d’explications
Dr. Lilia SFAXI
Slide 33
Code Description Signification
200 OK Ça marche!
201 Created La ressource a été créée
304 Not Modified Le client peut utiliser la version en
cache de la ressource, car elle n’a pas
été modifiée
400 Bad Request La requête du client est mal formulée
401 Not
Authorized
Le client doit s’authentifier
403 Forbidden Le client n’a pas le droit d’utiliser la
ressource
404 Not Found La ressource est inexistante
500 Internal
Server Error
Il y’a un roblème au niveau de
l’implémentation du service

6. Versionning
•  TOUJOURS inclure une version dans votre API
•  La rendre obligatoire
•  Plusieurs manières de faire:
•  Inclure un timestamp dans l’URL, qui va indiquer quand est-ce que la requête a
été créée, et choisir selon cela la version à utiliser
•  Spécifier la version sous la forme Vxx dans l’URL
•  Indiquer la version dans le header
•  Recommandation:
•  Spécifier la version dans l’URL
•  Utiliser le préfixe ‘v’
•  Le définir au début de l’URL, de manière à ce qu’il ait un haut niveau
hiérarchique
•  Utiliser un nombre ordinal simple (v1, v2, …) plutôt que v1.2, v2.4, car la
granularité du versionning d’une API doit être assez gros (contrairement à une
implémentation, qui peut évoluer à plusieurs reprises)
Dr. Lilia SFAXI
Slide 34

7. Réponse Partielle
•  Une réponse partielle permet de donner aux développeurs
l’information dont ils ont besoin uniquement, en
sélectionnant les champs affichés dans la réponse
•  Utiliser une liste optionnelle séparée par des virgules pour
indiquer les champs à afficher, ex. :
/dogs?fields=name,color,location
Dr. Lilia SFAXI
Slide 35

8. Pagination
•  La pagination permet de limiter les enregistrements
retournés d’une base de données.
•  Utiliser les mots clefs :
•  Limit : pour indiquer le nombre d’éléments retournés
•  Offset: pour indiquer le rang de départ
Par exemple, la requête:
/dogs?limit=25&offset=50
Retourne les enregistrements de 50 à 75
•  Il serait judicieux d’insérer dans chaque réponse des métadonnées
indiquant au développeur le nombre total d’enregistrements
disponibles
Dr. Lilia SFAXI
Slide 36

9. Accès aux URIs Fonctionnels
•  Il est possible de définir des APIs qui retournent autre chose
qu’une ressource ou qui déclenchent un traitement distant
particulier
•  Pour cela, utiliser des verbes, pas des noms
•  Indiquer clairement dans l’API que ce sont des opérations
fonctionnelles, pas des ressources
•  En ajoutant un préfixe à leur URI, comme func, par exemple
•  En les définissant dans une section différente de la documentation
http://.../api/func/calculateTax?state=fl&amount=10
Dr. Lilia SFAXI
Slide 37

10. Support de Plusieurs Formats
•  Il est recommandé de supporter plusieurs formats de réponse
•  Il est possible d’automatiser le mapping d’un format à un autre
•  Il est recommandé d’indiquer dans l’URI le format désiré pour
la réponse, en l’ajoutant comme extension
•  C’est clair, intuitif, et demande peu de caractères supplémentaires
/dogs/1234.json
•  Le format par défaut recommandé est JSON
•  La plupart des projets utilisent Javascript comme front-end
•  Il est moins verbeux que XML
Dr. Lilia SFAXI
Slide 38

11. Noms des Attributs
•  Il est recommandé d’utiliser les conventions Javascript pour
le nommage des attributs dans la réponse JSON
•  Utilisation du CamelCase
•  Majuscule ou minuscule selon le type de l’objet
"createdAt": 1320296464
Dr. Lilia SFAXI
Slide 39

12. Recherche
•  Pour une recherche globale, utiliser le mot clef search, et ?q
pour représenter la requête
/search?q=fluffy+fur
•  Pour faire une recherche plus précise, précéder la requête du
domaine de recherche
/owners/5678/dogs?q=fluffy+fur
Dr. Lilia SFAXI
Slide 40

13. Domaine de l’URI
•  Il est recommandé de consolider toutes les requêtes d’API sous un
même sous-domaine
•  C’est plus propre, et plus facile pour les développeurs
•  Définir un nom de domaine unique (votre API gateway)
api.techdogrest.com
•  Définir un portail dédié pour les développeurs
developers.techdogrest.com
•  Définir des redirections pour les requêtes venant du navigateur
web:
•  Un appel du domaine de l’API du navigateur devrait être redirigé vers le portail
des développeurs
•  Utilisation de dev ou developer au lieu de developers devrait être redirigé vers
developers.techdogrest.com
Dr. Lilia SFAXI
Slide 41

Microservices
API Management
API Gateway
Pourquoi utiliser les APIs Gateways
Avantages et Inconvénients des APIs Gateway
Rôles du API Gateway
42
PLAN

Problèmes…
•  L’utilisation des microservices dans une application implique que les APIs
fournies sont de grain fin
•  Un client a donc besoin d’interagir avec plusieurs services pour réaliser une
opération
•  Des clients différents ont besoin de données différentes pour représenter la
même chose
•  Par exemple, la version web et la version mobile d’une page de détails d’un
produit ne représentent pas les mêmes éléments
•  La performance du réseau est différente pour chaque client
•  Un réseau mobile est plus lent et avec une latence plus haute qu’un réseau fixe
•  Une application web côté serveur peut faire beaucoup de requêtes aux services
back-end sans impacter l’UX, alors qu’une application mobile ne peut en faire
que très peu
•  Les services et leurs emplacements (port et hôte) peuvent changer
Dr. Lilia SFAXI
Slide 43
API Gateway

Solution
•  Utilisation d’un API Gateway, un point d’entrée unique pour tous les
clients
•  Permet de gérer les requêtes:
•  Soit par simple routage au service approprié
•  Soit en les distribuant sur plusieurs services
•  Peut exposer une API différente pour chaque client
•  Peut implémenter la sécurité
•  Contrôle d’accès aux APIs
Dr. Lilia SFAXI
Slide 44
API Gateway

Avantages
•  Permet de rendre transparent le partitionnement de
l’application en microservices
•  Évite au client la charge de connaître les emplacements de
toutes les instances de services utilisées
•  Fournit l’API optimale pour chaque client
•  Réduit le nombre de requêtes et d’aller-retours, en
permettant l’extraction de données à partir de plusieurs
sources en une seule requête
•  Idéal pour les applications mobiles
•  Simplifie le traitement côté client en déplaçant la logique
d’orchestration du client vers le gateway
Dr. Lilia SFAXI
Slide 45
API Gateway

Inconvénients
•  Augmentation de la complexité
•  Un middleware supplémentaire qui doit être configuré, déployé
et géré
•  Augmentation du temps de réponse dû au saut
supplémentaire pour appeler le gateway
•  Peut être négligeable comparé au temps d’aller-retour pour la composition
de services
Dr. Lilia SFAXI
Slide 46
API Gateway

•  Auhentification
•  Authentification pour chaque requête ou série de requêtes
•  Définit des règles d’accès aux services
•  La plupart des Gateways ajoutent les informations d’authentification aux
requêtes faites aux services en arrière plan
•  Permet de développer une logique spécifique à l’utilisateur au niveau des
microservices
•  Sécurité du Transport
•  Étant le point d’entrée unique aux APIs publiques, il doit sécuriser les accès
aux microservices
•  Utilisation d’un protocole sécurisé pour l’accès au Gateway (par exemple
SSL) puis suppression ou changement des contraintes de sécurité entre le
gateway et les services
Dr. Lilia SFAXI
Slide 47
API Gateway

•  Répartition de Charge
•  Distribution des requêtes parmi les instances de microservices
•  Répartir la charge entre les différents services selon leurs contraintes
respectives
•  Le gateway peut demander la création dynamique de nouvelles instances de
service si les instances existantes ne sont pas suffisantes
•  Dispatching des Requêtes
•  Le gateway peut travailler en tandem avec les Service Registries pour router
les requêtes vers le bon service
•  Gestion du routage des services inexistants ou obsolètes
Dr. Lilia SFAXI
Slide 48
API Gateway

•  Résolution de Dépendances
•  Fournir des façades (point d’entrée virtuels) qui routent les requêtes
systématiquement à plusieurs micorservices différents
•  Éviter ainsi les appels répétés vers un ensemble de microservices pour
réaliser une seule fonctionnalité
•  Phénomène des architectures bavardes (chatty)
•  Transformation
•  Adapter les requêtes des clients aux formats utilisés par les services, sans
déranger les deux parties
•  Conserver l’indépendance du développeur de l’API ainsi que du client
Dr. Lilia SFAXI
Slide 49
API Gateway

Articles
•  Martin Fowler, Microservices, http://martinfowler.com/articles/microservices.html rédigé le
25/03/14, consulté le 13/11/15
•  Margaret Rouse, API Management,
http://searchcloudapplications.techtarget.com/definition/API-management rédigé en
septembre 2014, consulté le 29/11/15
•  George Psistakis, API Management tools: How to find the one for you
http://www.developereconomics.com/api-management-tools-how-to-find-the-one-for-you/,
rédigé le 23/03/15, consulté le 29/11/15
•  Chris Richardson, MicroServices Patterns and Best Practices, http://microservices.io/ rédigé
en 2014, consulté le 6/12/15
•  Sebastiàn Peyrott, An Introduction to Microservices part 2: The API Gateway,
https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/ rédigé
le 13/09/2015, consulté le 6/12/15
White Papers
•  Choosing the Right API Management Solution for the Enterprise User, CA Technologies White
paper, september 2014
50
Sources

eServices-Chp5: Microservices et API Management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (12)

Ähnlich wie eServices-Chp5: Microservices et API Management

Ähnlich wie eServices-Chp5: Microservices et API Management (20)

Mehr von Lilia Sfaxi

Mehr von Lilia Sfaxi (20)

eServices-Chp5: Microservices et API Management