Déployer des microservices avec Azure Container Apps et Dapr

Cet article décrit une solution permettant d’exécuter un système de gestion des commandes qui a 10 microservices sur Azure Container Apps. La solution utilise également les meilleures pratiques de microservices par le biais du runtime d’application distribué (Dapr) et de la mise à l’échelle pilotée par les événements avec la mise à l’échelle automatique basée sur les événements Kubernetes (KEDA).

Dapr et Traefik sont des marques commerciales de leurs sociétés respectives. L’utilisation de ces marques n’implique aucune approbation.

Architecture

Téléchargez un fichier PowerPoint de cette architecture.

Flux de données

Cette solution décrit un système de gestion des commandes Red Dog fictif et son infrastructure Azure prenant en charge. L’architecture se compose d’un seul environnement Container Apps qui héberge 10 applications de microservice .NET Core. La solution utilise le Kit de développement logiciel (SDK) Dapr pour s’intégrer aux ressources Azure via des blocs de construction de publication-abonnement, d’état et de liaison. Les services utilisent également des règles de mise à l’échelle KEDA pour permettre la mise à l’échelle en fonction des déclencheurs d’événements et des scénarios de mise à l’échelle à zéro.

Le flux de données suivant correspond au diagramme précédent :

1. Traefik : Proxy de base pour le routage des demandes utilisateur de l’interface utilisateur vers les services comptabilité et Makeline pour le tableau de bord interactif.

2. interface utilisateur : tableau de bord qui affiche les données de commande en temps réel et les données de ventes agrégées pour le système de gestion des commandes Red Dog.

3. Client virtuel : Programme de simulation client qui simule les clients qui placent des commandes via le service de commande.

4. Service commande : Une API de création, de lecture, de mise à jour et de suppression pour passer et gérer des commandes.

5. Service comptable : Service qui traite, stocke et agrège les données de commande. Il transforme les commandes client en métriques de ventes significatives que l’interface utilisateur présente.

6. Service de reçu : Programme d’archivage qui génère et stocke les reçus de commande à des fins d’audit et d’historique.

7. Service de fidélité : Service qui gère le programme de fidélité en suivant les points de récompense client en fonction des dépenses de commande.

8. Service Makeline : Service qui gère une file d’attente des commandes en cours en attente d’exécution. Il effectue le suivi du traitement et de la fin des commandes par le service de travail virtuel.

9. Worker virtuel : Programme de simulation de travail qui simule l’achèvement des commandes client.

Composants

• Application Insights est un service extensible de gestion des performances des applications que vous pouvez utiliser pour surveiller les applications actives et détecter automatiquement les anomalies de performances. Dans cette architecture, vous utilisez Application Insights avec Azure Monitor pour afficher les journaux de conteneur et collecter des métriques à partir des microservices.

• Le Stockage Blob est une solution basée sur le cloud pour stocker des quantités massives de données non structurées telles que du texte ou des fichiers binaires. Dans cette architecture, un service de reçu utilise le Stockage Blob via une liaison de sortie Dapr pour stocker les reçus de commande.

• Azure Cache pour Redis est un cache Redis managé distribué, en mémoire et évolutif. Dans cette architecture, elle est utilisée comme composant de magasin d’état Dapr pour le service Makeline pour stocker des données sur les commandes en cours de traitement.

• Azure Cosmos DB est un service de base de données managée NoSQL multimodélisé. Dans cette architecture, elle est utilisée comme composant de magasin d’état Dapr pour le service de fidélité afin de stocker les données de fidélité des clients.

• Azure Monitor est une plateforme unifiée qui vous permet de collecter, d’analyser et d’agir sur les données de contenu client à partir de vos environnements d’infrastructure Azure. Dans cette architecture, vous utilisez Azure Monitor avec Application Insights pour afficher les journaux de conteneur et collecter des métriques à partir des microservices.

• Service Bus est un répartiteur de messages d’entreprise entièrement géré qui a des files d’attente et des rubriques de publication-abonnement. Dans cette architecture, vous utilisez Service Bus pour l’implémentation du composant Depr publish-subscribe. Plusieurs services utilisent ce composant. Le service de commande publie des messages sur le bus et les services Makeline, comptabilité, fidélité et reçu s’abonnent à ces messages.

