Modifier

Système de messagerie publication-abonnement dynamique du hub de transit

Cache Azure pour Redis
Azure Cosmos DB
Hubs d'événements Azure
Azure Functions
Azure Service Bus

Idées de solution

Cet article présente une idée de solution. Si vous souhaitez que nous développions le contenu avec d’autres informations, telles que des cas d’usage potentiels, d’autres services, des considérations d’implémentation ou un guide des prix, adressez-nous vos commentaires GitHub.

Cet article décrit un modèle publication-abonnement élastique et flexible que les producteurs et les consommateurs de données peuvent utiliser pour créer et consommer des données ou du contenu organisés et validés.

Architecture

Diagramme du système de messagerie publication-abonnement du hub de transit.

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

Dataflow

  1. L’application Producteur de données publie des données sur Azure Event Hubs, qui envoie les données à la fonction Traitement des événements d’Azure Functions.

  2. Le producteur de données envoie également le schéma JSON pour le stocker dans un conteneur Stockage Azure.

  3. La fonction Traitement des événements récupère le schéma JSON dans Azure Cache pour Redis pour réduire la latence et l’utilise pour valider les données.

    Si le schéma n’est pas encore mis en cache, la fonction Traitement des événements récupère le schéma dans le conteneur Stockage Azure. La demande de schéma stocke également le schéma dans Azure Cache pour Redis en vue d’une récupération ultérieure.

    Notes

    Azure Schema Registry dans Event Hubs peut être une alternative viable pour stocker et mettre en cache les schémas JSON. Pour plus d’informations, consultez Azure Schema Registry dans Event Hubs (préversion).

  4. Si une rubrique existe déjà et que les données sont valides, la fonction Traitement des événements fusionne les données dans la rubrique Azure Service Bus Données valides existante et envoie la rubrique à l’application Consommateur de données.

  5. Si une rubrique existe déjà et que les données ne sont pas valides, la fonction Traitement des événements fusionne les données dans la rubrique Service Bus Données non valides existante et renvoie la rubrique au producteur de données. Le producteur de données s’abonne aux rubriques Données non valides pour obtenir un retour d’information sur les données non valides qu’il a créées.

  6. Si une rubrique n’existe pas encore, la fonction Traitement des événements publie les nouvelles données dans une rubrique Service Bus Nouvelles données et envoie la rubrique à la fonction Gestionnaire de rubriques Service Bus.

  7. Si les nouvelles données sont valides, la fonction Traitement des événements insère également les données sous la forme d’un nouvel enregistrement Données d’instantanés dans Azure Cosmos DB.

  8. Si les nouvelles données sont valides, la fonction Gestionnaire de rubriques Service Bus crée une nouvelle rubrique Service Bus Données valides et envoie la rubrique à Event Hubs.

  9. Si les nouvelles données ne sont pas valides, la fonction Gestionnaire de rubriques Service Bus crée une nouvelle rubrique Service Bus Données non valides et renvoie la rubrique à l’application Producteur de données.

  10. Le processeur de fichiers plats des données d’instantanés d’Azure Data Factory s’exécute selon une planification pour extraire toutes les données d’instantanés de la base de données Azure Cosmos DB Données d’instantanés. Le processeur crée un fichier plat et le publie dans un fichier plat de données d’instantanés dans Stockage Azure à des fins de téléchargement.

  11. L’application Consommateur de données récupère une liste de toutes les rubriques Service Bus que le gestionnaire de rubriques Service Bus a mis à disposition pour l’abonnement. L’application s’inscrit auprès du gestionnaire de rubriques Service Bus pour s’abonner à des rubriques Service Bus.

Composants

Détails du scénario

Le hub de transit est un modèle publication-abonnement dynamique permettant aux producteurs et aux consommateurs de données de créer et de consommer des données ou du contenu organisés et validés. Le modèle est élastique afin de pouvoir être mis à l’échelle et performant. Les producteurs de données peuvent rapidement intégrer et charger des données dans un service. Le service valide les données par rapport à un schéma fourni par le producteur de données. Le service met ensuite les données validées à la disposition des abonnés pour qu’ils puissent consommer les données qui les intéressent.

Le service qui valide les données n’a pas besoin de connaître la charge utile, mais seulement de savoir si elle est valide par rapport au schéma fourni par le producteur. Cette flexibilité signifie que le service peut accepter de nouveaux types de charges utiles sans devoir être redéployé. Cette solution permet également aux consommateurs de données d’accéder aux données historiques qui ont été publiées avant qu’ils ne s’inscrivent.

Cas d’usage potentiels

Ce modèle est particulièrement utile dans les scénarios suivants :

  • Systèmes de messagerie où le volume et l’état des utilisateurs sont inconnus ou varient de manière imprévisible
  • Systèmes de publication qui doivent potentiellement prendre en charge des sources de données nouvelles ou inconnues
  • Systèmes de commerce ou de billetterie qui doivent continuellement mettre à jour les données et les mettre en cache pour une livraison rapide

Contributeurs

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

Auteur principal :

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

Étapes suivantes