Le terme ‘Microservices’ fait le buzz depuis plusieurs mois déjà dans l’ingénierie logicielle. Durant cette soirée, Zenika vous propose de décrire en détail cette technique de décomposition de son système d’information.
La première partie de la soirée présente les enjeux des MicroServices et les différents cas d’utilisation.
La seconde partie aborde différents frameworks Java qui peuvent être utilisés pour la mise en place d’une architecture MicroServices.
4. Les Microservices favorisent le découpage de
son système d’information en de petites unités
métiers indépendantes et autonomes
« Fine-grained architecture »
8. Focalisé minutieusement sur une et une seule
responsabilité
Possédant un contexte d’exécution séparé
(propre machine, propre processus, propre container, etc)
Communique à travers une interface uniforme
Capable d’être déployé indépendamment et de manière
automatisé
Utilise un système d’inscription et de désinscription du
réseau de Microservices
9. « Gather together those things that
change for the same reason, and
separate those things that change for
different reasons »
Chaque service est
une application métier autonome
Extension du pattern Single Responsability
Pattern (SPR) au système d’information
10. La liberté des Microservices permet de réagir et de
prendre des décisions plus rapidement
à des changements inévitables
(fonctionnels, techniques, organisationnels, etc)
Responsive
Elastic Resilient
Message
-driven
Reactive Manifesto Pattern
11. Service 1
« Python »
Document
Database
Service 2
Clojure
Graph
Database
Service 3
Java
SQL
Database
Attention: Trouver le bon compromis entre
l’autonomie des équipes (avec la flexibilité du
choix) et le besoin de standardisation
12. Service 1
C++
Service 2
Python
Service 3
Java
On crée des équipes pluridisciplinaires co-localisés
orientées « Feature Métier »
Build & Run
Build & Run
Build & Run
20. IMPL
PUBLIC
API
Service
Une bonne API
• Agnostique à un
langage
• Porte la logique
d’intégration
Votre API est votre contrat en regroupant
l’ensemble des opérations exportables pour vos
consommateurs.
Elle doit évoluer indépendamment de votre code
21. ?
De nombreux
protocoles et API
d’intégration:
RMI
JAX-RPC
JAX-WS
JMS
SOAP/HTTP
REST/HTTP
AMQ
etc
Trouver la communication la
plus simple possible!
22. Dans le cas d’une base de données mutualisée,
l’évolution des services suit l’évolution du
schéma de base, les services sont fortement
couplés.
Shared
Database
24. Duplication de l’information (de la donnée)
dans chaque service
Gestion de la donnée à travers du code
ou du paramétrage (fichier de conf, etc)
Encapsulation dans un service dédié
25. Complex Integration System
(Encapsulate Logic)
Un bus d’intégration avec de la logique
(routage, transformation, etc) fournit de
l’intelligence dans la communication
ce qui introduit une forme de couplage
26.
27. APIA
APIB
Protocole A
Technologie A
Format de données A
Protocole B
Technologie B
Format de données B
L’intégration doit être simple et favoriser
le faible couplage des services
Synchrone
ou
Asynchrone
Pas
d’intelligence
28. 1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service
1
Service
1
Service
2
Service
2
Event
subscribespublishes
29. Conçu pour cacher les appels distants
Diminue l’interdépendance des services en raison
du partage d’un contrat
Fragile car on doit livrer un nouveau contrat à
chaque changement
La fiabilité du réseau et le coût du marshalling
sont à prendre en compte
30. On connaît les fonctionnalités mais on abstrait
la localisation des services
La sémantique des messages pilotent le
traitement des opérations
Des clients tolérants aux changements
Découplé temporellement & Physiquement
32. Exploitation des méthodes HTTP
(GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS)
Facile à consommer avec tous les langages
Plusieurs solutions pour la gestion des
versions
Dans les communications modernes, REST/HTTP
tend à remplacer les autres technologies
d’intégration comme SOAP/HTTP
34. Les réponses REST contiennent
les liens dont on a besoin
Les clients interagissent par « hypermedia »
Pas de connaissance préétablie de comment
interagir avec le serveur
Le concept de HATEOS est unique. Cela permet au
serveur d’évoluer fonctionnellement de manière
indépendante des clients
35.
36. On publie des événements
On souscrit à la réception d’événements
A chaque changement, un événement est
envoyé
37. Les Microservices publient des événements
en cas de changement d’état
Les autres Microservices souscrivent aux
événements publiés
• Synchronisation de la donnée répliquée
• Maintient de la consistance entre plusieurs
systèmes
L’utilisation d’événements au niveau applicatif permet de
garder la synchronisation des données répliquées et la
consistance des données entre plusieurs systèmes
39. Compréhension du bénéfice d’avoir des équipes
autonomes gérant tout le cycle de vie des produits
(conception, implémentation, déploiement)
Création d’outils pour faciliter l’indépendance et
l’autonomie des équipes
• Amazon Web Services
• Suite d’outils Netflix (Hystrix, Eureka, etc)
Utilisation massive du PaaS (Cloud)
A
40. Librairie contrôlant la collaboration entre les différents
services pour offrir une grande tolérance à la latence
et à l’échec
Isole l’accès et permet d’éviter « the failure
cascade » en offrant des solutions de repli (fallback)
43. Shared Library
Modules
Les architectures Microservices peuvent être combinées
avec d’autres techniques de décomposition.
Service Service Service
Library
ModuleAv1
ModuleAv2
ModuleB
44. Uniquement les librairies dynamiques évitent
d’avoir à redéployer tous le processus en cas
de changement
Ne pas hésiter à dupliquer du code à travers
plusieurs services
Essayer de se limiter à l’usage de librairies techniques
Le principe « DRY » ne doit être respecté qu’au sein
d’un service
45. Erlang propose en natif
sa notion de modules
Java avec OSGI n’a pas marché
en raison de sa mauvaise intégration au
langage
En dehors de Erlang, l’implémentation des modules
ne permet pas de bénéficier de tous les avantages
des Microservices
46. « A Bounded Context is a specific responsability
enforced by explicit boundaries »
On regroupe en bloc fonctionnel cohérent
Favorise le faible coupage et la forte cohésion
On évite d’avoir du code anémique
On garde la logique au sein du service
47. Toujours penser au service de plus haut
niveau, puis affiner uniquement
si nécessaire ensuite
49. Au début d’un projet, on ne connaît pas tout le scope
du projet (le domaine change au fur et à mesure)
On a tendance à créer un Microservices à chaque
nouveau besoin
Découper trop tôt en Microservices peut empêcher
d’avoir une cohérence globale
Il est plus facile de décomposer en Microservices
une base de code existante que de partir de Zéro
50. On écrit des API qui répondent à des besoins réels et
pas à des besoins futurs non idientifiés
On écrit des API qui est plus propice à l’extension
qu’à la modification
On limite le nombre de Microservices et on n’hésite
pas à faire du code jetable
On prend le temps sur la conception de la
modélisation de la donnée échangée
52. Un « seam » est un bloc de code
indépendant
Ne pas hésiter à s’aider du découpage
en package
Chaque « seam » va délimiter la frontière de son
service
Trouver le bon découpage nécessite de comprendre
le fonctionnel et le métier des différentes
applications / services par les utilisateurs
54. On découpe toujours d’abord les données pour
éviter de collaborer par le système de persistance
Import
Code
Monolithic
Schema
Monolithic Service
Promotion
Code
Import
Code
Import
Schema
Promotion
Code
Promot
ion
Schema
Import
Service
Import
Schema
Promotion
Service
Promot
ion
Schema
Monolithic Service
1 2 3
56. Un nouveau langage
ou une nouvelle technologie
à chaque service
Communication inter-service
Des systèmes de compensation
avec des cas d’utilisation transverses
entre les services
61. On prend en considération la mixité
technologique au niveau CI
On automatise la construction (CI) et le
déploiement (CD) de chaque service
On doit assurer une certaine cohérence dans
la livraison logicielle
On doit fournir un unique point d’administration
63. L’approche de la virtualisation est intéressante mais
elle a coût
Utilisation ou création d’images
On peut « povisionner » l’image pour les
besoins (Chef, Puppet, Ansible)
On voudrait idéalement exécuter chaque service
dans une VM séparée (chaque service apporte son
environnement)
64. L’approche de la virtualisation est intéressante mais
elle a coût
Processus de création
d’une image assez long
Les images sont souvent volumineuses
(ex: > 20Go)
Le démarrage d’une VM peut prendre
plusieurs minutes
65. Les hyperviseurs (comme KVM, Xen, etc) sont basés sur
l’émulation d’infrastructure.
C’est coûteux en terme de prérequis.
L’approche Container propose une approche lightweight
68. L’approche de la virtualisation est intéressante mais
elle a coût
Plateforme construite sur
des containers Unix LXC
On crée et on déploie des applications comme
des images dans le monde de la virtualisation
Facilite le provisioning de chaque service
S’appuie sur une registry d’images Docker
69. Une intégration dans les principaux outils de
l’usine logicielle
(Jenkins, Artifactory Pro, DockerHub, etc)
CoreOs (un Linux avec des services Docker)
Gestion de plusieurs containers (kubernetes,
CoreOs’s cluster, etc)
73. L’enjeu initial du SOA
• Découper une application monolithique en
services (favorisant la réutilisabilité)
• Focalisé sur l’intégration en lieu et place du
couplage des composants
Ce qui a généralement manqué
• Abstrait jusqu’à la mise en production
• Difficile à changer (ESB pattern)
• Manque de consensus de faire du SOA
correctement
75. Ne cédez pas à toutes les possibilités offertes
Surveiller, surveiller, … votre production!
L’enjeu est toujours de trouver le bon niveau de
granularité
Déporte une certaine complexité au niveau de
l’intégration et donc du déploiement
Nécessite d’avoir des cas d’usage qui s’y prêtent et
d’avoir des équipes « produit » compétentes pour sa
mise en place