• Container Apps est un service conteneur serverless entièrement managé utilisé pour créer et déployer des applications modernes à grande échelle. Dans cette architecture, vous hébergez toutes les 10 microservices sur Container Apps et les déployez dans un seul environnement Container Apps. Cet environnement sert de limite sécurisée autour du système.

• SQL Database est un service de base de données relationnelle intelligent et évolutif conçu pour le cloud. Dans cette architecture, elle sert de magasin de données pour le service de comptabilité, qui utilise Entity Framework Core pour interagir avec la base de données. Le service de programme d’amorçage est chargé de configurer les tables SQL dans la base de données. Ensuite, il s’exécute une fois avant d’établir la connexion au service de comptabilité.

• Traefik est un proxy inverse et un équilibreur de charge utilisé pour router le trafic réseau vers les microservices. Dans cette architecture, utilisez la fonctionnalité de configuration dynamique de Traefik pour effectuer un routage basé sur le chemin à partir de l’interface utilisateur, qui est une application Vue.js monopage. Cette configuration permet également d’effectuer des appels d’API directs aux services back-end à des fins de test.

Autres solutions

Dans cette architecture, vous déployez un proxy Traefik pour activer le routage basé sur le chemin pour l’API Vue.js. Il existe de nombreux proxys open source alternatifs que vous pouvez utiliser à cet effet. Deux autres projets courants sont NGINX et HAProxy.

Toutes les infrastructures Azure, à l’exception de SQL Database, utilisent des composants Dapr pour l’interopérabilité. L’un des avantages de Dapr est que vous pouvez échanger tous ces composants en modifiant la configuration du déploiement des applications de conteneur. Dans ce scénario, Service Bus, Azure Cosmos DB, Azure Cache pour Redis et Stockage Blob présentent certains des plus de 70 composants Dapr disponibles. Une liste d’autres répartiteurs d’abonnement à publication, magasins d’état et liaisons de sortie sont disponibles dans la documentation Dapr.

Détails du scénario

Les microservices sont un style architectural largement adopté. Ils offrent des avantages tels que l’extensibilité, l’agilité et les déploiements indépendants. Vous pouvez utiliser des conteneurs comme mécanisme pour déployer des applications de microservices, puis utiliser un orchestrateur de conteneurs comme Kubernetes pour simplifier les opérations. Il existe de nombreux facteurs à prendre en compte pour les architectures de microservices à grande échelle. En règle générale, la plateforme d’infrastructure nécessite une compréhension significative des technologies complexes telles que les orchestrateurs de conteneurs.

Container Apps est un service de conteneur serverless entièrement managé pour exécuter des applications modernes à grande échelle. Il vous permet de déployer des applications conteneurisées via une abstraction de la plateforme sous-jacente. À l’aide de cette méthode, vous n’avez pas besoin de gérer une infrastructure complexe.

Cette architecture utilise l’intégration de Container Apps à une version managée du Dapr. Dapr est un projet open source qui aide les développeurs à surmonter les défis inhérents aux applications distribuées, comme la gestion de l’état et l’appel de service.

Container Apps fournit également une version managée de KEDA. KEDA permet à vos conteneurs de mettre à l’échelle automatiquement en fonction des événements entrants provenant de services externes tels que Service Bus et Azure Cache pour Redis.

Vous pouvez également activer l’entrée HTTPS dans Container Apps sans créer de ressources réseau Azure supplémentaires. Vous pouvez utiliser le proxy Envoy, ce qui autorise également les scénarios de fractionnement du trafic.

Pour plus d’informations, consultez Comparer Container Apps à d’autres options de conteneur Azure.

Cet article décrit une solution permettant d’exécuter un système de gestion des commandes qui a 10 microservices sur Container Apps. La solution utilise également les bonnes pratiques en matière de microservices par le biais de Dapr et d’une mise à l’échelle pilotée par les événements avec KEDA.

Cas d’usage potentiels

Cette solution s’applique à toute organisation qui utilise des microservices sans état et avec état pour les systèmes distribués. La solution est la meilleure pour les produits empaquetés de consommateurs et les industries de fabrication qui ont un système de commande et de traitement.

Les solutions suivantes ont des conceptions similaires :

• Architecture des microservices sur AKS (Azure Kubernetes Service)
• Architecture des microservices sur Azure Functions
• Architectures basées sur les événements

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Container Apps repose sur une base Kubernetes, qui fonctionne en tant qu’infrastructure sous-jacente. Les mécanismes de résilience sont intégrés à Kubernetes qui surveillent et redémarrent des conteneurs, ou des pods, s’il existe des problèmes. Les mécanismes de résilience incluent un équilibreur de charge intégré qui distribue le trafic entre plusieurs réplicas de chaque application conteneur. Cette redondance permet au système de rester opérationnel, même si un réplica devient indisponible.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

