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 est une marque de commerce de sa société respective. L’utilisation de cette marque n’implique aucune approbation de sa part.

Architecture

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

Flux de données

Cette solution décrit un système fictif de gestion des commandes Red Dog et l'infrastructure Azure qui le soutient. L’architecture se compose d’un seul environnement Container Apps qui héberge 10 applications de microservice .NET. Azure Container Apps utilise une couche d’entrée basée sur Envoy managée pour router le trafic externe des utilisateurs vers l’interface utilisateur exposée publiquement. Les appels de service à service internes ne passent pas par cette entrée. À la place, ils utilisent l’invocation de service Dapr et la découverte de services de Container Apps dans l’environnement. 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. Entrée managée : Azure Container Apps fournit une couche d’entrée basée sur Envoy managée pour acheminer les requêtes utilisateur vers l’interface utilisateur et les points de terminaison d’API qui prennent en charge 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çus utilise Stockage Blob via une liaison de sortie Dapr pour stocker les reçus de commande.

• Azure Managed Redis fournit un magasin de données en mémoire basé sur le logiciel Redis Enterprise. Dans cette architecture, le composant de stockage d'état Dapr est utilisé pour le service Makeline afin de stocker les données des commandes en cours de traitement.

• Azure Cosmos DB est un service de base de données managée NoSQL multimodélisé. Dans cette architecture, il est utilisé comme composant de magasin d’état Dapr pour que le service de fidélité stocke 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 tous les 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 et fournit des entrées gérées basées sur Envoy pour le routage externe vers l’interface utilisateur.

• 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 seule fois avant que la connexion au service de comptabilité ne soit établie.

Autres solutions

Dans cette architecture, le chemin d’accès de routage par défaut utilise la couche d’entrée intégrée Container Apps, qui est implémentée via un proxy Envoy managé. Si une charge de travail nécessite un intergiciel personnalisé ou un comportement de protocole au-delà des fonctionnalités d’entrée natives, les proxys dédiés tels que NGINX ou HAProxy sont des alternatives.

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 Managed Redis et Stockage Blob présentent quelques-uns des plus de 70 composants Dapr disponibles. Une liste d’autres courtiers de publication-abonnement, magasins d’état et liaisons de sortie est disponible 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 s'adapter automatiquement en fonction des événements provenant de services externes tels que Service Bus et Azure Managed Redis.

Container Apps fournit également une entrée basée sur Envoy managée, ce qui vous permet d’exposer des points de terminaison HTTP, d’utiliser des domaines personnalisés et un protocole TLS managé, et de prendre en charge les scénarios de fractionnement du trafic sans déployer un niveau proxy distinct.

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 idéale pour les produits de grande consommation et le secteur de la fabrication disposant d'un système de gestion des commandes et de l'exécution.

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 la 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 une réplique devient indisponible.

Container Apps fournit également des stratégies de détection et de résilience de service que vous pouvez utiliser pour appliquer des délais d’attente et un comportement de disjoncteur entre les services. Pour les services avec Dapr activé, configurez les paramètres d’intégrité de l’application afin que les réplicas défaillants soient détectés plus tôt et que le trafic soit détourné des instances dégradées avant que les défaillances ne se propagent en cascade aux composants en aval.

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

  En guise d’alternative aux points de terminaison privés, envisagez d’utiliser Azure périmètre de sécurité réseau pour restreindre l’accès réseau à Microsoft.ServiceBus/namespaces et Microsoft.Storage/storageAccounts. Un périmètre de sécurité réseau vous permet d’associer ces ressources à un périmètre partagé et de définir des règles d’accès entrantes. Dans cette architecture, Container Apps n’est pas déployé avec un réseau virtuel personnalisé ou une adresse IP sortante statique. L’étendue de la règle de trafic entrant est donc étendue à l’abonnement qui héberge l’environnement Container Apps plutôt qu’à une plage d’adresses IP, ce qui nécessite une adresse IP source stable et connue pour être efficace.

• 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 quitte un réseau virtuel de 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.

Dapr ajoute une couche de portabilité entre vos services et leur infrastructure de stockage. Cette couche fournit une valeur lorsque vous attendez que les services de stockage changent ou que vous souhaitez échanger un composant, tel qu’un magasin d’états ou un répartiteur de messages, par le biais de la configuration plutôt que du code. Dapr ajoute également une dépendance et un niveau d’indirection. Lorsque vous disposez d’un ensemble assez stable de points de terminaison natifs d’Azure que vous ne prévoyez pas de remplacer, appeler directement les SDK Azure natifs constitue une alternative raisonnable qui élimine l’abstraction Dapr. Pesez la flexibilité des composants Dapr par rapport à la simplicité opérationnelle des appels directs du SDK.

Vous pouvez utiliser Azure Monitor et Application Insights pour surveiller Container Apps. Pour les applications distribuées, utilisez un pipeline basé sur OpenTelemetry pour envoyer des traces, des journaux et des métriques à Azure Monitor et Application Insights. Vous pouvez également 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 opération de mise à l’échelle entraîne l’augmentation de la capacité du service de commande au moyen d’une règle de mise à l’échelle HTTP. À mesure que le service de commande publie les commandes sur Service Bus, les règles de mise à l’échelle de Service Bus provoquent la mise à l’échelle des services de comptabilité, de reçus, de Makeline et de fidélité. L’interface utilisateur et le service Makeline peuvent également utiliser des règles de mise à l’échelle HTTP afin que les applications soient mises à l’échelle en tant 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 ne réduit pas ses capacités, parce qu'il vérifie en permanence l'exécution des commandes. Pour plus d’informations, consultez Définir des règles de mise à l’échelle dans Container Apps.

Profils de charge de travail

Utilisez des profils de charge de travail pour séparer les services nécessitant une capacité chaude des services qui bénéficient le plus de l’élasticité serverless. Dans ce diagramme, le service Order et le service Comptabilité sont affichés sur un profil dédié, car ils gèrent le travail transactionnel et prennent en charge les métriques professionnelles dynamiques. Le service de reçus et le service de fidélité sont affichés sur un profil de consommation, car ce sont des services pilotés par les événements qui peuvent mieux tirer parti de l’élasticité serverless.

Les règles de mise à l’échelle basées sur KEDA fonctionnent avec les profils de charge de travail Consommation et Dédié. La consommation est optimale pour les services pouvant être mis à l’échelle à zéro, tandis que Dedicated est préférable pour les services qui bénéficient toujours de la mise à l’échelle automatique, mais qui ont besoin d’une capacité chaude ou de performances plus élevées.

Contributeurs

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

Auteur principal :

• Alice Gibbons | Cloud natif Global Black Belt

Autres contributeurs :

• Lynn Orrell | Spécialiste Principal des Solutions (PSS) (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