Les builds d’applications lorsqu’elles sont décomposées en plusieurs composants de service plus petits sont appelées microservices. Par rapport à la méthode monolithique traditionnelle, une architecture de microservice traite chaque microservice comme une entité/un module autonome, aidant essentiellement à faciliter la maintenance de son code et de l’infrastructure associée. Chaque microservice d’une application peut être écrit dans une pile technologique différente, puis être déployé, optimisé et géré indépendamment.
Bien qu’en théorie, une architecture de microservices profite spécifiquement à la construction d’applications complexes à grande échelle, elle est également largement utilisée pour les constructions d’applications à petite échelle (par exemple, un simple panier d’achat) – dans le but d’évoluer davantage.
Avantages d’une architecture de microservices
- Les microservices individuels au sein d’une application peuvent être développés et déployés via différentes piles technologiques.
- Chaque microservice peut être optimisé, déployé ou mis à l’échelle indépendamment.
- Meilleure gestion des défauts et détection des erreurs.
Composants d’une architecture de microservices
Une application cloud native moderne s’exécutant sur une architecture de microservices repose sur les composants critiques suivants :
- Conteneurisation (via des plateformes comme Docker) – pour une gestion et un déploiement efficaces des services en les divisant en plusieurs processus.
- Orchestration (via des plates-formes telles que Kubernetes) – pour la configuration, l’affectation et la gestion des ressources système disponibles aux services.
- Service Mesh (via des plateformes comme Istio) – pour la communication inter-services via un maillage de proxys de service pour connecter, gérer et sécuriser les microservices.
- Les trois éléments ci-dessus sont les composants les plus importants d’une architecture de microservices qui permettent aux applications d’une pile native du cloud de s’adapter à la charge et de fonctionner même en cas de défaillance partielle de l’environnement cloud.
Complexités d’une architecture de microservices
Lorsqu’une grande application est décomposée en plusieurs microservices, chacun utilisant une pile technologique différente (langage, base de données, etc.), nécessitant plusieurs environnements forment une architecture complexe à gérer. Bien que la conteneurisation Docker aide à gérer et à déployer des microservices individuels en divisant chacun en plusieurs processus s’exécutant dans des conteneurs Docker distincts, la communication inter-services reste extrêmement compliquée car vous devez gérer la santé globale du système, la tolérance aux pannes et plusieurs points de défaillance.
Pourquoi avons-nous besoin d’un Service Mesh ?
Maintenant que vous connaissez l’importance d’une communication de service à service dans une architecture de microservices, il semble évident que le canal de communication reste sans faille, sécurisé, hautement disponible et robuste. C’est là qu’intervient un Service Mesh en tant que composant d’infrastructure, qui assure une communication contrôlée de service à service en implémentant plusieurs proxys de service. Un Service Mesh est chargé d’affiner la communication entre les différents services plutôt que d’ajouter de nouvelles fonctionnalités.
Dans un service Mesh, les proxys déployés aux côtés de services individuels permettant la communication inter-services sont largement connus sous le nom de Sidecar Pattern. Les side-cars (proxy) peuvent être conçus pour gérer toutes les fonctionnalités essentielles à la communication inter-services telles que l’équilibrage de charge, la coupure de circuit, la découverte de services, etc.
Grâce à un Service Mesh, vous pouvez
- Maintenir, configurer et sécuriser toutes les communications de service à service entre tous les microservices ou certains microservices d’une application.
- Configurer et exécuter des fonctions réseau au sein des microservices telles que la résilience du réseau, l’équilibrage de charge, la coupure de circuit, la découverte de services, etc.
- Les fonctions réseau sont maintenues et mises en œuvre en tant qu’entité distincte de la logique métier, répondant au besoin d’une couche dédiée pour le découplage de la communication de service à service du code d’application.
- En conséquence, les développeurs peuvent se concentrer sur la logique métier de l’application, tandis que la totalité ou la majeure partie du travail lié à la communication réseau est gérée par le Service Mesh.
- Étant donné qu’une communication proxy Microservice vers Service Mesh est toujours au-dessus des protocoles standard tels que HTTP1.x/2.x, gRPC, etc., les développeurs peuvent utiliser n’importe quelle technologie pour développer des services individuels.
Composants d’une architecture Service Mesh
Logique métier
Celui-ci contient la logique d’application principale et le code sous-jacent d’un microservice. Une logique métier conserve également le calcul de l’application ainsi que la logique d’intégration service à service. La logique métier peut être écrite sur n’importe quelle plate-forme et reste complètement indépendante d’un service différent.
Fonctions réseau primitives
Cela inclut les fonctions réseau de base utilisées par un microservice pour lancer un appel réseau et se connecter au proxy sidecar de service mesh. Bien que les principales fonctions réseau parmi les microservices soient gérées via le Service Mesh, un service donné doit contenir les fonctions réseau de base pour se connecter au proxy side-car.
Fonctions du réseau d’applications
Contrairement aux fonctions réseau primitives, ce composant via un proxy de service maintient et gère les fonctions réseau critiques, notamment la coupure de circuits, l’équilibrage de charge, la découverte de services, etc.
Plan de contrôle du maillage de services
Tous les proxys de service mesh sont gérés et contrôlés de manière centralisée par un plan de contrôle. Grâce à un plan de contrôle, vous pouvez spécifier des politiques d’authentification, la génération de métriques et configurer des proxys de service sur le maillage.
Implémentation de Service Mesh avec Istio
Bien qu’il existe plusieurs autres, étant les plus populaires, nous explorerons comment Istio peut être utilisé pour implémenter une architecture Service Mesh pour une application cloud native.
Comme expliqué dans les sections ci-dessus, dans une architecture de microservices, Istio forme une couche d’infrastructure pour connecter, sécuriser et contrôler la communication entre les services distribués. Istio déploie un proxy Istio (appelé side-car Istio) à côté de chaque service avec peu ou pas de modifications de code sur le service en lui-même. Tout le trafic interservices est dirigé vers le proxy Istio, qui utilise des politiques pour contrôler la communication interservices tout en mettant en œuvre des politiques essentielles de déploiements, d’injections de pannes.
Capacités de base d’Istio
- Communication sécurisée de service à service grâce à l’authentification et à l’autorisation.
- Implémentez des couches de politique prenant en charge les contrôles d’accès, les quotas et l’allocation des ressources.
- Équilibrage de charge automatique pour le trafic HTTP, gRPC, WebSocket et TCP.
- Métriques, journaux et traces automatiques pour tout le trafic au sein d’un cluster, y compris l’entrée et la sortie du cluster.
- Configurez et contrôlez la communication inter-services via les basculements, l’injection de fautes et les règles de routage.
- Implémentez des couches de stratégie prenant en charge les contrôles d’accès, les quotas et l’allocation des ressources.
Istio étant indépendant de la plate-forme, il peut être exécuté dans divers environnements, notamment Cloud, On-Premise, Kubernetes, etc. Istio prend actuellement en charge :
- Déploiement de services sur Kubernetes
- Services enregistrés auprès du Consul
- Services exécutés sur des machines virtuelles individuelles
Composants principaux d’Istio
Le service mesh Istio se compose d’un dataplane et d’un controlplane.
- Le dataplane se compose des proxys de service side-car (via Envoy), tandis que la communication side-car entre les microservices est réalisée via un hub de stratégie et de télémétrie (via Mixer).
- Le controlplane gère et configure la communication entre tous les proxys side-car via Pilot, Citadel et Galley. Tandis que Pilot applique les règles de routage et la découverte de service des proxys Envoy, Citadel agit en tant que canal d’authentification et d’autorisation. Galley, d’autre part, agit en tant que composant de validation, d’ingestion, de traitement et de distribution de la configuration de Service Mesh.
- Le controlplane finit par gérer et maintenir les composants du plan de données et constitue donc la couche la plus importante du mesh Istio.