Architectures Microservices : introduction générale

SOA – Microservices Mickaël BARON – 2016 (Rév. Mai 2022)
mailto:[email protected] ou mailto:[email protected] mickael-baron.fr mickaelbaron Introduction générale

Microservices - Généralités - M. Baron - Page mickael-baron.fr mickaelbaron
2 Creative Commons Contrat Paternité Partage des Conditions Initiales à l'Identique 2.0 France creativecommons.org/licenses/by-sa/2.0/fr Licence

3 A propos de l’auteur … Mickaël BARON Ingénieur de Recherche au LIAS https://www.lias-lab.fr Equipe : Ingénierie des Données et des Modèles Responsable des plateformes logicielles, « coach » technique Ancien responsable Java de Developpez.com (2011-2021) Communauté Francophone dédiée au développement informatique https://java.developpez.com 4 millions de visiteurs uniques et 12 millions de pages vues par mois 750 00 membres, 2 000 forums et jusqu'à 5 000 messages par jour mickael-baron.fr mickaelbaron

4 Plan du cours Contexte des applications monolithiques Microservice : quels sont les besoins ? Architecture microservices c’est quoi ? Comparaison avec les architectures existantes Technologies mises en œuvre

5 Déroulement du cours : Introduction générale Pédagogie du cours Des bulles d’aide tout au long du cours Comprendre l’utilité des microservices Pas de technique pour l’instant Pré-requis Ingénierie des données Cours architectures orientées services Service web REST Ceci est une alerte Ceci est une astuce

6 Ressources : Liens sur le Web Billets issus de Blog www.nginx.com/blog/introduction-to-microservices blog.loof.fr/2014/05/small-is-beautiful.html cdelmas.github.io/2015/11/01/A-comparison-of-Microservices-Frameworks.html dzone.com/articles/building-microservices-with-java www.touilleur-express.fr/2015/02/25/micro-services-ou-peon-architecture klangism.tumblr.com/post/80087171446/microservices Articles microservices.io/patterns/microservices.html martinfowler.com/articles/microservices.html www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise- service-bus-part-one dzone.com/storage/assets/293353-rc215-microservices.pdf Présentations fr.slideshare.net/gboissinot/p-microservices101-20150210 www.pst.ifi.lmu.de/Lehre/wise-14-15/mse/microservice-architectures.pdf fr.slideshare.net/jpetazzo/docker-quels-enjeux-pour-le-stockage-et-reseau-paris-open- source-summit-2015

7 Ressources : Bibliothèque The art of Scalability Auteur : Michael T. Fisher and Martin L. Abbott Éditeur : Addison Wesley Edition : Juin 2015 - 624 pages - ISBN : 0134032802 Continuous Delivery Auteur : Jez Humble et David Farley Éditeur : Addison Wesley Edition : Août 2010 – 512 pages - ISBN : 0321601912 Building Microservices Auteur : Sam Newman Éditeur : O’Reilly Edition : Fév. 2015 – 280 pages - ISBN : 9781491950357

8 Evolution des applications … retour Exemple : application de co-voiturage Architecture dite « Monolithique » Architecture Orientée Service Clients Architecture Microservice Une grosse application Clients Base de données Interfaces web Connecteur pour envoie SMS API REST/SOAP Connecteur pour envoie EMAIL Connecteur pour paiement (Paypal) Entreprise Service Bus Une Application découpée par des services techniques reliés par un bus d’intégration Une Application découpée par des services fonctionnels Clients Service Conducteur Interface web Passager Connecteurs pour SMS, EMAIL et paiement Interfaces web Base de données API REST/SOAP Service Notification (SMS, EMAIL) Service Paiement Service Facturation Service Passager « Broker » de Messages

Application monolithique : rappel 9 Un gros code contenant toutes les fonctionnalités et les différentes couches logicielles Une seule grosse compilation et un seul livrable (un gros fichier WAR) Une seule pile logicielle (Linux, JVM, Tomcat et bibliothèques tierces) Présentation Logique métier Accès données

