Modifier

Traitement évolutif des commandes

Azure Cosmos DB
Azure HDInsight

Cet exemple de scénario s’applique aux entreprises ayant besoin d’une architecture hautement évolutive et résiliente pour le traitement de commandes en ligne. Les applications potentielles incluent le e-commerce et les points de vente au détail, le traitement des commandes ainsi que la réservation et le suivi d’un stock.

Architecture

Schéma d’un exemple d’architecture pour un pipeline évolutif de traitement des commandes.

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

Dataflow

Cette architecture décrit en détail les composants clés d’un pipeline de traitement des commandes. Les données circulent dans le scénario comme suit :

  1. Les messages d’événements entrent dans le système via des applications orientées client (de façon synchrone sur HTTP) et divers systèmes back-end (de façon asynchrone via Apache Kafka). Ces messages sont passés dans un pipeline de traitement des commandes.
  2. Chaque message d’événement est ingéré et mappé à un ensemble défini de commandes par un microservice de traitement des commandes. Le traitement des commandes récupère n’importe quel état actuel pertinent pour l’exécution de la commande à partir d’une base de données de capture instantanée de flux d’événements. La commande est ensuite exécutée, et la sortie de la commande est émise comme un nouvel événement.
  3. Chaque événement émis en tant que sortie d’une commande est affecté à une base de données des flux d’événement à l’aide d’Azure Cosmos DB.
  4. Pour chaque insertion de base de données ou mise à jour affectée dans la base de données de flux d’événements, un événement est déclenché par le flux de modification d’Azure Cosmos DB. Les systèmes en aval peuvent s’abonner aux rubriques d’événement qui s’appliquent à ce système.
  5. Tous les événements à partir du flux de modification d’Azure Cosmos DB sont également envoyés à un microservice de flux d’événements de capture instantanée, qui calcule les modifications d’état provoquées par des événements qui se sont produits. Le nouvel état est ensuite validé dans la base de données de capture instantanée de flux événement stockée dans Azure Cosmos DB. La base de données de capture instantanée fournit une source de données mondialement distribuée et à faible latence pour l’état actuel de tous les éléments de données. La base de données de flux d’événements fournit un enregistrement complet de tous les messages d’événement passés à travers l’architecture, ce qui permet des scénarios robustes de récupération d’urgence, de dépannage et de test.

Components

  • Azure Cosmos DB est une base de données Microsoft multimodèle et distribuée mondialement qui vous permet de faire évoluer à votre guise et de manière indépendante le débit et le stockage de vos solutions dans le nombre de régions géographiques de votre choix. Il offre des garanties en termes de débit, de latence, de disponibilité et de cohérence avec des contrats SLA complets. Ce scénario utilise Azure Cosmos DB pour le stockage de flux d’événements et le stockage de capture instantanée et applique des fonctionnalités du flux de modification d’Azure Cosmos DB pour fournir une cohérence des données et une récupération après incident.
  • Apache Kafka sur Azure HDInsight est une implémentation de service géré d’Apache Kafka, une plateforme de streaming distribuée en open source pour la création d’applications et de pipelines de données de streaming en temps réel. Kafka fournit également des fonctionnalités de courtier de messages semblables à une file d’attente, pour la publication et l’abonnement aux flux de données nommés. Ce scénario utilise Kafka pour traiter les événements entrants et en aval dans le pipeline de traitement des commandes.

Détails du scénario

Ce scénario prend une approche d’approvisionnement en événements, à l’aide d’un modèle de programmation fonctionnel implémenté par le biais de microservices. Chaque microservice est traité comme un processeur de flux de données, et toute la logique métier est implémentée au moyen de microservices. Cette approche permet une disponibilité et une résilience élevées, une géo-réplication et des performances rapides.

L’utilisation de services gérés par Azure tels qu’Azure Cosmos DB et HDInsight peut aider à réduire les coûts en utilisant l’expertise de Microsoft dans le stockage et la récupération de données mondialement distribuées à l’échelle du cloud. Ce scénario concerne plus spécialement un scénario de e-commerce ou de vente au détail. Si vous avez d’autres besoins en matière de services de données, vous devez examiner la liste des services de base de données intelligente entièrement gérée dans Azure qui sont disponibles.

Cas d’usage potentiels

Les autres cas d’usage appropriés sont les suivants :

  • Systèmes principaux de e-commerce ou de point de vente au détail.
  • Systèmes de gestion des stocks, pour les secteurs de vente au détail ou de fabrication.
  • Systèmes de traitement de commande.
  • Autres scénarios d’intégration concernant un pipeline de traitement de commande.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

De nombreuses options technologiques sont disponibles pour l’ingestion des messages en temps réel, le stockage de données, le traitement de flux, le stockage des données d’analyse et l’analyse et la création de rapports.

