Lorsque vous concevez une application Web basée sur une architecture de microservices, vous décidez comment diviser ses fonctionnalités en microservices et appeler ces microservices depuis votre application. Pour les services de longue durée, vous pouvez utiliser des appels de service asynchrones. Cette architecture de référence explique comment déployer une application conteneurisée qui appelle des processus de longue durée de manière asynchrone.
Ce document d'architecture de référence est destiné aux développeurs et aux architectes qui souhaitent implémenter des microservices de manière asynchrone à l'aide de technologies modernes, telles que Google Kubernetes Engine (GKE) et Pub/Sub. Dans ce document, nous partons du principe que vous maîtrisez les concepts de base des microservices, ainsi que Pub/Sub et GKE sur Google Cloud.
Architecture
Le schéma suivant illustre un exemple de scénario dans lequel une application génère des vignettes. La génération de vignettes peut être une tâche gourmande en ressources et peut donc prendre un certain temps.
Figure 1 : Architecture d'origine pour le traitement d'images basé sur des VM
Dans le schéma précédent, l'application reçoit les fichiers image des clients, puis génère des vignettes. Dans cette architecture, l'application est implémentée à l'aide d'instances de machine virtuelle (VM) sur Compute Engine et du stockage de fichiers backend sur Cloud Storage. L'application stocke les métadonnées à l'aide de Cloud Storage. Cloud Load Balancing distribue les requêtes à plusieurs VM.
Pour réduire les coûts opérationnels liés à la maintenance des VM, vous migrez ce système vers une nouvelle architecture qui n'utilise pas de VM.
Le schéma suivant montre comment implémenter ce flux à l'aide des services gérés qui utilisent des notifications et des microservices pour mettre en œuvre des appels asynchrones entre les composants du système.
Figure 2. Nouvelle architecture pour le traitement d'images basée sur l'utilisation de conteneurs et de la messagerie asynchrone
Dans la nouvelle architecture, le client envoie une image à l'application, qui l'importe dans Cloud Storage. Les notifications Pub/Sub placent ensuite un message dans la file d'attente des messages Pub/Sub. Le message appelle un microservice exécuté sur GKE. Le microservice récupère l'image à partir de Cloud Storage, génère une vignette et l'importe dans Cloud Storage.
Considérations de conception
Les consignes suivantes peuvent vous aider à développer une architecture répondant aux exigences de votre organisation en termes de fiabilité, de coût et de performances.
Efficacité opérationnelle
Cette nouvelle architecture présente les avantages suivants :
Évolutivité indépendante : dans l'architecture d'origine, l'application exécutée sur Compute Engine traite deux tâches principales. La première tâche consiste à recevoir des fichiers, et l'autre à générer une vignette à partir de l'image d'origine. La réception de fichiers importés consomme de la bande passante réseau, tandis que la génération de vignettes nécessite une utilisation intensive du processeur. Les instances Compute Engine peuvent manquer de ressources processeur pour générer des images, mais disposer de ressources réseau suffisantes pour recevoir des fichiers. Dans la nouvelle architecture, ces tâches sont partagées entre Cloud Storage et GKE, ce qui permet de les adapter de manière indépendante.
Ajout facile de nouvelles fonctionnalités : dans l'architecture d'origine, si vous souhaitez ajouter des fonctionnalités, vous devez les déployer sur les mêmes instances Compute Engine. Dans la nouvelle architecture, vous pouvez développer une application et l'ajouter indépendamment. Par exemple, vous pouvez ajouter une application d'expéditeur d'e-mails pour vous avertir lorsqu'une nouvelle vignette est générée. Pub/Sub peut se connecter aux applications de génération de vignettes et d'expéditeurs d'e-mails de manière asynchrone sans modifier le code d'origine qui s'exécute sur GKE.
Couplage réduit : dans l'ancienne architecture, le couplage temporel pose souvent problème. Si un serveur de relais de messagerie n'est pas disponible, l'application tente d'envoyer une notification, mais elle échoue. Ces processus sont étroitement liés et un client risque de ne pas obtenir de réponse positive de la part de l'application. Dans la nouvelle architecture, le client obtient une réponse positive, car les processus de génération d'une vignette et d'envoi d'une notification sont faiblement couplés.
Cette nouvelle architecture présente les inconvénients suivants :
La modernisation de l'application nécessite un effort supplémentaire : la conteneurisation d'une application exige du temps et des efforts. La nouvelle architecture utilise davantage de services et nécessite une approche différente de l'observabilité, en particulier des modifications de la surveillance de l'application, du processus de déploiement et de la gestion des ressources.
Exigence pour la gestion de la duplication côté application : Pub/Sub garantit au moins une distribution de chaque message. Des doubles occasionnels sont donc inévitables. Votre application doit gérer cette possibilité.
Performances
La nouvelle architecture peut vous permettre d'utiliser efficacement les ressources : dans l'architecture d'origine, le scaling horizontal des instances Compute Engine consomme davantage de ressources afin d'exécuter les systèmes d'exploitation. Avec GKE, l'exécution de plusieurs conteneurs sur quelques serveurs ("bin packing") vous permet d'optimiser l'utilisation des ressources serveur. Vous pouvez effectuer un scaling horizontal à la hausse des conteneurs très rapidement pour permettre à la nouvelle architecture de gérer de brèves utilisations intensives, puis un scaling à la baisse une fois les tâches terminées.
Déploiement
Pour déployer un exemple d'application mettant en œuvre cette architecture, consultez la page Déployer des microservices utilisant Pub/Sub et GKE.
Étapes suivantes
- Apprenez-en plus sur le DevOps et découvrez la fonctionnalité d'architecture associée à cette architecture de référence.
- Effectuez l'évaluation DevOps rapide pour comprendre votre position par rapport au reste du secteur.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.