Architecture microservice : Généralités 10 Premières discussions autour du terme microservice en 2011 lors d’un workshop sur les architectures logicielles Les architectures microservices sont une évolution, une spécialisation des architectures orientées services (SOA) Vu comme une bonne pratique du SOA (ma vision) Articles de référence martinfowler.com/articles/microservices.html www.nginx.com/blog/introduction-to-microservices Citation courte de Sam Newman « Microservices are small, autonomous services that work together »

Microservice : Concepts 11 Des concepts présentés dans le premier cours restent valables (réutilisabilité, autonomie, sans état…) Huit nouveaux aspects caractérisent un microservice Fonctionnalité unique Flexibilité technologique Equipe réduite Déploiement ciblé Montée en charge « scalabilité » Tests facilités

Une seule fonctionnalité 12 Un microservice doit réaliser une seule fonctionnalité de l’application globale Un microservice peut contenir toutes les couches logicielles (IHM, middleware et base de données) Un microservice possède un contexte d’exécution séparé des autres (exemple : machine virtuelle ou conteneur) Service Conducteur Service Passager Service Notification (SMS, EMAIL) Service Paiement Service Facturation Interfaces web Passager Pour les applications web, séparer dans un microservice spécifique permet de fournir des expériences différentes aux utilisateurs

Flexibilité technologique 13 Utiliser les bons langages et frameworks selon la fonction- nalité à réaliser Play/Scala Jakarta EE (JSF/EJB/Java), Spring JQuery/AngularJS/NodeJS Django/Python Symfony/PHP Service Conducteur Service Passager Service Notification (SMS, EMAIL) Service Paiement Service Facturation Interface web Passager

Equipe réduite 14 Chaque microservice à sa propre équipe de développement L’équipe de développement orientée fonctionnalité est réduite et pluridisciplinaire Développeurs backend Développeurs web Administrateurs bases de données Service Conducteur Service Passager Service Notification (SMS, EMAIL) Service Paiement Service Facturation Interface web Passager

Déploiement ciblé 15 Evolution d’une certaine partie sans tout redéployer Un seul livrable à partir d’un seul code source Moins de coordination entre équipe quand il y a un seul déploiement Plus souvent Moins de risque Plus rapide Service Conducteur Service Passager Service Notification (SMS, EMAIL) Service Paiement Service Facturation Interface web Passager V1.0 V1.0 V2.0 V10.0 V5.0 V545.2

Montée en charge / scalabilité 16 Forte sollicitation sur un microservice ? page web : Amazon en période de « Black Friday » batch : compression de vidéos Comme chaque fonctionnalité est isolée possibilité de multiplier le nombre d’instances d’un microservice Service Conducteur Service Passager Service Notification (SMS, EMAIL) Service Paiement Service Facturation Interface web Passager V1.0 V1.0 V2.0 V10.0 V5.0 V545.2 Trois instances du même microservice

Montée en charge / scalabilité : cube de scalabilité 17 Scalabilité Axe Y Décomposition fonctionnelle Le livre « The art of Scalability » décrit trois dimensions pour la scalabilité Scalabilité Axe X Augmentation des instances Scalabilité Axe Z Partitionnem ent des données Application monolithique (JEE Application) Partitionner les données selon les besoins • Volumétrie excessive pour les fichiers vidéos ou musiques • Zone géographique Autant de microservices que de fonctionnalités Cloner les microservices qui ont une forte sollicitation (nécessite un loadbalancer) Utilisation d’un loadbalancer dans le cours suivant Netflix

Facilite les tests 18 Comme chaque fonctionnalité est isolée dans un microservice il est plus facile de les tester Les tests unitaires concernent la partie intrinsèque d’un microservice => on sait déjà faire Quels types de tests restants ? Service : stresser l’API exposée du microservice Bout-en-bout : intégrer les autres microservice (voir architecture microservice) Si c’est facile à tester alors c’est facile à déployer (principe du déploiement continu)