Les microservices sont devenus un style architectural populaire pour générer des applications cloud résilientes, hautement évolutives, capables d’évoluer rapidement et pouvant être déployées indépendamment. Les microservices requièrent une approche différente pour concevoir et générer des applications. Pour obtenir des conseils sur la création et l'exploitation d'une architecture basée sur les microservices, consultez Conception de microservices sur Azure.

Disponibilité

L’approche d’approvisionnement en événements de ce scénario permet aux composants de système faiblement couplés et déployés indépendamment les uns des autres. Azure Cosmos DB offre une haute disponibilité et permet à l’organisation de gérer les compromis associés à la cohérence, la disponibilité et les performances, avec les garanties correspondantes. Apache Kafka sur HDInsight est également conçu pour une haute disponibilité.

Azure Monitor fournit des interfaces utilisateur unifiées pour la surveillance entre divers services Azure. Pour plus d’informations, consultez l’article Monitoring in Microsoft Azure (Surveillance dans Microsoft Azure). Event Hubs et Stream Analytics sont intégrés à Azure Monitor.

Pour d’autres considérations relatives à la disponibilité, consultez la check-list de disponibilité.

Extensibilité

Kafka sur HDInsight permet la configuration du stockage et de l’extensibilité pour des clusters Kafka. Azure Cosmos DB offre des performances rapides et prévisibles et se met à l’échelle sans montrer d’interruption à mesure que votre application se développe. L’architecture basée sur les microservices d’approvisionnement en événements de ce scénario simplifie la mise à l'échelle de votre système et l’extension de ses fonctionnalités.

Pour d’autres considérations concernant la scalabilité, consultez la liste de contrôle d’efficacité des performances dans le Centre des architectures Azure.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Le modèle de sécurité d’Azure Cosmos DB authentifie les utilisateurs et fournit l’accès à ses données et ressources. Pour plus d’informations, consultez Sécurité de la base de données Cosmos DB.

Pour obtenir des conseils d’ordre général sur la conception de solutions sécurisées, consultez la documentation sur la sécurité Azure.

Résilience

L’architecture d’approvisionnement en événements et les technologies associées dans cet exemple de scénario rendent ce scénario hautement résilient lorsque des échecs se produisent. Pour obtenir des conseils d’ordre général sur la conception de solutions résilientes, consultez l’article Conception d’applications résilientes pour Azure.

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.

Pour examiner le coût d’exécution de ce scénario, tous les services sont préconfigurés dans le calculateur de coûts. Pour pouvoir observer l’évolution de la tarification pour votre scénario particulier, modifiez les variables appropriées en fonction du volume de données que vous escomptez. Pour ce scénario, le prix de l’exemple inclut uniquement Azure Cosmos DB et un cluster Kafka pour le traitement des événements déclenchés à partir du flux de modification d’Azure Cosmos DB. Les processeurs et microservices d’événements pour les systèmes d’origine et d’autres systèmes en aval ne sont pas inclus, et leur coût dépend beaucoup de la quantité et de l’échelle de ces services, de même que les technologies choisies pour les implémenter.

La devise d’Azure Cosmos DB est l’unité de requête (RU). Avec les unités de requête, vous n’avez pas besoin de réserver de capacités en lecture et en écriture, ni de configurer les ressources de processeur, de mémoire et d’E/S par seconde. Azure Cosmos DB prend en charge des API variées avec différentes opérations allant des lectures et des écritures simples aux requêtes de graphe complexes. Toutes les requêtes n’étant pas égales, la quantité normalisée d’unités de requête qui leur est affectée est fonction de la quantité de calcul requise pour traiter chaque requête. Le nombre d’unités de requête requis par votre solution dépend de la taille d’élément de données et du nombre d’opérations de lecture et d’écriture de la base de données, par seconde. Pour en savoir plus, voir Unités de requête dans Azure Cosmos DB. Ces prix estimés sont basés sur Azure Cosmos DB exécuté dans deux régions Azure.

Nous proposons trois exemples de profils de coût basés sur la quantité d’activité que vous escomptez :

  • Petite : 5 unités de requête réservées avec un magasin de données de 1 To dans Azure Cosmos DB et un petit cluster Kafka (D3 v2).
  • Moyenne : 50 unités de requête réservées avec un magasin de données de 10 To dans Azure Cosmos DB et un cluster Kafka de taille moyenne (D4 v2).
  • Grande : 500 unités de requête réservées avec un magasin de données de 30 To dans Azure Cosmos DB et un gros cluster Kafka (D5 v2).

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Étapes suivantes

Cet exemple de scénario est basé sur une version plus étendue de cette architecture générée par jet.com pour son pipeline de traitement de commandes de bout en bout. Pour plus d’informations, consultez le profil de client technique jet.com et la présentation de jet.com au Build.

Consultez le contenu suivant :

Consultez l’aide associée en matière d’architecture :