eservices-chp5: microservices et api management
TRANSCRIPT
Microservices & API Management Chapitre 5 - eServices
GL5 2015/2016
Dr. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 5
Microservices
Approche Monolithique vs Approche 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 6
Microservices
Approche Monolithique vs Approche 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 7
Microservices
Approche Monolithique vs Approche 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 8
Microservices
Approche Monolithique vs Approche Microservices
Dr. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 10
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 11
Microservices
UI Métier BD
Service1
Service2 Service3
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 12
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 13
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 14
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 15
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 16
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 17
Microservices
Architecture Microservices : Caractéristiques
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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 util isant 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 23
API Management
Fonctionnalités des Outils de 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 visibi l ité necessaire sur leur uti l isation 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 portai l 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’uti l isation • Charger uniquement certaines fonctionnal ités • Charger pour une certaine priorité d’usage ou pour une qual ité de service meil leure
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 24
API Management
Fonctionnalités des Outils de 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 26
API Management
Classement des Outils de API Management
Dr. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 30
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 31
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 32
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 33
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 34
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 35
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 36
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 37
Recommandations pour la Conception d'APIs
10. Support de Plusieurs Formats
• Il est recommandé de supporter plusieurs formats de réponse • I l 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 • I l est moins verbeux que XML
Dr. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 38
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 39
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 40
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 41
Recommandations pour la Conception d'APIs
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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 46
API Gateway
Rôles du 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 47
API Gateway
Rôles du 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 48
API Gateway
Rôles du 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. L i l i a SFAXI www. l i l i asfax i .wix .com /l i l i asfax i
S l ide 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