Architecture microservice 19 Une architecture microservice est donc un ensemble de microservices autonomes Pas de bus d’intégration (ESB) car il y a de la logique et donc cela force le couplage Utilisation d’un Broker de Messages pour le faible couplage Utilisation d’un Load Balancer pour équilibrer la charge Service Conducteur Service Passager Service Notification (SMS, EMAIL) Service Paiement Service Facturation Interface web Passager V1.0 V1.0 V2.0 V10.0 V5.0 V545.2 « Broker » de Messages LoadBalancer Synchrone Asynchrone Charge équilibrée

20 Applications Monolithique Versus Microservice q Une seule grosse application pour toutes les fonctionnalités q Un seul langage pour faciliter la communication q Couplage fort q Communication par les données Architecture Monolithique VS Architecture Microservice q Autant de microservices que de fonctionnalités q Plusieurs langages utilisés et API REST pour l’exposition q Couplage faible q Communication par les services

21 SOA Versus Microservice q Standards définis par OASIS q Bus d’intégration q Une seule fonctionnalité par service q Déploiement monolithique q Technologies imposées Architecture Orientée Service VS Architecture Microservice q Standards du web q « Broker » de Messages q Une seule fonctionnalité par microservice q Automatiquement déployable q Bonnes pratiques sans imposer des technologies q Mouvement « DevOps »

Architecture microservices : inconvénients 22 Plus de compilation lors de l’intégration pour vérifier si une API est cassée ou pas Multiplication des SGBD utilisés (relationnel ou NoSQL) et donc compétences nouvelles Développeur devient un opérationnel pour le déploiement Ne s’applique pas à toutes les entreprises Si déploiement fréquent => ok Si déploiement une fois l’an => monolithique

Qui utilisent les microservices ? 23 Uber : https://eng.uber.com/service-oriented-architecture Netflix : https://netflixtechblog.com Amazon : https://aws.amazon.com/fr/microservices Sound Cloud : https://developers.soundcloud.com/blog/building- products-at-soundcloud-part-2-breaking-the-monolith Le prochain Eclipse Che IDE Offres d’emploi (tendances à la hausse) https://www.linkedin.com/jobs/search?keywords=Micro+Services&location=France http://www.meteojob.com/candidate/offers/candidateOffersSearchResults.mj?q=micro +service+macro-job%3A14&cid=281982

Développer des architectures microservice ? 24 Savoir Isoler un microservice Savoir Coder le contenu du microservice Savoir faire Communiquer des microservices Savoir Composer les microservices Savoir Répartir les charges On va explorer les technologies du marché. Dans le cours suivant, on se focalisera sur une technologie pour chaque point

Isoler : Machine virtuelle ou Conteneur ? 25 Pour isoler un microservice utilisation de techniques de virtualisation Trois grandes techniques s’affrontent Conteneurs Machines Virtuelles Serveurs physiques Serveur Matériel Serveur Matériel Serveur Matériel OS OS Serveur Matériel OS OS Application Application Docker Daemon Binaires Bibliothèques Binaires Bibliothèques Application Application Hyperviseur OS Virtualisé OS Virtualisé Binaires Bibliothèques Binaires Bibliothèques Application Application 1 Application = 1 machine physique = trop coûteux

Isoler : Machine virtuelle VS Conteneur 26 Machine Virtuelle (574 Mo) Conteneur (100 Ko) Démarrage ~ 1 minute 0.2 seconde Mémoire min 256 Mo ~ 0.3 Mo Espace Disque min 1 Go ~ 0.1 Mo Comparatif sur les performances 2500 conteneurs ont été créés dans un Raspberry PI 2 https://blog.docker.com/2015/09/update-raspberry-pi-dockercon-challenge/

