Partager via

Communications résiliente

  • Article

Conseil

Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

Cloud Native .NET apps for Azure eBook cover thumbnail.

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 seule requête sur plusieurs microservices consommateurs ?

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 é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 illustre ce scénario.

Service mesh with a side car

Figure 6-7. Maillage de service avec un side-car

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 présente ces composants et leurs responsabilités.

Service mesh control and data plane

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 elle retourne des erreurs, un maillage supprime l’instance du pool d’équilibrage de charge et la restitue une fois qu’elle est guérie. Si une requête expire, un maillage peut échouer, puis va réessayer la requête. Un maillage capture et émet des métriques et un suivi distribué vers un système de métriques centralisé.

Istio et Envoy

Bien que quelques options de maillage de service existent actuellement, Istio est le plus populaire au moment de cette écriture. Istio est une coentreprise 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 de routage 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 :
  • Arrêt TLS.
  • Proxys HTTP et gRPC.
  • Résilience du disjoncteur.
  • Contrôles d’intégrité.
  • Mises à jour propagées avec des déploiements canary .

Comme indiqué précédemment, Envoy est déployé en tant que side-car sur 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 :

References

PrécédentSuivant