Infrastructure de communication Service Mesh

  • 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.

Dans ce chapitre, nous avons passé en revue les défis liés à la communication de microservices. Nous avons vu que les équipes de développement doivent s’intéresser à la manière dont les services back-end communiquent entre eux. Dans l’idéal, il est préférable de limiter autant que possible la communication interservice. Mais il n’est pas toujours possible de l’éviter, car les services back-end sont souvent dépendants d’un autre service pour exécuter des opérations.

Nous avons exploré différentes approches pour implémenter la communication HTTP synchrone et la messagerie asynchrone. Dans chacun des cas, le développeur a pour mission d’implémenter le code de communication. Or, cette tâche se révèle à la fois complexe et chronophage. Toute décision incorrecte peut entraîner de graves problèmes de performances.

Une approche plus moderne de la communication de microservices privilégie l’adoption d’une nouvelle technologie qui ne cesse d’évoluer et que l’on appelle maillage de services. Un maillage de service est une couche d’infrastructure configurable, qui intègre des fonctionnalités conçues pour améliorer la gestion de la communication entre les services, la résilience et de nombreuses autres problématiques transversales. Il libère les microservices de cette responsabilité pour les confier à la couche de maillage de services. La communication est ainsi isolée de vos microservices.

Le proxy est un composant essentiel d’un maillage de services. Dans une application native cloud, une instance d’un proxy est généralement colocalisée avec chaque microservice. Bien qu’ils s’exécutent dans des processus distincts, les deux sont étroitement liés et partagent le même cycle de vie. Ce modèle, appelé modèle Sidecar, est illustré à la Figure 4-24.

Service mesh with a side car

Figure 4-24. Maillage de service avec side-car

Notez dans la figure précédente la manière dont les messages sont interceptés par un proxy qui s’exécute en parallèle de chaque microservice. Chaque proxy peut être configuré avec des règles de trafic spécifiques au microservice. Il comprend les messages et peut les router entre vos services et le monde extérieur.

En plus de la gestion de la communication entre services, le maillage de services prend en charge la découverte des services et l’équilibrage de charge.

Une fois configuré, un maillage de services est hautement fonctionnel. Le maillage récupère un pool d’instances correspondant à partir d’un point de terminaison de découverte de service. Il envoie une requête à une instance spécifique, en enregistrant la latence et le type de réponse du résultat. Il choisit l’instance la plus susceptible de retourner une réponse rapide en fonction de nombreux facteurs, notamment la latence observée pour les requêtes récentes.

Un maillage de services gère les problèmes de trafic, de communication et de mise en réseau au niveau de l’application. Il comprend les messages et les requêtes. Un maillage de services s’intègre généralement à un orchestrateur de conteneurs. Kubernetes prend en charge une architecture extensible dans laquelle il est possible d’ajouter un maillage de services.

Le chapitre 6 examine en détail les technologies de maillage de services et présente son architecture ainsi que les implémentations open source disponibles.

Résumé

Dans ce chapitre, nous avons abordé les modèles de communication natifs cloud. Nous avons commencé par examiner la manière dont les clients front-end communiquent avec les microservices back-end. Nous avons ensuite parlé des plateformes de passerelle d’API et de la communication en temps réel. Nous nous sommes ensuite intéressés à la manière dont les microservices communiquent avec d’autres services back-end. Nous avons étudié à la fois la communication HTTP synchrone et la messagerie asynchrone entre les services. Nous avons abordé le concept de gRPC, une technologie nouvelle génération adaptée au monde natif cloud. Enfin, nous avons introduit la notion de maillage de services, une nouvelle technologie en pleine évolution capable de simplifier la communication des microservices.

Nous avons tout particulièrement évoqué les services Azure managés qui peuvent faciliter l’implémentation de la communication dans les systèmes natifs cloud :

Nous allons maintenant nous intéresser aux données distribuées dans les systèmes natifs cloud et présenter les avantages et inconvénients associés.

References

PrécédentSuivant