PARTIE 1 | PARTIE 2 | PARTIE 3 | ||
---|---|---|---|---|
Sommaire général | Concevoir des microservices | Appels entre Microservices | Intégration continue et implémentation des tests | Références |
L’architecture microservice est un style d’architecture pour développer une application avec plusieurs petits services fonctionnant en utilisant des processus différents et utilisant des “moyens légers” pour communiquer. “Moyens légers” signifie, des moyens n’ayant pas une empreinte technique trop contraignante sur le code et sur les interactions entre les services.
L’approche consistant à séparer une application en plusieurs services n’est pas vraiment nouvelle, elle a déjà été tentée avec l’architecture orientée service (SOA pour “Service Oriented Architecture”):
- Pourquoi l’approche SOA n’a pas vraiment fonctionné ?
- Quelle est la différence entre l’approche SOA et l’approche Microservice ?
- Pourquoi retenter une séparation en plusieurs services alors que cette approche n’a pas fonctionné avec SOA ?
Le but de cet article est d’expliquer l’architecture Microservice, de montrer les différences avec l’approche SOA et d’avoir un regard critique sur cette architecture.
Partie 1: Concevoir des microservices
Quelques définitions
Architecture orientée service (SOA)
Qu’est-ce que l’approche en microservices ?
Les microservices ne sont pas la solution idéale
Concevoir des microservices
Principe général
Séparation de la logique fonctionnelle en contextes bornés
Casser un monolithe
Application de DRY
Utiliser une base de données à partir de microservices
Partie 2: Appels entre Microservices
Choix des interfaces
Utiliser le “semantic versioning”
Créer un nouveau point d’accès en cas de “breaking changes”
Appels synchrones ou asynchrones
Tolérer les échecs partiels
Pattern “circuit breaker”
Chef d’orchestre ou chorégraphie
Service discovery
Connaître la configuration des services en avance
Pattern “client-side discovery”
Pattern “server-side discovery”
Quelques technologies utilisées pour les appels
Communications asynchrones par messagerie
Communications synchrones
REpresentational State Transfer (REST)
REST over HTTP
API RESTful
Partie 3: Intégration continue et implémentation des tests
Intégration continue
Effectuer une “build” pour tous les services
Effectuer une “build” par service
Plusieurs “build pipelines”
Appliquer des tests
Pyramide des tests
Tests unitaires
Tester un service
Stratégies de déploiement
Plusieurs services par hôte
Un service par hôte
Un service par “container”
Déploiement sans serveur