Architectures Microservices : introduction générale

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

View Slide

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

View Slide

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
@mickaelbaron
mickael-baron.fr

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
Bus d’événements

View Slide

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

View Slide

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 »

View Slide

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

View Slide

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

View Slide

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
(SMS, EMAIL)
Facturation
Interface web
Passager

View Slide

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
(SMS, EMAIL)
Facturation
Interface web
Passager

View Slide

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
(SMS, EMAIL)
Facturation
Interface web
Passager
V1.0 V1.0 V2.0
V10.0 V5.0
V545.2

View Slide

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
(SMS, EMAIL)
Facturation
Interface web
Passager
V1.0 V1.0 V2.0
V10.0 V5.0
V545.2
Trois instances
du même
microservice

View Slide

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

View Slide

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)

View Slide

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 Bus d’événements pour le faible couplage
Utilisation d’un Load Balancer pour équilibrer la charge
Service Conducteur
Service Passager
(SMS, EMAIL)
Facturation
Interface web
Passager
V1.0 V1.0 V2.0
V10.0
V5.0
V545.2
Bus d’événements
LoadBalancer
Synchrone
Asynchrone
Charge équilibrée

View Slide

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

View Slide

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 Bus d’événement
q Une seule fonctionnalité
par microservice
q Automatiquement déployable
q Bonnes pratiques sans
imposer des technologies
q Mouvement « DevOps »

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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/

View Slide

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, CoreOS rkt, LXC
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

View Slide

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

View Slide

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
…

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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 ?

View Slide

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)

View Slide

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

View Slide

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 Publish-Subscribe
AMQP => communication asynchrone

View Slide

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…

View Slide

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

View Slide

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 adresse 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

View Slide

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)

View Slide

Architectures Microservices : introduction générale

Architectures Microservices : introduction générale

Mickael BARON

More Decks by Mickael BARON

Other Decks in Programming

Featured

Transcript