Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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.
Tout au long de ce chapitre, nous avons exploré les défis de la communication de microservice. Nous avons dit que les équipes de développement doivent être sensibles à la façon dont les services principaux communiquent entre eux. Dans l’idéal, moins la communication interservices est meilleure. Toutefois, l’évitement n’est pas toujours possible, car les services principaux s’appuient souvent les uns sur les autres pour effectuer 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 est chargé d’implémenter du code de communication. Le code de communication est complexe et fastidieux. Des décisions incorrectes peuvent entraîner des problèmes de performances importants.
Une approche plus moderne de la communication des microservices repose sur une technologie nouvelle et en pleine é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 à service, la résilience et de nombreuses préoccupations croisées. Il déplace la responsabilité de ces préoccupations hors des microservices et dans la couche de maillage de service. La communication est abstraite de vos microservices.
Un composant clé d’un maillage de service est un proxy. 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é dans la figure 4-24.
Figure 4-24. Maillage de service avec une voiture latérale
Notez dans la figure précédente comment les messages sont interceptés par un proxy qui s’exécute en même temps que chaque microservice. Chaque proxy peut être configuré avec des règles de trafic spécifiques au microservice. Il comprend les messages et peut les acheminer entre vos services et le monde extérieur.
En plus de la gestion de la communication de service à service, Service Mesh prend en charge la découverte de service et l’équilibrage de charge.
Une fois configuré, un maillage de service est hautement fonctionnel. Le réseau maillé récupère un ensemble d’instances correspondant à partir d’un endpoint de découverte de service. Il envoie une requête à une instance de service spécifique, 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 différents facteurs, y compris la latence observée pour les demandes récentes.
Un maillage de service 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 demandes. Un maillage de service s’intègre généralement à un orchestrateur de conteneur. Kubernetes prend en charge une architecture extensible dans laquelle un maillage de service peut être ajouté.
Dans le chapitre 6, nous examinons en détail les technologies Service Mesh, notamment une discussion sur son architecture et 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 façon dont les clients frontaux communiquent avec les microservices principaux. En chemin, nous avons parlé des plateformes de passerelle d’API et de la communication en temps réel. Nous avons ensuite examiné comment les microservices communiquent avec d’autres services principaux. Nous avons examiné à la fois la communication HTTP synchrone et la messagerie asynchrone entre les services. Nous avons abordé gRPC, une technologie à venir dans le monde natif du cloud. Enfin, nous avons introduit une nouvelle technologie en évolution rapide intitulée Service Mesh qui peut simplifier la communication de microservice.
L’accent a été mis sur les services Azure gérés qui peuvent aider à implémenter la communication dans les systèmes natifs cloud :
- Application Gateway Azure
- Gestion des API Azure
- Azure SignalR Service
- Files d’attente Stockage Azure
- Azure Service Bus
- Azure Event Grid
- Azure Event Hub
Nous allons ensuite passer aux données distribuées dans des systèmes natifs cloud et aux avantages et aux défis qu’il présente.
références
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
