Service Mesh
Quand vous avez de plus en plus de services il peut devenir très compliqué de gérer l’ensemble des communications inter-service.
Problématique
Les microservices communiquent énormément entre eux, par conséquent de nombreux problèmes peuvent survenir :
- Timeout
- Securité
- Rejouer
Première approche
En conséquence, les développeurs ont fini par utiliser des bibliothèques et des composants tiers tels qu’Eureka, Ribbon, Hystrix pour fournir ces fonctionnalités communes supplémentaires : service discovery, load balancing, circuit breaker, logging, etc …
Mais avec cette approche, notre logique métier et la configuration sont fortement couplées. La compléxité augmente et il peut vite devenir compliquer de maintenir toute cette architectures sur plusieurs dizaines de microservices.
Service Mesh
Un Service Mesh est un ensemble de composants logiciels qu’on positionne à côté du microservice et qui gère l’ensemble des communications inter-services.
Le Service Mesh est un service dédié qui va gérer l’ensemble des communications inter-services :
- Load balancing
- Service discovery
- Health checks
- Authentication
- Traffic management and routing
- Circuit breaking and failover policy
- Security and policy management
- Metrics and telemetry
- Fault injection
Par conséquent, l’ensemble des microservices ne communiquent maintenant qu’avec le Service Mesh. En général, le pattenr Sidecar est utilisé pour mettre en œuvre le Service Mesh, c’est-à-dire que le Service Mesh est déployé à côté (et non avec) de la logique métier.
Aller un peu plus loin
Tous les Service Mesh sont gérés de manière centralisée par un Control Panel. Ceci est très utile pour soutenir les capacités de maillage de services : contrôle d’accès, l’observabilité, la découverte de services, etc.