La liste suivante présente plusieurs fonctionnalités de sécurité omises dans cette architecture, ainsi que d’autres recommandations et considérations :

• Cette architecture n’utilise pas de points de terminaison privés, ce qui permet une connectivité privée plus sécurisée aux services Azure en leur attribuant une adresse IP à partir de votre réseau virtuel. Lorsque des points de terminaison privés sont utilisés, l’accès au réseau public peut être désactivé. Cette approche maintient le trafic sur le réseau principal de Microsoft et améliore la sécurité et la conformité.

• L’activité réseau doit être surveillée en permanence pour détecter et prévenir les abus. Vous pouvez effectuer cette approche à l’aide d’un Pare-feu Azure et de tables de routage. Les tables de routage permettent au trafic qui laisse un réseau virtuel passer d’abord par le pare-feu. Ce processus est une étape importante pour vous assurer que votre architecture n’est pas vulnérable aux attaques d’exfiltration de données.

• Utilisez un pare-feu d’applications web (WAF) pour vous protéger contre les vulnérabilités courantes. Utilisez Azure Front Door ou Azure Application Gateway pour implémenter un WAF dans cette architecture.

• Envisagez d’utiliser la fonctionnalité d’authentification et d’autorisation intégrée pour Container Apps, connue sous le nom d’authentification simple. Easy Auth gère l’intégration avec les fournisseurs d’identité en dehors de votre application web, ce qui peut réduire la quantité de code dont vous avez besoin pour gérer.

• Utilisez une identité managée pour les identités de charge de travail. Identité managée permet aux développeurs de ne plus avoir à gérer les informations d’authentification. Par exemple, l’architecture de base s’authentifie auprès de SQL Server via un mot de passe dans une chaîne de connexion. Si possible, utilisez les ID Microsoft Entra pour s’authentifier auprès d’Azure SQL Server.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Utilisez la calculatrice de prix Azure pour estimer le coût des services dans cette architecture.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Vous pouvez utiliser Azure Monitor et Application Insights pour surveiller Container Apps. Vous pouvez afficher les journaux de conteneur en accédant dans le portail au volet Journaux de chaque application conteneur, puis en exécutant la requête Kusto suivante. Cet exemple montre les journaux de l’application de service Makeline.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Le mappage d’application dans Application Insights montre également comment les services communiquent en temps réel. Vous pouvez ensuite les utiliser pour les scénarios de débogage. Accédez à la carte d’application sous la ressource Application Insights pour afficher quelque chose comme la carte suivante.

Pour plus d’informations, consultez Surveiller une application dans Container Apps.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

Cette solution s’appuie fortement sur l’implémentation KEDA dans Container Apps pour la mise à l’échelle basée sur les événements. Lorsque vous déployez le service client virtuel, il place en permanence des commandes. Cette mise à l’échelle entraîne le scale-up du service d’ordre via le scaler KEDA HTTP. À mesure que le service de commande publie les commandes sur service bus, les scalers KEDA entraînent le scale-up deservices de comptabilité, de reçu, de Makeline et de fidélité. L’interface utilisateur et les applications de conteneur Traefik configurent également des scalers HTTP KEDA afin que les applications soient mises à l’échelle à mesure que plus d’utilisateurs accèdent au tableau de bord.

Lorsque le client virtuel n’est pas en cours d’exécution, tous les microservices de cette solution sont mis à l’échelle à zéro, à l’exception des services de travail virtuel et Makeline. Le worker virtuel n’effectue pas un scale-down, car il vérifie en permanence le traitement des commandes. Pour plus d’informations, consultez Définir des règles de mise à l’échelle dans Container Apps.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Alice Gibbons | Global Black Belt natif cloud

Autres contributeurs :

• Lynn Orrell | PSS (Principal Solution Specialist) (GBB)
• Kendall Roden | Responsable de programme senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Documentation Container Apps
• Comparer Container Apps à d’autres options de conteneur Azure

Ressources associées

• Architecture de microservices sur AKS
• Architecture de microservices avancée sur AKS
• Intégration continue et livraison continue pour les applications AKS avec Azure Pipelines