Partager via

Communications résilientes

Conseil / Astuce

Ce contenu est un extrait de l’eBook, Architecting Cloud Native .NET Applications pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

Miniature de la couverture du livre électronique Applications .NET natives cloud pour Azure.

Tout au long de ce livre, nous avons adopté une approche architecturale basée sur des microservices. Bien qu’une telle architecture offre des avantages importants, elle présente de nombreux défis :

  • Communication réseau hors processus. Chaque microservice communique sur un protocole réseau qui introduit la congestion du réseau, la latence et les erreurs temporaires.

  • Découverte des services. Comment les microservices découvrent-ils et communiquent-ils entre eux lors de l’exécution sur un cluster de machines avec leurs propres adresses IP et ports ?

  • Résilience. Comment gérer les défaillances à courte durée de vie et maintenir le système stable ?

  • Équilibrage de charge : Comment le trafic entrant est-il distribué entre plusieurs instances d’un microservice ?

  • Sécurité. Comment les problèmes de sécurité tels que le chiffrement au niveau du transport et la gestion des certificats sont-ils appliqués ?

  • Supervision distribuée. - Comment mettre en corrélation et capturer la traçabilité et la surveillance d’une requête unique sur plusieurs microservices consommatrices ?

Vous pouvez résoudre ces problèmes avec différentes bibliothèques et frameworks, mais l’implémentation peut être coûteuse, complexe et fastidieuse. Vous vous retrouvez également avec des problèmes d’infrastructure couplés à la logique métier.

Maillage de services

Une meilleure approche est une technologie en constante évolution intitulée Service Mesh. Un maillage de service est une couche d’infrastructure configurable avec des fonctionnalités intégrées pour gérer la communication de service et les autres défis mentionnés ci-dessus. Il dissocie ces préoccupations en les déplaçant vers un proxy de service. Le proxy est déployé dans un processus distinct (appelé sidecar) pour fournir l’isolation du code métier. Toutefois, le side-car est lié au service : il est créé avec lui, et partage son cycle de vie. La figure 6-7 montre ce scénario.

Maillage de service avec une voiture latérale

Figure 6-7. Maillage de service avec une voiture latérale

Dans la figure précédente, notez comment le proxy intercepte et gère la communication entre les microservices et le cluster.

Un maillage de service est divisé logiquement en deux composants disparates : un plan de données et un plan de contrôle. La figure 6-8 montre ces composants et leurs responsabilités.

Contrôle de maillage de service et plan de données

Figure 6-8. Contrôle de maillage de service et plan de données

Une fois configuré, un maillage de service est hautement fonctionnel. Il peut récupérer un pool d’instances correspondant à partir d’un point de terminaison de découverte de service. Le maillage peut ensuite envoyer une requête à une instance spécifique, enregistrant la latence et le type de réponse du résultat. Un maillage peut choisir l’instance la plus susceptible de retourner une réponse rapide en fonction de nombreux facteurs, y compris sa latence observée pour les requêtes récentes.

Si une instance ne répond pas ou échoue, le maillage réessaye la requête sur une autre instance. Si l'instance retourne des erreurs, le réseau l'évacue du pool d'équilibrage de charge et la redémarre une fois qu'elle est réparée. Si une requête expire, un maillage peut échouer, puis réessayer la requête. Un réseau capture et émet des indicateurs et un suivi distribué vers un système d'indicateurs centralisé.

Istio et Envoy

Bien que quelques options de maillage de service existent actuellement, Istio est le plus populaire au moment de cet écriture. Istio est une joint-venture d’IBM, Google et Lyft. Il s’agit d’une offre open source qui peut être intégrée à une application distribuée nouvelle ou existante. La technologie fournit une solution cohérente et complète pour sécuriser, connecter et surveiller les microservices. Ses fonctionnalités sont les suivantes :

  • Sécuriser la communication de service à service dans un cluster avec une authentification et une autorisation fortes basées sur l’identité.
  • Équilibrage de charge automatique pour le trafic HTTP, gRPC, WebSocket et TCP.
  • Contrôle précis du comportement du trafic avec des règles d’acheminement riches, nouvelles tentatives, basculements et injection de pannes.
  • Une couche de stratégie enfichable et une API de configuration prenant en charge les contrôles d’accès, les limites de débit et les quotas.
  • 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.

Un composant clé pour une implémentation Istio est un service proxy intitulé le proxy Envoy. Il s’exécute en même temps que chaque service et fournit une base indépendante de la plateforme pour les fonctionnalités suivantes :

  • Découverte de services dynamiques.
  • Équilibrage de charge :
  • Terminaison TLS.
  • Proxys HTTP et gRPC.
  • Résilience du disjoncteur.
  • Bilans de santé.
  • Mises à jour progressives avec des déploiements canari.

Comme indiqué précédemment, Envoy est déployé en tant que side-car à côté de chaque microservice du cluster.

Intégration à Azure Kubernetes Services

Le cloud Azure embrasse Istio et fournit une prise en charge directe dans Azure Kubernetes Services. Les liens suivants peuvent vous aider à commencer :

références

PrécédentSuivant