Isoler : les outils existants 27 Les outils pour construire des machines virtuelles Hyperviseur type 1 : Xen, VMware vSphere, Microsoft HyperV, KVM Hyperviseur type 2 : Oracle VirtualBox, VMware Player, QEMU Les outils pour construire des conteneurs Conteneur : Docker, LXC, Podman… Docker (https://www.docker.com) => le plus tendance … Basé sur LXC mais plus simple à mettre en œuvre Dispose d’un dépôt central fournissant des images prêtes à l’emploi Logiciel libre Service Conducteur V5.0 Ce microservice est isolé dans un conteneur

Coder 28 Utiliser les plateformes logicielles (Java, Python, JavaScript) que vous avez l’habitude d’utiliser Utiliser votre environnement de développement préféré (Eclipse, IntelliJ, Netbeans, Atom…) Utiliser des bibliothèques qui permettent d’exposer des services web (REST ou SOAP) Automatiser le déploiement de votre application afin de minimiser le temps

Coder : le cas de Java (sans microservice) 29 Serveur Matériel OS Conteneur Jakarta EE Bibliothèques Jar partagées Bibliothèques JAR Classes Actuellement une application web (war) développée en Java est déployée dans un serveur d’application Java Autres Applications Bibliothèques JAR Classes Contexte de l’application (war) Contient les classes et les ressources Contient les Bibliothèques Java spécifiques Contient les bibliothèques globales à tous les War …

Coder : le cas de Java (avec microservice) 30 Trois stratégies pour développer des microservices en Java in-JavaContainer : conteneur Jakarta EE et un War (comme avant) JavaContainer-less : un gros Jar contenant toutes les bibliothèques self-contained : un gros Jar en utilisant un micro-framework In-JavaContainer JavaContainer-less Self-contained Serveur Matériel OS Docker Binaires Bibliothèques Binaires Bibliothèques Conteneur Jakarta EE Application Bibliothèques JAR WAR … Serveur Matériel OS Docker Binaires Bibliothèques Binaires Bibliothèques Application JAR … Conteneur Jakarta EE embedded Bibliothèques JAR Serveur Matériel OS Docker Binaires Bibliothèques Binaires Bibliothèques Application JAR … Bibliothèques JAR

Coder : le cas de Java (JavaContainer-less en détail) 31 Le serveur d’application est embarqué dans l’application Le code source est le même que pour une application War Un gros Jar est distribué et prêt à l’exécution Solutions du marché Apache TomEE (anciennement OpenEJB) Wildfly Swarm (anciennement JBoss) Payara (à base de Glassfish) Serveur Matériel OS Docker Binaires Bibliothèques Binaires Bibliothèques Application JAR … Conteneur Jakarta EE embedded Bibliothèques JAR $ java -jar my-big-app-container-less.jar

Coder : le cas de Java (JavaContainer-less en détail) 32 Avantages Pas d’adaptation du code à faire, une simple méthode main à ajouter Rapide à démarrer Pratique pour les tests fonctionnels La plupart des serveurs d’application sont « embedded » Inconvénients Ne fournit pas toutes les fonctionnalités d’un serveur (admin ?) Difficulté de modification du serveur à chaud ? L’application est dépendante du serveur, recompiler pour changer Fournit toutes les bibliothèques de la pile Jakarta EE

Coder : le cas de Java (self-contained en détail) 33 Serveur Matériel OS Docker Binaires Bibliothèques Binaires Bibliothèques Application JAR … Bibliothèques JAR Utilisation d’un micro-framework Le code source est le même que pour une application War Un gros Jar est distribué et prêt à l’exécution C’est quoi un micro-framework ? Framework orienté service web minimaliste Opposé au framework qui font tout full-stack Des dépendances Maven « à la carte » Des modules pour simplifier le développement et le monitoring d’exécution $ java -jar my-big-app-self-contained.jar

Coder : le cas de Java (self-contained en détail) 34 Deux familles de micro-framework pour Java s’affrontent SpringBoot Basé sur Spring Est un PRODUIT https://start.spring.io/ pour faciliter la création de projet Starters pour gérer les dépendances Auto-configuration (moins d’XML) Métriques accessibles via services web (Actuator) Métrique de l’application (CPU, mémoire) Beans (liste des Beans) Trace (requêtes HTTP envoyées) DUMP (threads en cours) HEALTH (état de santé de l’application) … Eclipse MicroProfile Basé sur Jakarta EE (CDI, JAX-RS, JSON-P) Est une SPECIFICATION Gestion de la configuration Tolérance aux pannes Authentification avec JWT Métriques Trace de JAX-RS

Coder : le cas de Java (self-contained en détail) 35 Avantages Délivre le strictre nécessaire (configuration à la “carte”) S‘appuie sur des bibliothèques déjà connues par les développeurs Adaptation rapide de votre code source Fournit des bibliothèques pour monitorer votre déploiement Inconvénients Apprentissage d’une nouvelle bibliothèque Nombre important de micro-frameworks sur le marché, fait-on le bon choix ?

Coder : le cas de Java - MicroProfile 36 Eclipse MicroProfile est une spécification pour le développement de microservices avec le langage Java Initiative indépendante de Java EE qui se voulait combler l’absence de solution pour développer des microservices Java Site web : https://microprofile.io Version actuelle : 5 (décembre 2021) Différentes implémentations (pas forcément alignées avec les dernières versions de la spécification)

Coder : le cas de Java - MicroProfile 37 La spécification s’appuie sur des spécifications Jakarta EE et des API spécifiques MicroProfile 5 JAX-RS 3.0 JSON-P 2.0 CDI 3.0 Config 3.0 Fault Tolerance 4.0 JWT Propagation 2.0 Health Check 4.0 Metrics 4.0 Open Tracing 3.0 Open API 3.0 Rest Client 3.0 JSON-B 2.0 Pour l’injection de dépendance API pour manipuler du JSON API pour développer des services web RES API de « binding » Java vers JSON Pour connaître l’état d’un microservice Pour la gestion des tokens JWT (authentification et autorisation) Pour la configuration d’un microservice API pour l’accès à des services web REST Pour fournir une API unifiée au format Open API (ex Swagger) Pour fournir des traces lors de l’utilisation des services web REST Spécification qui fournit des mécanismes de secours (si un service n’est pas disponible) Fournit des métriques sur l’utilisation d’un microservice

Communiquer 38 La communication entre des microservices peut se faire conjointement ou pas via Services web REST ou SOAP => communication synchrone Technologies « Push » WebSocket ou SSE => communication asynchrone Technologies basées sur l’envoi de messages AMQP => communication asynchrone

Composer 39 La composition va permettre de résoudre le problème d’orchestration des conteneurs Exemple simple pour comprendre cette problématique A = un conteneur pour la base de données (MySQL) B = un conteneur applicatif A doit être démarré avant B et B a besoin d’accéder à A (ouverture de port) B fortement sollicité, alors besoin d’augmenter le nombre d’instances de B Solutions du marché Docker Compose (Docker inc.) => le plus simple Docker Swarm (Docker inc.) Kubernetes (Linux Foundation Project, ex projet Google) Mesos (Apache) Fleet (CoreOS) Consul…

Répartir la charge : reverse proxy 40 Problématique du pourquoi utiliser un reverse proxy Plusieurs microservices vont être créés Plusieurs instances d’un même microservice peuvent être créées Reverse Proxy ou « Proxy inversé » Donne accès depuis un réseau externe aux conteurs d'un réseau interne Distribuer en fonction de la charge, les requêtes web aux conteneurs les moins occupées (d’une même image par exemple) Solutions libres du marché Nginx (www.nginx.com) Otoroshi (www.otoroshi.io) Haproxy (www.haproxy.org) Træfik (traefik.io) Vulcand (vulcand.readthedocs.io) HTTPD

Bilan 41 L’architecture microservices n’est pas la solution à tous les problèmes de performances d’un applicatif Problèmes courants Modélisation Persistance des données Transaction Front-end non adapté Les microservices adressent le problème d’architecture et sont là pour faciliter la monté en charge Attention : il n’a jamais été précisé que les architectures monolithiques étaient mortes

Pour aller plus loin 42 Les bonnes pratiques pour passer à une architecture microservices => partir d’une application monolithique Déploiement vers des clusters Logging, Monitoring Transaction Sécurité Tolérance au panne (inaccessibilité des microservices)

Architectures Microservices : introduction géné...

Architectures Microservices : introduction générale

More Decks by Mickael BARON

Other Decks in Programming

Featured

Transcript