Eservices chp5 Microservices Et Api Management

GL5
2015/2016
Microservices & API Management

Chapitre 5 - eServices
Dr. Lilia SFAXI

Slide 1
www.liliasfaxi.wix.com /liliasfaxi
PLAN
Microservices
API Management
API Gateway
2
PLAN
Microservices
Définition des Microservices
Approche Monolithique vs Microservices
Caractéristiques de l’A rchitecture Microservices
API Management
API Gateway
3
Définition des Microservices
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
Approche Monolithique vs Approche Microservices
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
Architecture Microservices : Caractéristiques
Microservices
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
UI Métier BD
•  Solution: Division logique des équipes Service1

•  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)
Service2 Service3
Dr. Lilia SFAXI
Slide 11
Microservices
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
PLAN
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
Mouvement Open API
API Management
•  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’e ntreprise qui publie l’A PI
(modification de l’A PI, ajout de frais…)
Dr. Lilia SFAXI

Slide 20
Définition
API Management
•  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
Challenges de l’API Management
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’A PI 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
Fonctionnalités des Outils de API Management
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’A PI
•  S’assurer que les mises à jour ou versionning de l’A PI, 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’A PI
•  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’A PI 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’A PI 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’e xpérimentation de
l’e nvironnement de production
•  Permettre au consommateur de l’A PI de tester l’A PI 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
Types de Solutions de API Management
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
Classement des Outils de API Management
API Management
Gartner Magic Quadrant for Application Services Governance
Dr. Lilia SFAXI

Slide 27
Recommandations pour la Conception d’APIs
API Management
Voici quelques recommandations pour l’é criture d’une

« bonne » API, ce n’e st pas la seule, peut-être pas la meilleure,
mais c’e st 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
1. Accès aux ressources : Nouns are Good, Verbs are Bad
Recommandations pour la Conception d'A PIs
•  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:
Ressource POST GET PUT DELETE

/dogs Créer un nouveau Lister les chiens Modifier plusieurs Supprimer tous les
chien chiens en masse chiens
/dogs/1234 Erreur Afficher le chien Si le chien existe, Supprimer le chien

1234 l’afficher, sinon Erreur 1234
Dr. Lilia SFAXI

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

Slide 33
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’A PI 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’e st 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’A PI 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’A PI 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
PLAN
Microservices
API Management
API Gateway
Pourquoi utiliser les APIs Gateways
Avantages et Inconvénients des APIs Gateway
Rôles du API Gateway
42
Problèmes…
API Gateway
•  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
Solution
API Gateway
•  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
Avantages
API Gateway
•  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’A PI optimale pour chaque client
•  Réduit le nombre de requêtes et d’aller-retours, en
permettant l’e xtraction 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
Inconvénients
API Gateway
•  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’e ntré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’e ntré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’A PI ainsi que du client
Dr. Lilia SFAXI

Slide 49
Sources
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

Eservices chp5 Microservices Et Api Management

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eservices chp5 Microservices Et Api Management

Uploaded by

Copyright:

Available Formats

GL5

Microservices & API Management

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

• Solution: Division logique des équipes Service1

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Gartner Magic Quadrant for Application Services Governance

Dr. Lilia SFAXI

Voici quelques recommandations pour l’é criture d’une

Dr. Lilia SFAXI

Ressource POST GET PUT DELETE

/dogs/1234 Erreur Afficher le chien Si le chien existe, Supprimer le chien

Dr. Lilia SFAXI

• Il est plus lisible d’utiliser le pluriel pour représenter un type de

Dr. Lilia SFAXI

• Une association entre deux ressources devrait être représentée de la

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

• Une réponse partielle permet de donner aux développeurs

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

• Il est recommandé d’utiliser les conventions Javascript pour

Dr. Lilia SFAXI

• Pour une recherche globale, utiliser le mot clef search , et ?q

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

Dr. Lilia SFAXI

You might also like

•  Solution: Division logique des équipes Service1

•  Il est plus lisible d’utiliser le pluriel pour représenter un type de

•  Une association entre deux ressources devrait être représentée de la

•  Une réponse partielle permet de donner aux développeurs

•  Il est recommandé d’utiliser les conventions Javascript pour

•  Pour une recherche globale, utiliser le mot clef search , et ?q