Cet article décrit une solution permettant d’exécuter un système de gestion des commandes avec 10 microservices sur Azure 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.
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.
Dataflow
Cette solution utilise des modèles Bicep pour exécuter le déploiement du système de gestion des commandes Reddog et son infrastructure Azure prise en charge. L’architecture est composée d’un seul environnement Azure Container Apps qui héberge 10 applications de microservice .NET Core. Vous allez utiliser le Kit de développement logiciel (SDK) .NET Core Dapr pour s’intégrer aux ressources Azure via les blocs de construction publication-abonnement (pub/sub)d’état et de liaison. Bien que Dapr offre généralement une flexibilité lorsque vous implémentez des composants, cette solution est basée sur un avis. Les services utilisent également des règles de KEDA pour permettre la mise à l’échelle en fonction des déclencheurs d’événements et de la mise à l’échelle vers zéro scénarios.
La liste suivante décrit chaque microservice et la configuration d’Azure Container Apps avec laquelle il est déployé. Consultez le référentiel reddog-code sur GitHub pour afficher le code.
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.
Interface utilisateur : Tableau de bord montrant 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 Reddog.
Client virtuel : Programme de simulation client qui simule les clients qui placent des commandes via le service de commande.
Service de commande : API CRUD pour placer et gérer des commandes.
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 présentées par l’interface utilisateur.
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.
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.
Service Makeline : Service responsable de la gestion d’une file d’attente de commandes actuelles en attente de traitement. Il effectue le suivi du traitement et de la fin des commandes par le service de travail virtuel.
Worker virtuel : Programme de simulation de travail qui simule l’achèvement des commandes client.
Bootstrapper (non affiché) : Service qui utilise Entity Framework Core pour initialiser les tables dans Azure SQL Database à utiliser avec le service de comptabilité.
| Service | Entrée | Composants Dapr | Règles d’échelle KEDA |
|---|---|---|---|
| Traefik | Externe | Dapr désactivé | HTTP |
| Interface utilisateur du service | Interne | Dapr désactivé | HTTP |
| Client virtuel | None | Appel de service à service | N/A |
| Service de commande | Interne | Pub/sub : Azure Service Bus | HTTP |
| Service de comptabilité | Interne | Pub/sub : Azure Service Bus | Longueur de la rubrique Azure Service Bus, HTTP |
| Service de reçu | Interne | Pub/sub : Azure Service Bus Liaison : Objet blob Azure |
Longueur de la rubrique Azure Service Bus |
| Service de fidélité | Interne | Pub/sub : Azure Service Bus État : Azure Cosmos DB |
Longueur de la rubrique Azure Service Bus |
| Service Makeline | Interne | Pub/sub : Azure Service Bus État : Azure Redis |
Longueur de la rubrique Azure Service Bus, HTTP |
| Worker virtuel | Aucun(e) | Appel de service à service Liaison : Cron |
N/A |
Notes
Vous pouvez également exécuter Bootstrapper dans une application conteneur. Toutefois, ce service est exécuté une fois pour effectuer la création de la base de données, puis mis à l’échelle à zéro après avoir créé les objets nécessaires dans Azure SQL Database.
Components
Cette solution utilise les composants suivants :
- Les groupes de ressources Azure sont des conteneurs logiques pour les ressources Azure. Vous utilisez un groupe de ressources unique pour structurer tout ce qui concerne cette solution dans le portail Azure.
- Azure Container Apps est un service conteneur serverless, complètement managé, qui permet de créer et déployer des applications modernes à grande échelle. Dans cette solution, vous hébergez tous les 10 microservices sur Azure Container Apps et vous les déployez dans un seul environnement Container App. Cet environnement agit comme une limite sécurisée autour du système.
- Azure Service Bus est un répartiteur de messages d’entreprise complètement managé, avec des files d’attente et des rubriques de publication/abonnement. Dans cette solution, utilisez-la pour l’implémentation du composant pub/sub Dapr. 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.
- Azure Cosmos DB est un service de base de données managée NoSQL multimodèle. Utilisez-le comme composant de magasin d’état Dapr pour le service de fidélité afin de stocker les données de fidélité du client.
- Azure Cache pour Redis est un cache Redis managé distribué, en mémoire et évolutif. Il est utilisé comme composant de magasin d’état Dapr pour le service Makeline afin de stocker les données sur les commandes en cours de traitement.
- Azure SQL Database est un service de bases de données relationnelles, scalable et intelligent, conçu pour le cloud. Créez-le pour le service de comptabilité, qui utilise Entity Framework Core pour interagir avec la base de données. Le service Bootstrapper est chargé de configurer les tables SQL dans la base de données, puis s’exécute une fois avant d’établir la connexion au service de comptabilité.
- Le stockage Blob Azure stocke des quantités massives de données non structurées telles que des fichiers texte ou binaires. Le service de reçu utilise le stockage Blob via une liaison de sortie Dapr pour stocker les reçus de commande.
- Traefik est un proxy inverse moderne et un équilibreur de charge qui facilite le déploiement de microservices. Dans cette solution, 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 monopage (SPA) Vue.js. Cette configuration permet également d’effectuer des appels d’API directs aux services principaux à des fins de test.
- Azure Monitor vous permet de collecter, d’analyser et d’agir sur les données de contenu client à partir de vos environnements d’infrastructure Azure. Vous l’utiliserez avec Application Insights pour afficher les journaux de conteneur et collecter des métriques à partir des microservices.
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 populaires sont NGINX et HAProxy.
Toutes les infrastructures Azure, à l’exception de Azure 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 cas, Azure Service Bus, Azure Cosmos DB, Cache pour Redis et le stockage d’objets blob ont été choisis pour présenter certains des 70+ composants Dapr disponibles. Une liste d’autres répartiteurs pub/sub, magasins d’état et liaisons de sortie se trouvent dans la documentation Dapr.
Détails du scénario
Les microservices sont un style d’architecture de plus en plus populaire qui peut avoir de nombreux avantages, notamment une scalabilité élevée, des cycles de développement plus courts et une plus grande simplicité. 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.
Azure Container Apps est un service conteneur serverless, complètement managé, qui permet d’exécuter des applications modernes à grande échelle. Il vous permet de déployer des applications conteneurisées via l’abstraction de la plateforme sous-jacente. De cette façon, vous n’aurez pas besoin de gérer une infrastructure complexe. Azure Container Apps est basé sur des technologies open source.
Cette architecture utilise l’intégration d’Azure Container Apps à une version managée de Dapr (Distributed Apps Runtime). Dapr est un projet open source qui aide les développeurs à relever les défis inhérents aux applications distribuées, comme la gestion des états et l’appel de service.
Azure Container Apps fournit également une version managée de KEDA (Kubernetes Event-driven Autoscaling). KEDA permet à vos conteneurs de mettre à l’échelle automatiquement en fonction des événements entrants provenant de services externes tels qu’Azure Service Bus et Azure Cache pour Redis.
Vous pouvez également activer l’entrée HTTPS dans Azure Container Apps sans créer plus de ressources réseau Azure. Vous pouvez utiliser le proxy Envoy, ce qui autorise également les scénarios de fractionnement du trafic.
Pour découvrir comment Azure Container Apps se compare à d’autres plateformes d’hébergement de conteneurs dans Azure, consultez Comparaison des applications conteneur avec d’autres options de conteneur Azure.
Cet article décrit une solution permettant d’exécuter un système de gestion des commandes avec 10 microservices sur Azure 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.
Ces autres solutions 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 Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Azure Container Apps s’exécute sur Kubernetes en arrière-plan. Les mécanismes de résilience sont intégrés à Kubernetes qui surveillent et redémarrent des conteneurs, ou des pods, en cas de problèmes. Les mécanismes de résilience se combinent avec l’équilibreur de charge intégré pour exécuter plusieurs réplicas de chaque application conteneur. Avec cette redondance, la solution peut tolérer l’indisponibilité d’une instance.
Vous pouvez utiliser Azure Monitor et Application Insights pour superviser Azure Container Apps. Vous pouvez afficher les journaux de conteneur en accédant au portail jusqu’au volet Journaux de chaque application conteneur, puis exécuter 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 au mappage d’application sous la ressource Application Insights pour afficher quelque chose comme suit.
Pour plus d’informations sur la supervision d’Azure Container Apps, consultez Superviser une application dans Azure Container Apps.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Utilisez la calculatrice de prix Azure pour estimer le coût des services dans cette architecture.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
Cette solution s’appuie en grande partie sur l’implémentation de KEDA dans Azure Container Apps pour la mise à l’échelle pilotée par les événements. Lorsque vous déployez le service de client virtuel, il passe en permanence des commandes, ce qui entraîne le scale-up du service de commande via le processus de mise à l’échelle HTTP KEDA. À 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 constamment le traitement des commandes. Pour plus d’informations sur la mise à l’échelle dans les applications de conteneur, consultez Définir des règles de mise à l’échelle dans Azure Container Apps. Pour plus d’informations sur les scalers KEDA, consultez la documentation KEDA sur les scalers.
Déployer ce scénario
Pour obtenir des instructions de déploiement, consultez Démonstration Red Dog : Déploiement d’Azure Container Apps sur GitHub.
La Démonstration Red Dog :intégration de microservices est un pack de modèles d’applications qui s’appuie sur les ressources de code précédentes pour illustrer l’intégration d’Azure Container Apps, App Service, Functions et API Management et approvisionne l’infrastructure et déploie le code à l’aide de GitHub Actions.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Alice Gibbons | Global Black Belt natif cloud
Autres contributeurs :
- Kendall Roden | Responsable de programme senior
- Lynn Orrell | PSS (Principal Solution Specialist) (GBB)
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Docs Azure Container Apps
- Comparaison des offres de conteneurs dans Azure
- Autres mises en œuvre du système de gestion des commandes de Reddog :